AI Business Automation That Holds Up in Production

Most AI automations that fail in production don't fail because the model is weak. They fail because the model was handed the whole process to run. The model should make one judgment call inside a workflow it does not control.

That is the design I start from whenever a business process is a candidate for a language model. The rest of this piece is what surrounds that call.

Plain code first

Before a model enters the design, I ask whether rules would do. Routing on a form field, checking a reference number's format, applying a pricing table: that is code. It is cheaper, faster, testable, and gives the same answer twice.

A model earns its place where the input is unstructured and the decision needs reading: an email that could be a complaint or a cancellation, a scanned document of unknown type, a free-text request that has to land in the right queue. Anthropic's guidance on building effective agents makes the same case: find the simplest solution possible and add complexity only when it pays for itself. Most business automation is a workflow with predefined code paths, not an agent choosing its own steps.

The model returns data, not prose

Every model call in a workflow returns a typed object against a schema. Say, for a document intake step: document type, confidence, extracted fields, and the reasons behind the classification. Providers now enforce this at generation time; structured outputs constrain the response to the schema, so malformed JSON stops being a failure mode.

That guarantees shape, not truth. A schema-valid response can still carry a wrong amount or a date read from the wrong page. So plain validation runs after it: totals reconcile, referenced records exist in the system of record, dates fall in range. Anything that fails goes to review, not to the next step.

Tool calling follows the same rule. The model can request an action. The code decides whether it runs, with which permissions, and against which records.

People own the consequential decisions

Every automation needs a written answer to one question: what happens when the model is unsure, or wrong?

My default is that anything touching money, a customer, or a compliance obligation passes through a person before it takes effect. Below a confidence threshold, the item goes to a review queue with the model's reasoning attached, so the reviewer starts from a draft instead of from zero. Above it, low-risk actions such as tagging, drafting or enriching a record can proceed, and a sample is still checked.

It is the same principle as the human gate in my team's delivery pipeline. The machine handles the volume. A person owns the outcome.

Built like any other backend job

A model call is a slow, occasionally failing, non-deterministic network dependency. It gets the treatment every such dependency gets: idempotent steps, so a retried job never sends the email twice, and bounded retries that end in a dead-letter queue someone watches. Two additions are specific to models:

• Budgets. Each step has a latency ceiling and a cost ceiling, and monitoring alerts when either drifts.
• An audit trail. For every decision: the input reference, the output, the prompt version and the model version. In regulated industries such as banking, "why did the system do this" has to be answerable months later.

Nothing changes without an eval

Prompts and model versions are code. They are versioned, reviewed, and not changed without evidence.

Before anything goes live, I want an evaluation set: realistic examples with known correct answers, including the edge cases and the ugly inputs. Every prompt edit or model upgrade runs against it before it ships, and the set grows each time production surfaces a new failure. OpenAI's evaluation best practices name the alternative well: "vibe-based evals", which is how regressions reach customers.

Data in, outside content in

Two boundaries hold regardless of how capable the model is.

The first is data. Secrets, credentials, and anything confidential the step doesn't need never go into a model call. Fields are stripped before the request is built, not filtered afterwards. It is the same rule I apply to my own use of AI tools, enforced in code instead of habit.

The second is outside content. The moment the model reads an inbound email, an uploaded PDF or a web page, that text can carry instructions. The OWASP Top 10 for LLM Applications ranks prompt injection first for this reason. The defense is architectural: the model gets only the permissions its step needs, external content is marked as untrusted, outputs are checked by deterministic code, and privileged actions need a human. A model that can only return a classification cannot be talked into moving money.

What holds up

The automations that last are unglamorous: a deterministic workflow, one narrow model call, a schema, a review queue, an eval set and a log.

The model supplies judgment. The system around it supplies reliability. Build the system first, and the model becomes the easiest part to replace.