Workflows vs agents

When a team slides right on the dial, three things happen at once - and only one of them is on the pitch slide:

• Capability goes up. The system handles requests too varied for a fixed script - this is the part everyone sells.
• Cost goes up. More model calls per task, more latency, a bigger bill for the same outcome.
• Predictability goes down. Fixed paths can be tested like normal software; a model choosing its own steps cannot be certified the same way, only evaluated and monitored.

So the leader's question is never "should we use agents?" It is "how far right does THIS task force us?" Most tasks in most organizations sit comfortably in the middle band - the five patterns - or all the way left, in plain code.

Four questions that place any proposal on the dial in one meeting:

• "Who chooses the next step - our code or the model?" If the answer is "our code", it is a workflow, whatever the deck calls it.
• "Could we write the steps down in advance?" If yes, a pattern in the middle band will be cheaper and testable.
• "What does one task cost at the far right vs the middle?" Ask for both numbers before approving either.
• "How will we test it?" A team that cannot answer this has bought unpredictability without noticing.

What it is: the task runs as a fixed sequence of steps, each model call feeding the next - outline, then draft, then translate, with checks between stations.

The right buy when: the work naturally decomposes into stages that always run in the same order, and you want quality control between them. You trade a little latency for a lot of accuracy per step - exactly the deal an assembly line makes. Ask your team: "could we name the stations?" If yes, chain it.

What it is: a first model call classifies the incoming request, then hands it to the specialist path built for that category - billing questions here, technical issues there.

The right buy when: your inputs fall into distinct categories that deserve different handling - different prompts, different tools, even different models by cost. It is a hospital triage desk: one cheap decision up front so every case gets the right specialist, and no single prompt has to be good at everything.

What it is: several model calls run at the same time - either splitting the work into independent pieces, or asking for multiple independent takes on the same question - then the results are combined.

The right buy when: speed matters and the pieces are independent, or confidence matters and you want several opinions before acting - screening content, double-checking a judgment call. You pay for extra calls; you get speed or confidence. Like asking three doctors at once instead of one after another.

What it is: a central model looks at the task, decides how to break it up on the fly, delegates the pieces to worker calls, then merges what comes back.

The right buy when: you cannot predict the subtasks in advance - each case needs a different breakdown. This is the first pattern where the model, not your code, decides the decomposition, so it sits furthest right in the middle band. It is a team lead with specialists: more capable than a fixed pipeline, more expensive, and the step to watch on cost.

What it is: one model call produces, a second evaluates against clear criteria and sends it back with feedback, looping until the output passes.

The right buy when: quality is measurable and iteration visibly improves it - translations, reports, anything a human editor would redline. You pay for the loop; you get output that clears a defined bar instead of a first draft. Ask your team: "what does the editor check against?" If they cannot name the criteria, this pattern is not ready.

OpenAI names exactly two conditions that justify going multi-agent - and neither is "it sounds more advanced":

• Complex conditional logic - the instructions have grown so many branching rules that prompts become unmaintainable, the same way an if/else forest becomes unmaintainable code.
• Tool overload - and here is the nuance leaders miss: it is not about the NUMBER of tools. It is about overlap. An agent with many clearly distinct tools can be fine; an agent with a few similar, overlapping tools gets confused about which to use. Ask "are the tools distinct?" before "how many are there?"

If neither trigger is present and someone proposes a multi-agent system, the burden of proof is on them - with numbers.

The middle band of the dial has a property the far right never will: you can test it like software. A routed workflow has fixed lanes - you can check each lane, measure each lane, and sign off each lane. A full agent's path changes per request, so assurance becomes evaluation and monitoring rather than certification. For anything customer-facing or regulated, that difference is the whole governance story (a4 picks this up). Less autonomy means cheaper, testable, boring - and boring is a feature in production.