Workflow or agent? Do the arithmetic first

Autonomy is not an ambition decision. It is a cost decision, and the costs compound per step.

There is a conversation happening in every enterprise right now, and it usually starts with the word "agentic" and ends without anyone having done any arithmetic. The instinct is understandable — agents are the interesting thing, and nobody gets excited proposing a pipeline. But the choice between a workflow and an agent is not a statement about how advanced your team is. It is a purchasing decision about how much autonomy the task actually needs, paid for in three currencies: cost, latency, and compounding failure.

The definitions matter, so plainly: a workflow is a system where you decided the steps and the model executes inside them. An agent is a system where the model decides the steps — which tool to call, what to do next, when it's done. Everything in between — a workflow with one open-ended step, an agent on rails — is just a point on that line. The question is never "should we be agentic?" The question is: where on this line does the task stop paying for autonomy?

The arithmetic

Three calculations, none requiring more than a napkin.

Failure compounds per decision. A model that is right 95% of the time on a single step is a different animal chained across eight self-directed steps: 0.95⁸ ≈ 66%. One error in three runs, and — worse — the failures are path failures, different every time, resistant to debugging. A workflow spends its error budget once per constrained step, and you know which step broke. An agent spends it on every decision, including decisions you didn't know it would make. This single line of math kills most agent proposals honestly, before a demo ever seduces anyone.

Latency and cost multiply per step too. Every reasoning hop is another model call. A task a workflow finishes in one pass and two seconds, an agent may finish in nine calls and forty seconds — at nine times the token bill, before retries. For a task run ten times a day, nobody cares. For a task run fifty thousand times a day, the architecture is the unit-economics decision.

Variance is what autonomy is for. So when does the agent win? When the input space is too irregular to enumerate: the long tail of formats, the branching investigation, the task where writing the workflow means writing four hundred branches you'll never maintain. Autonomy is a payment you make to handle variance you cannot specify. If a human can write the steps down, the steps are cheaper — every time.

How I actually run the decision

Build the workflow version first, cheaply — often it's a day of work, and it becomes the baseline. Then build the smallest agentic version of the same task and run both against the same eval set. Now the argument is over, because there is a table: quality delta, cost per task, p95 latency, failure rate, and — the row people forget — reviewability: when it's wrong, can a person see why?

Most tasks lose the autonomy they were about to be given. The workflow matches the agent's quality at a fraction of the cost, and the roadmap quietly improves. And when the agent does win — when the variance is real and the table shows it — you ship it with confidence instead of hope, because you know exactly what the autonomy is buying and what it costs.

The pattern underneath: start with the least autonomy that solves the task, and promote a system to more autonomy only when it has earned trust at the current level — the same way you'd promote a person. Systems that assist ship first; systems that act alone ship after the evidence.

If you take one thing: a workflow's failures add; an agent's failures multiply. Buy autonomy only where variance makes the multiplication worth it.