AI automation in
production workflows

Most automation that reaches production fails for the same reason: it treats a language model as the system rather than as one component inside it. A model is good at reading an unstructured message and proposing an interpretation. It is a poor choice for enforcing a spending limit, deciding who approves a refund, or guaranteeing that a record was written exactly once.

The useful split is narrow. Use a model where the input is ambiguous and human judgement would otherwise be required to read it. Use deterministic code everywhere the answer must be identical on every run.

Where interpretation belongs

Classification and extraction are interpretation problems. An inbound email might be a quote request, an invoice, a complaint, or a reply to a thread from six weeks ago. A model can assign that label and pull structured fields out of the body and its attachments — names, dates, amounts, reference numbers.

What it produces is a proposal, not a fact. Treat it that way. Every extraction should be validated against the schema the next system expects before anything acts on it. A date that does not parse, an amount with two decimal separators, a reference number that matches no known customer: these are ordinary outcomes, not exceptions.

Confidence deserves the same treatment. A classifier that returns a score is telling you something actionable. Below your threshold, the work goes to a person. That threshold is a business decision and belongs in configuration, not in a prompt.

Where determinism belongs

Once the request is structured, judgement stops and policy starts. Limits, ownership, escalation paths, exception handling — these are rules your business already has, and they change more often than the model does.

Keep them outside the model. A rules layer you can read, diff, and version is one an operations lead can change without an engineer. A prompt that encodes the same logic is opaque, untestable, and silently rewritten every time someone tunes the wording.

A workflow that survives contact with production

The shape below is deliberately unremarkable. Its value is that each stage has one job and produces evidence.

Record the request at intake, before interpretation. If you only persist after processing succeeds, you cannot investigate the runs that failed — which are exactly the runs worth investigating.

Approvals are a system boundary

An approval step is not a notification. It is a point where the workflow stops and waits, possibly for hours, and it has to survive a deployment while it waits.

That means the pending state lives in durable storage, not in memory or in a queue message with a visibility timeout. It means the approver sees the extracted evidence and the reason for the recommendation, not just a yes/no button. And it means a decision is recorded against a person and a timestamp, because at some point someone will ask who released a payment.

Failure handling, written down first

Every integration in the chain will be unavailable at some point. Decide the behaviour per step before you build it:

Failure	Reasonable default
Model timeout	Retry with backoff, then route to a person. Never silently drop.
Low confidence	Route to a queue with the extracted fields attached for correction.
Schema validation fails	Hold the run, surface the offending field, keep the raw input.
Downstream API 5xx	Retry on an idempotency key. The write must be safe to repeat.
Downstream API 4xx	Stop. This is a logic error, and retrying will not fix it.

Idempotency is the one that gets skipped and the one that hurts. If a retry can create a second CRM record or send a second reply, the workflow is not finished. Derive a key from the request, not from the attempt.

Observability for workflows, not just services

Service metrics tell you the automation is running. They do not tell you it is working. The questions an operations owner actually asks are different:

• What share of requests completed without a person this week, and is it moving?
• Which step sends the most work to the exception queue?
• How long do items sit waiting for approval, and who owns the oldest one?
• When a rule changed, what happened to the completion rate after it?

Those require the run itself to be a first-class record: input, interpretation, confidence, rule version, decision, outcome, and duration per stage. Log that and the reporting layer is a query. Skip it and no dashboard will recover the information.

Replay is the recovery plan

Because the raw input was stored at intake and every stage is deterministic after interpretation, a run can be replayed. That matters in three ordinary situations: a downstream system was down and a batch needs reprocessing; a rule was wrong and yesterday's decisions need re-evaluating; an auditor asks how a specific decision was reached eight months ago.

Replay is not a feature you add later. It is a consequence of storing inputs separately from outcomes and keeping the policy layer versioned.

What this buys

A workflow built this way is boring in the right places. The model does the reading. The rules do the deciding. The integrations are safe to retry. A person sees the cases that need judgement, with the evidence in front of them. And every run leaves a record that answers questions later.

That is the standard we build to in AI Automation engagements. The same evidence discipline shows up in how we built OpsGate, where a score without its supporting evidence is treated as incomplete.