What are agentic workflows — and when a workflow beats an agent

Note on terminology.The five-pattern taxonomy below follows Anthropic’s Building effective agents, which is where the workflow/agent distinction was set out most clearly and whose vocabulary the industry has largely adopted. The argument about which to choose, and the cost and testability analysis, is ours.

The one test

Everything that matters follows from that one difference. Not capability — a workflow calling the same model is exactly as intelligent per step. What changes is the size of the set of possible executions.

Five patterns that get sold as agents

1. Prompt chaining

Each call’s output feeds the next. Extract, then summarise, then format. Use it when a task decomposes into fixed sequential stages, and put a validation gate between stages so a bad intermediate result fails fast rather than propagating.

const extracted = await extract(document);
if (!isValid(extracted)) throw new ExtractionError();   // fail here, not three steps later

const summary  = await summarise(extracted);
const formatted = await format(summary);

2. Routing

A classifier picks a downstream handler. A support enquiry is triaged into billing, technical or cancellation, and each route has its own prompt and tools. This is the highest-value pattern in customer operations because it lets you use a cheap model for triage and reserve expensive handling for the routes that need it.

3. Parallelisation

Independent subtasks run concurrently and are aggregated — either sectioning one task into parts, or voting where several attempts are compared. Wall-clock is the slowest branch rather than the sum, which makes it the pattern to reach for when latency is the constraint.

4. Orchestrator-workers

A coordinator decomposes a task, dispatches workers, and combines results. This is the pattern most often confused with a true agent, and the distinction is precise: if the coordinator can only dispatch from a fixed set of worker types in a fixed shape, it is a workflow. If it decides at runtime what kinds of workers it needs and how many rounds to run, it is an agent.

5. Evaluator-optimiser

One call produces output, a second critiques it, and the first revises — looping until the critique passes or a limit is reached. The bounded loop is what keeps this a workflow, and the bound is not optional: an unbounded critique loop is the most common way a workflow quietly becomes an unpriced agent.

When you genuinely need an agent

The honest test for the middle of that table: if you find yourself writing a prompt that says “figure out what to do and do it” for a task you could have specified, you have chosen an agent to avoid the work of specification — and you will pay for that choice in tokens, latency and untestability rather than saving anything.

What autonomy actually costs

That last property deserves emphasis because it is counter-intuitive and it wrecks budgets. In a normal system, failures are cheap — you error out early. In an agent loop, a failure is a run that kept trying: more turns, each carrying a longer context, each costing more than the last.

Workflow (3 fixed steps):
    cost  =  c1 + c2 + c3                    ← constant, known before shipping

Agent (n turns, context accumulating):
    turn k input  ≈  base + Σ(previous turns' outputs and tool results)
    cost          ≈  Σ(k=1..n) (base + k·δ)  =  n·base + δ·n(n+1)/2

    → cost grows with the SQUARE of turn count, not linearly
    → the runs that fail are the runs with the largest n
    → prompt caching flattens the base term, not the accumulation

Prompt caching helps with the repeated prefix but not with the growing tail, which is the part that scales. The practical consequence is that a turn cap is a cost control as much as a safety one — and that an agent without one has no upper bound on what a single request can spend.

Testability is the real gap

This is the argument that should decide most real decisions, and it gets the least attention because it is unglamorous. Ask what your test suite looks like in each case:

Coverage is the row that ends arguments. In a workflow you can say “we test every branch” and mean something. In an agent there is no denominator, so there is no such statement to make — which matters enormously if anyone ever has to sign off on the system’s behaviour.

If you do need the agent, the tooling burden is real and worth knowing about in advance — see what a trace has to contain before you can evaluate trajectories at all.

Start as a workflow, promote later

The sequence that works, and the reason each step is in that order:

Step three is the one that surprises teams. When the failure log is actually examined, the unbounded branching is nearly always confined to a single step — a diagnosis, a decision about which of many systems to consult — while the rest of the pipeline was fixed all along. Promoting the whole pipeline because one step needed autonomy is the most common over-build in this space.

The hybrid that usually wins

// Fixed control flow: known steps, known cost ceiling, testable branches.
async function handleTicket(ticket: Ticket) {
  const route = await classify(ticket);              // workflow: routing
  if (route === "billing")      return billingFlow(ticket);
  if (route === "cancellation") return escalateToHuman(ticket);   // policy, not capability

  // ONE step is genuinely open-ended — so this step, and only this step, is an agent.
  const diagnosis = await runAgent({
    objective: `Diagnose: ${ticket.body}`,
    tools: [readLogs, searchDocs, checkStatus],      // read-only: no authority to act
    maxTurns: 12,                                    // bounded
    maxCostUsd: 0.40,                                // bounded
  });

  // Back to fixed control flow, with a human gate on anything consequential.
  return diagnosis.confident
    ? replyWithFix(ticket, diagnosis)
    : escalateToHuman(ticket, diagnosis);            // the agent proposes; code decides
}

Two design choices in that snippet carry most of the safety. The agent gets read-only tools, so the worst outcome of a bad trajectory is a wrong recommendation rather than a wrong action. And the decision to act stays in code, which means the authority boundary is enforced structurally rather than requested in a prompt — the subject of authority as code.

The conclusion is genuinely inconvenient for anyone selling agents, including us: most teams asking how to build an agent should build a workflow instead, and would ship sooner, spend less and sleep better. The interesting engineering is not in making a system autonomous — it is in working out the smallest part of it that needs to be.

Which is also why so many products marketed as agents are really workflows, or less. If you are evaluating one rather than building it, the same distinction becomes a buyer’s test — a handful of questions that separate a real agent from a wrapper wearing the label.