An AI agent does not automate a process. It automates the interpretive steps inside a process — reading a document, classifying an enquiry, extracting a figure, drafting a response — while the deterministic steps stay as code and the consequential decisions stay with a person. Automating an entire process end to end is where these projects fail.

The work is therefore process decomposition, not model selection. This article is about how to do that decomposition.

Which parts of a process can an agent actually take?

Every business process is a sequence of steps, and each step falls into one of three categories.

Deterministic steps have exactly one correct outcome given the inputs: calculate a fee, check a value against a threshold, write a record, send a notification. These belong in code. An agent doing arithmetic is slower, more expensive and less reliable than a function doing arithmetic.

Interpretive steps require reading unstructured content and producing structured meaning: what is this document, what is the customer asking, which of these clauses applies, what does this free-text field mean. These are what agents are genuinely good at, and they are the steps that previously forced a human into the loop for reasons that had nothing to do with judgement.

Judgement steps require weighing consequences, applying discretion, or accepting accountability: approve the credit, reject the claim, escalate to legal. These stay with people — not because a model cannot produce an answer, but because the organisation needs someone accountable for the outcome.

The decomposition exercise is simply labelling every step in a real process with one of these three. It takes a day per process and it is the highest-value hour of an agent project, because most disappointing deployments turn out to have handed deterministic steps to a model or judgement steps to nobody.

Why does the deterministic split matter so much?

Three reasons, each of which shows up in production.

Reliability. A deterministic function produces the same output every time. A model does not, and the variance is not eliminable. Anything that must be exactly right — a calculation, a threshold check, an identifier lookup — should not be probabilistic.

Cost and capacity. On-premise, GPU capacity is finite. Routing work to a model that a function could do consumes capacity that the interpretive steps need, which is why routing is a control-plane concern rather than an application one — see AI orchestration architecture.

Explainability. When something goes wrong, a deterministic step has a traceable cause. Keeping the deterministic parts deterministic keeps the investigation surface small.

The resulting architecture is a workflow where code calls the model for interpretation and does everything else itself — not a model that calls tools to accomplish a process. The distinction sounds subtle and determines whether the system is debuggable.

Where does the human stay?

At the points classified as judgement, and at one more place people forget: the exception path.

Approval gates on consequential actions. Classify actions by reversibility. Reads are free, reversible writes can proceed, irreversible or externally-visible actions require approval. The approver needs the proposed action, its inputs and the evidence — not a summary the model wrote about its own reasoning.

Exception handling. When the agent cannot complete a step confidently, it stops and routes to a person with the context assembled. This is the design decision that most affects whether people trust the system: an agent that guesses when uncertain is worse than one that asks, because guessing transfers the error to a downstream step where it is harder to catch.

Sampling review even on the confident path. A percentage of completed cases reviewed by a person, continuously. Not a launch-phase activity — a permanent control, because quality drifts as source content changes and nobody notices otherwise.

The practical design rule: the agent's output is a proposal until a defined condition makes it final. Sometimes the condition is human approval, sometimes it is a deterministic validation passing, sometimes it is a confidence threshold combined with a sampling regime. What is never acceptable is that the condition is unstated.

How should exceptions actually be handled?

The part that decides whether the deployment survives contact with real volume, and the part demos never show.

Route exceptions with context, not as failures. The person receiving an exception should get the document, what the agent extracted, what it could not resolve and why. An exception queue that says "manual review required" recreates the original work and adds a step.

Measure the exception rate as the primary quality metric. It is more informative than accuracy, because it is observable in production without labelled data. A rising exception rate is the earliest signal that source content or upstream systems have changed.

Feed exceptions back into the design. The same exception appearing fifty times is either a missing capability or a document type nobody accounted for. Reviewing the exception log monthly is what turns a static deployment into an improving one.

Never let an exception silently become an approval. Under load, queues get cleared. If the approval interface makes bulk-approving easy, bulk approval is what will happen, and the control becomes decorative.

