Workflows vs agents

Read these first

• What an agent is
• Prompt decomposition

What you will know

• Take an "agent" requirement and deliver it as a deterministic workflow

  A fixed graph makes retries, tests, approvals, and failure handling explicit instead of letting model-chosen actions expand unpredictably.

• Write a decision record that selects a workflow or agent using path variability, tool-choice requirements, and operational constraints

  The choice should account for bounded versus open-ended work, latency budgets, auditability, and how safely incorrect actions can be contained.

• Measure the cost of non-determinism with a matched workflow and agent prototype

  Compare task success, tool-call count, latency, token spend, and reproducibility across the same representative inputs.

• Show a case where the workflow is genuinely insufficient

  A bounded loop stops being an adequate abstraction when later steps depend on discoveries that cannot be enumerated or scheduled in advance.

• Run a design review that rejects an agent when a workflow meets the requirement

  A credible recommendation should survive objections about flexibility while identifying the concrete evidence that would justify adding model-controlled iteration later.

Chapters

1. 1

   Enumerable steps, not the presence of a model, decide it

   The criterion is whether the steps and their order can be listed in advance for nearly every input, not whether an LLM appears somewhere in the design. Test it against a fixed graph whose first node is a model call routing the request into one of six branches. The reachable state space there is six, all of them enumerated, so the model influenced a decision without ever receiving control flow.

   Read chapter
2. 2

   Retrying a failed API is not a reason to add a loop

   "We made it an agent so it can retry when the API fails" confuses an operational concern with a control-flow one, and the confusion is expensive. Retries, backoff and fallbacks belong to any architecture at all. What model-controlled iteration actually adds is state to persist between steps, trajectories to trace, budgets to enforce, and failures that do not reproduce the same way twice.

   Read chapter
3. 3

   Ship the workflow first, then instrument the fallback rate

   Fifty thousand invoices arrive nightly in three known layouts and someone proposes an agent in case a fourth appears. The answer is not refusal: build the deterministic version, route unmatched inputs to an explicit fallback branch, and count how often it fires. That measured rate converts a future-proofing argument into a decision, and the fixed graph makes retries, tests and approvals explicit in the meantime.

   Read chapter
4. 4

   Where the step list cannot be written before the run

   Some work genuinely defeats enumeration: diagnosing a failing test in an unfamiliar repository, where which file you open next depends on what the last one contained. This chapter draws that boundary honestly. What separates such tasks is not difficulty or open-endedness in the marketing sense, but that later steps depend on discoveries no designer could have scheduled — and recognising it keeps the criterion from becoming dogma.

   Read chapter
5. 5

   Model-controlled iteration fits inside one node of a fixed graph

   The choice is not whole-system and it is not once-and-for-all. When the fallback rate you were told to instrument comes back high, the move is almost never to rebuild the thing as an agent: scope the iteration to the single step that needs it — the unmatched layout, the receipt nobody can parse — and give that step its own tool set, token and step budget, timeout and deterministic fallback while every other node stays exactly as it was. The reachable state space remains enumerated everywhere else, so tests, retries and approvals keep working. This is what 'add the iteration later' has to mean in practice if the evidence you promised to collect is ever going to change anything.

   Read chapter
6. 6

   Non-determinism shows up in the spread, not in the average

   Matched prototypes on the same task give you more than a success percentage. Run identical inputs repeatedly and record the distribution of tool calls, tokens and latency, because the variance is usually what decides the question. Work the case where the agent scores 91% against the workflow's 88% but costs four times as much with a p95 six times worse, and name what would have to be true to reverse it.

   Read chapter
7. 7

   Reversibility and blast radius decide what a wrong action costs

   Auto-approving money under fifty dollars is an irreversible payment; a read-only summariser's worst case is a bad paragraph. This chapter supplies the two axes the decision record turns on that nothing earlier has taught: how reversible a wrong action is and how far its blast radius reaches, which together decide where an approval gate belongs and what it must show the approver. Auditability falls out of the same construction, since a fixed graph makes the record of what was decided a byproduct while a model-chosen trajectory makes it something you reconstruct afterwards. This is the argument that beats 'a workflow is cheaper to build'.

   Read chapter
8. 8

   A decision record that survives "it can't handle anything new"

   The recommendation has to hold up in a room. Write the record around path variability, tool-choice requirements, the latency budget, auditability and how safely a wrong action can be contained, then meet the flexibility objection by agreeing with it and naming the evidence that would change your mind. Take the expense-report case through this, including the single requirement that would genuinely flip you to an agent.

   Read chapter