On this page
Which shape you should pick
Default to a workflow. Choose an agent only when the sequence of steps genuinely cannot be enumerated in advance, and you can prove that by counting: take a hundred real cases, write down the step sequence each one actually needed, and count how many distinct sequences appear. Under roughly ten, write branches. Over about thirty with a long tail that keeps producing new sequences, an agent starts to earn its cost. Between the two, build a fixed pipeline with a model inside two or three steps.
This is a measurement, not a taste question, and it takes an afternoon. Teams skip it because the agent demo was persuasive and because counting paths feels like the boring option. The counting is what tells you whether you are buying flexibility you need or variance you will spend a year containing.
- 100Real cases to sample before the design meeting. Recent, unfiltered, including the awkward ones.
- 3Places variance can be booked: in code, in the model, or in a human's queue.
- 1Number that dominates running cost for either shape: the escalation rate.
- 0Steps a model should own that involve arithmetic, identifier lookup or a permission check.
The measurement that settles the argument
Count paths, not steps. A process with forty sequential steps and no branching is the easiest workflow you will ever write. A process with six steps that combine differently for every customer is the hard one. Length and difficulty are unrelated, and confusing them is the most common reason a team reaches for an agent it does not need.
- Pull a hundred real cases
From the last ninety days, unfiltered. Not the ones someone remembers, and not a clean sample. The awkward cases are the entire question.
- Write each case as a step sequence
Encode what actually happened as a short string, for example check-po, email-supplier, wait, credit-note, post. Identical cases collapse to identical strings, which is what makes them countable.
- Count distinct sequences and their frequency
You will usually get a head of five to ten sequences covering most of the volume, and a long tail of sequences appearing once. That shape is normal and it is the whole finding.
- Split the tail into repeatable and genuinely novel
Some tail cases are rare but well defined, so they are branches nobody wrote yet. Others are novel every time. Only the second kind is an argument for an agent, and it is usually smaller than it feels.
- Check the rate of new sequences
Sort by date and ask how many of the last twenty cases needed a sequence not seen in the first eighty. A high rate means the branch set is still growing and code will lag reality. A rate near zero means the process is stable and branches will hold.
If the answer is that the head covers most of the volume and the tail is small, the correct design is branches for the head and a human queue for the tail. An agent built for that shape spends most of its runs rediscovering a path you could have written down, at a higher price per run and with no test that proves it will pick the same path tomorrow.
The Variance Ledger
Every process contains a fixed amount of variance: the number of genuinely different situations reality produces. You do not get to remove it by choosing a design. You only get to choose where it is booked, and the ledger always balances.
The Variance Ledger
Three accounts, and a fourth nobody budgets for. Choosing between an agent and a workflow is choosing which account carries the process variance, not whether you pay for it.
Cheapest per run, most expensive per change. You pay once at build time for each branch and again every time reality moves. This is the right account when the branch set is small and stable, and the wrong one when a new case type appears monthly and every appearance needs a release.
Cheapest to extend, most expensive per run, hardest to test. A new case type often needs no code at all. In exchange you accept a cost distribution rather than a cost, a test suite that samples rather than proves, and the possibility that the same input takes a different route next Tuesday.
Most expensive per case and instant to add, and the only account that handles a situation nobody anticipated. Escalation is a line item, not a failure. Costing a design without a number in this account is the most common error in automation planning, because it is the account that usually dominates.
The account that opens when you close the other three too aggressively. Cut escalations without reducing real variance and the difference does not vanish: it becomes confidently wrong answers that reach someone outside your company. This is the only account where the cost arrives late, arrives compounded, and is not on your dashboard.
The practical use of the ledger is in design review. Someone proposes an agent to reduce the human account, so ask which account the variance moves to and what the new number is. If nobody can answer, the proposal is not moving variance, it is hiding it.
The two shapes, dimension by dimension
Neither column is better. They fail differently, and the failure profile should match what your process can tolerate.
The hybrid that actually ships
Most production systems worth copying are fixed pipelines with a model inside two or three steps. The sequence lives in code where it can be read and tested, and the model handles the parts that are genuinely linguistic: reading unstructured input, classifying it, drafting language. The rest stays deterministic, and some of it should never move.
| Step type | Who should own it | Why |
|---|---|---|
| Classify free text into known categories | Model, with a confidence floor | Language variation is exactly what models handle well and regexes handle badly |
| Extract fields from an unstructured document | Model, with schema validation after | Layouts vary per sender, so a template breaks on the next supplier |
| Arithmetic, totals, tax, currency | Code, always | A model that is right most of the time is a defect in a finance path |
| Look up a record by identifier | Code, always | A model asked for an ID under pressure will produce a well formed fiction |
| Permission and threshold checks | Code, always | A check that can be talked out of is not a control |
| Duplicate detection | Code, always | Deduplication needs a deterministic key, not a judgment |
| Draft a reply for a human to send | Model, with review before send | Cheap to check, expensive to get slightly wrong unsupervised |
| Rank options on fuzzy criteria | Model, with a deterministic tiebreak | Ranking is judgment, but ties must resolve the same way every run |
- Every model step needs a deterministic fallback, and the fallback is usually a human queue rather than a retry.
- Every model step needs a confidence floor below which the fallback fires, and the floor is set from your sample, not from a default.
- If a model step needs a second model step to check the first one, the design is drifting toward an agent without anyone deciding to build one. Say so out loud in review, and see when to use multiple agents before you split it further.
The arithmetic that decides it in money
Compute cost is usually the smaller half of the bill and it gets nearly all the argument. What dominates is the escalation rate multiplied by the human minutes behind it. A shape that is more expensive per run and escalates less can be cheaper in total, and the only way to see that is to put both on the same page.
Compute cost is entered per thousand runs so you can use your own measured figure rather than a rate printed on a page. Take the escalation percentages from your sample, not from hope.
Run it once with your own numbers and the shape of the decision changes. At most realistic volumes the compute line is a rounding error against the labour line, which means the honest question is not which architecture is cheaper per run, it is which one escalates less on your actual case mix. That is measurable before you build anything, by running both designs over the hundred cases you already sampled.
Write the decision down
The decision is only useful if the next person can see what it was based on. A short record beats an architecture diagram, because it captures the measurement and the conditions under which the answer should change.
# shape-decision-record.yaml
# One per process. Written before the build, reread every quarter.
# Every value below is illustrative. Replace all of them with your own measurements.
process: "supplier invoice exceptions"
decided_on: 2026-08-26
owner: "named ops lead, not a team"
measurement:
cases_sampled: 100
window: "last 90 days"
distinct_step_sequences: 14
top_5_sequences_cover: "78% of sampled volume"
cases_needing_a_new_sequence: 6
current_handling_minutes_median: 7
decision: workflow_with_model_steps # workflow | workflow_with_model_steps | agent | leave_manual
model_steps:
- step: classify_exception_type
why: "free text supplier email, 9 known categories, no arithmetic"
fallback: route_to_human
- step: extract_line_items
why: "layout varies per supplier, no fixed template"
fallback: route_to_human
never_model: # these stay in code, permanently
- "totals, tax and currency arithmetic"
- "supplier and PO identifier lookup"
- "approval threshold checks"
- "duplicate detection"
variance_booked:
code: "14 branches, each with a test"
model: "2 bounded steps, both with a deterministic fallback"
human: "about 60 cases a month at 7 minutes"
revisit_when:
- "distinct sequences exceed 25"
- "the human tail exceeds 200 cases a month"
- "a new exception category appears twice in one month"
- "any model step needs a second model step to fix its output"The two fields that earn their place are never_model and revisit_when. The first stops a well meaning change six months later from handing tax arithmetic to a model because it seemed to work in a test. The second turns the decision into something with an expiry date rather than a permanent article of faith.
When the right answer changes
A shape decision has a shelf life. Volume grows, the case mix drifts, a supplier changes format, a regulation adds a check. Two of those push you toward code and two push you toward a model, so revisit on a schedule rather than after an incident.
- Workflow automation
- A system in which the sequence of steps is fixed at build time. A model may run inside a step, but it never chooses which step runs next.
- Step sequence
- The ordered list of steps one real case actually required, written as a short string so that identical cases collapse together and distinct ones can be counted.
- Escalation rate
- The share of cases a system hands to a human because it cannot finish them safely. It is the single number that dominates the running cost of either shape.
- Branch factor
- The count of decision points where the next step depends on the content of the case rather than its position in the sequence. Length is not branch factor: forty steps in a fixed order have a branch factor of zero.
If the count says workflow, the build is ordinary integration work and belongs with workflow automation. If it says agent, read what an AI agent actually is before scoping, because the loop is the small part. Either way, map the process first: mapping a process before automating it is where the hundred cases come from.
Questions readers ask next
Is an AI agent always more capable than a workflow?
How many distinct paths justify an agent?
Can I start with a workflow and move to an agent later?
Does a model inside a workflow make it an agent?
What is the cheapest way to test both shapes before committing?
Who should own the decision between the two shapes?
ChatGPTalker. "Agent or Workflow: How to Choose the Right Shape." chatgptalker.com, 2026-08-26. https://chatgptalker.com/guides/agent-or-workflow/