What does the integration surface look like?

Agents touch three kinds of systems, with different integration characteristics.

Read integrations — document stores, databases, ticketing systems, email. The technical work is straightforward; the governance work is not, because retrieval scope has to be defined and enforced per user. The architecture for this is in lakehouse architecture for enterprise AI and RAG.

Write integrations — creating a ticket, updating a record, sending a message. These need idempotency, because agents retry. An agent that creates a duplicate ticket on every retry is a support incident generator.

Human-facing surfaces — where approvals and exceptions appear. Whether this is a dedicated interface or an integration into the tool the team already uses is a genuine decision. Integrating into the existing tool usually wins on adoption; a dedicated interface usually wins on audit completeness. The audit requirement is generally decisive in supervised institutions.

Standardised tool interfaces reduce the per-integration cost meaningfully. The Model Context Protocol has become the common approach, and its practical value is that an integration written once is reusable across models and applications rather than being rebuilt per framework.

How do you measure whether it worked?

Four metrics, and the first two must be baselined before anything is built.

Cycle time. How long a case takes from arrival to resolution. The number executives care about and the easiest to game — measure it end to end, including the exception path, not just the happy path.

Human touch time. Minutes of human attention per case. This is the honest efficiency measure, because a process where the agent is fast and the human still reads everything has not improved.

Exception rate. The share of cases the agent could not complete. Tracked over time, this is the quality signal.

Downstream error rate. Cases that came back — corrections, complaints, rework. The measure that catches a system optimising for throughput at the expense of correctness, and the one most often omitted.

A note from deployments: cycle time improves before touch time does. The first version routes work faster and still requires the same reading. Touch time improves when the exception rate falls and reviewers start trusting the confident path, which is a second-quarter outcome. Setting the expectation accordingly is what prevents a successful project being judged a failure at week six.

What does a rollout look like?

Five phases, and the sequencing is deliberate.

Phase 1 — shadow mode. The agent processes real cases and its output is recorded but not used. Humans work as before. This produces the accuracy measurement that no pilot on synthetic data can, and it costs nothing but time.

Phase 2 — assistive. The agent's output is shown to the person doing the work, who accepts, edits or ignores it. Acceptance rate is now a live quality metric, and edits are the most valuable training signal available.

Phase 3 — supervised automation. The agent completes cases, a person approves before anything becomes final. Volume moves here once the acceptance rate is stable.

Phase 4 — automation with sampling. Confident cases complete without individual approval; a defined percentage is reviewed. This is where efficiency gains actually arrive, and it requires the audit trail to be trustworthy first.

Phase 5 — expansion. Adjacent process steps, additional document types, more volume.

Most organisations should expect phases 1 to 3 to take a quarter and should not skip phase 1. Shadow mode is the cheapest information available in the whole project, and skipping it means the first real accuracy measurement happens in front of users.

Key points

  • Agents automate interpretive steps. Deterministic steps stay in code and judgement steps stay with people.
  • Decompose the process by labelling every step deterministic, interpretive or judgement. It takes a day and is the highest-value work in the project.
  • Code should call the model for interpretation, not the model call tools to run the process. That structure is what makes the system debuggable.
  • The agent's output is a proposal until a stated condition makes it final. The condition must never be implicit.
  • Route exceptions with full context, treat the exception rate as the primary quality metric, and review the exception log monthly.
  • Make write integrations idempotent; agents retry.
  • Baseline cycle time and human touch time before building, and track downstream error rate to catch throughput-at-any-cost.
  • Roll out through shadow mode, assistive, supervised automation, then sampling. Do not skip shadow mode.

Yukon Labs implements HAVAA on-premise with the process decomposition done first, because the split between code, model and human is what determines whether a deployment holds. For candidate processes, see AI agent use cases across industries; for how this differs from rule-based automation, AI automation vs traditional automation.