Agentic Workflows: The Five Patterns and Where Each One Breaks
An agentic workflow rarely fails inside a step. It fails at the hand-off, where one step treats the previous step's output as fact. The reliable ones put a written contract, and a check that enforces it, on every arrow between the steps.
The example in this article is a composite scenario built from patterns common to procurement operations. It is not a single real organisation. Its figures come from a seeded simulation published with the article, and are illustrative.
A manufacturer's procurement team built a four-step workflow to onboard new suppliers. A model read the supplier's registration form and extracted the legal name. A screening tool searched the company's restricted-party list for that name. A second model assigned a risk tier. A third drafted the approval note, and a fourth critiqued the draft before it went to the buyer.
Each step was tested before launch. Extraction scored 200 out of 200 on a test set of recent forms. The screening tool returned the right answer for every name it was given. The router matched its labelled tiers 96.7% of the time, and the critic passed every note. Six weeks after launch, an internal audit sample found two approved suppliers whose legal entities were on the restricted list.
No step had malfunctioned. The extraction model had read the trading name from the header of an older form layout, the screening tool had correctly found no match for that name, the router had correctly treated "no match" as clear, and the note had accurately said so. The failure lived in the three arrows between the steps, which nobody had tested because nobody had written down what crossed them.
What "agentic workflow" means, and why the term points at the wrong place
Two vocabularies are in common use, and they describe the same territory from different sides.
Anthropic draws the line most practitioners now use. Workflows are systems where language models and tools are orchestrated through predefined code paths; agents are systems where the model dynamically directs its own process and tool use. Both are "agentic systems" (Anthropic, 2024). The same article names five workflow patterns: prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer.
Andrew Ng's four agentic design patterns came earlier the same year, from the model's side: reflection (the model examines its own work to improve it), tool use, planning (the model comes up with and executes a multistep plan) and multi-agent collaboration (Ng, 2024). His case for them was a coding benchmark: GPT-3.5 answered 48.1% of HumanEval problems correctly zero-shot, and up to 95.1% when wrapped in an agent loop, more than the gap to GPT-4's 67.0% zero-shot.
Both framings put the attention on the steps: what each model call does, and how much better iteration makes it. That is where the capability comes from. It is not where the risk sits. In a chain, each step's input is another step's output, and every arrow carries an assumption about what that output means. Whether you should be building a workflow or an agent at all is a separate question, covered in Agent, Workflow, Automation or RPA?. This article assumes you have chosen a workflow and need it to hold up.
The test: draw your workflow as boxes and arrows. For each arrow, write one sentence saying what the receiving step assumes about what it receives. Any arrow you can't write a sentence for is untested.
Why testing each step feels like enough
Per-step testing is how the work is organised. Each step has an owner, a prompt or a tool, and a test set that owner can build. The extraction owner labels forms; the routing owner labels tiers; the note's owner writes a rubric. Each test answers a fair question about one step, and each score is real.
It also matches how ordinary software is tested, where a unit that passes its tests can be trusted by the units that call it. That trust works because a function's contract is enforced by types and assertions, so a wrong input fails loudly. A model step has no such contract. Hand it the trading name instead of the legal name, and it carries on without complaint, because a trading name is a perfectly good string.
The scores also mislead in a specific way. Each step is scored against its own input, so a step that faithfully processes a wrong input scores as correct. The onboarding team's four scores multiply to 96.7%, which reads like an end-to-end estimate. It isn't one. The figure that mattered, how many suppliers were screened against the right legal entity, was 91.9%, and no per-step test could have produced it.
The test: find the number your team reports for the workflow as a whole. If it was computed from per-step scores rather than measured on whole cases, it describes the steps, not the workflow.
Where the chain actually breaks: three hand-off failures
Three mechanisms account for most hand-off failures, and the onboarding chain had all three.
A plausible wrong value is consumed as fact. The extraction step returns a string that is well formed and wrong. Nothing downstream can tell, because nothing downstream compares it with anything. Schema validation doesn't help: the trading name passes every format check the legal name passes.
"Nothing found" collapses into an answer. The screening tool searched for a name and found no match. Its interface had two outcomes, listed and clear, so "I didn't find this entity" became "this entity is clean". A lookup that can miss needs a third value, and a step downstream that knows what to do with it. This failure is easy to build in, because two-valued interfaces are the default, and it is a data-design problem before it is a model problem.
The checker shares the generator's blind spot. The critic was asked whether the note was complete and professional. It was. The critic had no access to the screening record, so it couldn't check the note's one claim that mattered. This is the weakness in reflection without outside evidence: researchers found that language models struggle to correct their own reasoning without external feedback, and that performance sometimes degrades after self-correction (Huang et al., 2024). An evaluator loop is only as good as the evidence the evaluator can see.
Errors also compound along a chain, and the arithmetic is unkind. As an illustrative calculation, five steps that are each right 95% of the time, with independent errors, are all right together only about 77% of the time (0.95⁵ ≈ 0.774). Anthropic names "the potential for compounding errors" as one of the costs of autonomy (Anthropic, 2024). Real errors are usually not independent, which can make things better or worse. In the onboarding chain they were perfectly correlated: one bad extraction decided the next three steps.
The test: for each step that calls a tool or a lookup, list every outcome it can return, including "not found", "timed out" and "partial". If any of them is reported to the next step as one of the normal answers, you have found a hand-off failure.
The onboarding chain, walked through one supplier
Take one supplier from the composite. Its form is the older layout, which prints the trading name in the header and the registered legal name in a box further down. Here is the hand-off at each arrow, as built.
Arrow | What the next step assumed | What it received |
Extract → screen | The name is the registered legal name | The trading name from the header |
Screen → route | clear means the entity was screened and is not listed | clear, meaning no match for the trading name |
Route → note | The tier reflects a completed screening | low, from a screening that never happened |
Note → critic | The critic can check the note's claims | A note and a rubric, with no screening record |
The discovery move that would have caught it is a question to ask at intake, before any prompt is written: what key does the restricted-party list match on, and how does the form give it to us? The list is keyed on the registered legal entity. The form carries a company registration number. The team had extracted a name, the weakest identifier on the page, because a name is what a person would read first. Commercial screening services match aliases and fuzzy spellings, which would have narrowed this failure without removing it: any search that can miss still needs a way to say it missed.
The fix was a contract on each arrow, and a check that enforces it.
def screen_gated(s, name, registry):
"""Look up the registration number, confirm the name, then search.
'not_found' and 'name_mismatch' are their own answers, not 'clear'."""
entity = registry.get(s["reg_no"])
if entity is None:
return "not_found"
if entity != name:
return "name_mismatch"
return "listed" if name in WATCHLIST else "clear"
The router gained a precondition (a low tier requires a verified clear), and the critic received the screening record and a rubric that checks the note's claims against it. The published simulation runs the same 1,000 composite suppliers through both versions, with identical random draws:
== per-step evaluations (as built, before launch)
step 1 extract 200 recent forms, field accuracy 100.0%
step 2 screen correct for the name it is given 100.0%
step 3 route tier matches its inputs 96.7%
step 4 critic notes passed 100.0%
product of the four 96.7%
== as built: no gates between steps
forms on the older layout 127
step 1 extraction accuracy (legal name) 91.9%
wrong name: trading name 69
wrong name: misread character 12
marked 'clear' without screening the 81
legal entity
listed suppliers 17
listed suppliers approved 2
sent to a person 0
== with hand-off gates
step 1 extraction accuracy (legal name) 91.9%
marked 'clear' without screening the 0
legal entity
listed suppliers 17
listed suppliers approved 0
sent to a person 81
(Excerpt of output.txt. The full output also prints the supplier count, the older-layout count and a "screened against the right entity" line for each run.)
Two things in that output carry the argument. First, the gates didn't make extraction any better: it is 91.9% in both runs. They made its failures visible, by turning 81 silent false clears (69 trading names and 12 misread characters) into 81 cases a person looks at. Second, the extraction test set scored 200 out of 200 because all 200 forms were the current layout. The older layout was 127 of the 1,000 real forms, and none of the test set. The per-step test wasn't wrong; its data was unrepresentative, which no amount of prompt work would have revealed.
Routing 81 of every 1,000 suppliers to a person is a real cost, and it is the right first state. It tells the team exactly which forms the extraction step can't read, which becomes the test set for the extraction fix. The queue should shrink as extraction improves; the gate should stay.
The test: pick ten whole cases that went through your workflow last week, including at least two from your oldest or messiest input source. Trace each one arrow by arrow against the table above. Count how many hand-offs held.
The five patterns, and the gate each one needs
Each of Anthropic's five patterns has a characteristic hand-off failure. Knowing which pattern you are running tells you where to put the check.
Pattern | Who decides the next step | Where it breaks | The gate that belongs there |
Prompt chaining | Code: fixed sequence | A plausible wrong value is passed on as fact | Check each output against an independent source or identifier, not just its format |
Routing | Code, from a model's classification | A misrouted case lands in a specialist that handles it confidently | A route for "none of these"; the specialist checks its own precondition; accuracy measured per route |
Parallelization (sectioning or voting) | Code | Voters share a blind spot and agree on the same wrong answer; merged sections contradict each other | Diverse inputs or models for voting; a conflict check when sections are merged |
Orchestrator-workers | A model breaks down the task | A subtask is never created, and the synthesis looks complete | A coverage check against a required list of subtasks, run in code |
Evaluator-optimizer | A model loop | The critic can't see the evidence and passes plausible work | Give the critic external evidence (test results, source records); cap iterations; track first-pass vs final pass rates |
Prompt chaining is the pattern Anthropic describes with an explicit "gate": programmatic checks on intermediate steps to ensure the process is still on track (Anthropic, 2024). The other four need the same idea, applied where their hand-offs are.
Routing deserves a note, because its failure is quiet. A router that sends 3% of cases to the wrong specialist produces outputs that look like that specialist's normal work. Measure accuracy per route, from a labelled sample, and give the router somewhere to send what doesn't fit. A "none of these" route that is never used usually means the router is forcing cases into categories, not that every case fits.
Orchestrator-workers is the pattern closest to an agent, because a model decides what the subtasks are. Its characteristic failure is absence: the research task that never got assigned, the clause that was never reviewed. You can't catch an absence by checking what was produced. Keep a list, in code, of what any complete answer must cover, and check the synthesis against it.
Once a model decides more than the subtasks, the choice is no longer between workflow patterns but between architectures. AI Agent Architecture: Components, Patterns and How to Choose covers that choice, and where the system's state should live.
Evaluator-optimizer is Ng's reflection pattern with the critic split out, and it is the one most often trusted too far. A critic that only reads the draft checks style and internal consistency. A critic that reads the draft and the evidence (the test output, the source record, the retrieved document) checks truth. If the loop's pass rate is near 100% on the first iteration, the critic is probably not checking anything that matters.
The test: name the pattern behind each multi-step feature you run, then check whether the gate in that row exists. Most teams find the routing and evaluator rows missing first.
How to check your own workflow
Five observable checks will tell you whether a workflow's hand-offs are under control. Each can be answered from artefacts you already have.
Every arrow has a written assumption. Count the arrows on your diagram and the sentences in your design doc. They should match.
No lookup can return "not found" as a normal answer. Read the return values of every tool and retrieval step.
Every critic or judge can see evidence, not just the draft. Read its prompt and the inputs passed to it.
There is an end-to-end metric, measured on whole cases. Not a product of per-step scores. A labelled sample of at least a few dozen complete cases, re-run when any step changes.
The test set includes your worst input source. List your input sources by volume, and check that each appears in the step test sets in roughly that proportion.
A workflow that fails check 4 is the urgent case: you don't know how often it is right. Evaluating AI Agents covers how to build that sample and size it for the decision it informs.
The hand-off contract: a method
The method takes one working session per workflow, with the owner of each step in the room, and produces a contract table the team can test against.
Draw the chain as it runs, not as it was designed. Boxes for steps, arrows for every value that crosses between them. Include tool calls and lookups as their own boxes. Done when each owner agrees their step is drawn correctly.
For each arrow, ask the receiving step's owner what they assume. Write each assumption as a checkable statement: "the name is the registered legal name", "the tier reflects a completed screening". Done when every arrow has at least one statement.
Ask the discovery question for each assumption: what data proves it? An independent identifier, a source record, a count, a required list. This is where the onboarding team found the registration number. Done when each statement names the data that would confirm it.
Turn each statement into a gate, and decide what happens when it fails. Retry, route to a person, or stop. Give "unknown" its own value everywhere it can occur. Done when each arrow has a gate and a failure route, and no failure route is "carry on".
Measure end to end. Run a labelled sample of whole cases through the workflow, including your worst input source, and record the end-to-end rate and the size of each failure route. Done when the number exists and is re-run whenever a step changes.
The output is a table with one row per arrow: producer, consumer, assumption, evidence, gate, failure route. It doubles as the test plan for the workflow, and as the starting point for the boundary tests described in How to Test an AI Agent, which apply equally to the tool steps inside a workflow.
Tradeoffs and exceptions
Gates cost latency, money and, when they route to people, staff time. The question is which costs buy reliability where it matters.
Option | Gains | Costs | Best suited for | Warning signs |
No gates; per-step tests only | Fastest to build and run | Failures pass silently to the end | Drafts a person always reviews in full | Nobody can say how often the workflow is right |
Code gates on every arrow | Cheap, fast, deterministic | Only checks what can be expressed as a rule | Anything with an identifier, schema or record to compare against | Gates that check format but not truth |
Model judge between steps | Can check meaning, not just shape | Adds a model call and its own error rate | Free-text outputs with no source record | A judge with no evidence in its context |
Route uncertain cases to a person | Turns silent failures into visible work | Staff time; queue can grow | High-consequence outcomes (money, compliance, customers) | The queue grows and nobody fixes the upstream step |
Redesign as an agent | Handles paths you can't predict | Far larger test surface | Genuinely open-ended tasks | Chosen because the workflow's failures were hard to find |
The main exception: if a person reads every output in full before anything acts on it, the person is the gate, and per-step tests plus an end-to-end sample may be enough. Watch the edit rate. When people stop changing drafts, they have often stopped reading them.
Gates also matter less on reversible, low-consequence outputs, such as an internal summary nobody acts on. They matter most where an output triggers an action, which is why tool contracts apply the same idea to the arrow between a model and the tool it calls.
How the gates themselves fail
A gate is code, and it fails in predictable ways.
Checking format instead of truth. A JSON schema check on an extracted field confirms it is a string. Only a comparison with an independent source confirms it is the right string.
A failure route that nobody owns. The 81-case queue only helps if someone works it and feeds what they find back to the extraction owner. Give the queue an owner and a weekly count.
Gates that get loosened under pressure. When the queue grows, the easy fix is to relax the check. Track how often each gate fires; a gate whose firing rate drops suddenly has probably been changed, not satisfied.
The end-to-end sample goes stale. Input sources change: a new form layout, a new supplier country. Re-draw the sample when the input mix changes, not only when the prompts do.
What to do next
Pick the workflow whose output most often triggers an action without a person reading it. Run step 1 and step 2 of the method with its step owners this week: draw the chain and write one assumption per arrow. Then run the "not found" check against every tool step: list each one's possible outcomes and how the next step reads them. It takes an hour, and it is the quickest way to find out whether your workflow can report "clear" for something it never checked.
Final takeaway
The capability of an agentic workflow comes from its steps; its reliability comes from its hand-offs. Write down what crosses each arrow, check it with evidence the next step couldn't fake, give "unknown" its own answer, and measure the workflow on whole cases. A chain of well-tested steps with untested arrows is an untested chain.
Sources
Anthropic (Schluntz, E. and Zhang, B.), Building effective agents, 19 December 2024. Workflows vs agents; the five workflow patterns; programmatic "gate" checks in prompt chaining; compounding errors.
Ng, A., Four AI Agent Strategies That Improve GPT-4 and GPT-3.5 Performance, The Batch, DeepLearning.AI, 20 March 2024. The four agentic design patterns; HumanEval results (48.1%, 67.0%, up to 95.1%).
Huang, J., Chen, X., Mishra, S., Zheng, H. S., Yu, A. W., Song, X. and Zhou, D., Large Language Models Cannot Self-Correct Reasoning Yet, ICLR 2024. Self-correction without external feedback.
Frequently Asked Questions
What are agentic workflows?
An agentic workflow is a multi-step process in which one or more steps are done by a language model: reading a document, classifying a request, calling a tool, drafting or critiquing an answer. In the narrow sense Anthropic uses, the path between the steps is fixed in code; when the model chooses its own steps, it is an agent.
What are the main agentic workflow patterns?
Anthropic describes five: prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer. Andrew Ng's four agentic design patterns (reflection, tool use, planning and multi-agent collaboration) describe the same territory from the model's side.
How do you test an agentic workflow?
Test each step, then test every hand-off: write down what each step assumes about the output it receives, turn each assumption into a check that runs between the steps, and measure the workflow end to end on a labelled sample. Per-step scores alone can all be high while the chain fails.
Part of the Agent Engineering curriculum: eight paths from prompts and context to testing, evaluation and governance.
