Demo 8 is not a download. It is a map.
By now you have built six things. Each of them is a named pattern that the agent-engineering literature already has a word for, and the words are worth having — not to collect, but so you can say what you are building and hear when someone else's design does not fit their problem.
Two sources are doing the naming: Anthropic's Building effective agents and DeepLearning.AI's Agentic design patterns. This page puts their vocabulary next to code you have already run.
The distinction that comes before the patterns
Workflow: the steps are decided in advance, in code. A model runs inside some of them.
Agent: the model decides what to do next, and keeps deciding until it is finished.
Almost everything on this site is a workflow. Demo 2's server is a workflow —
analyze_tissue, then classify_tissue, in that order, because a person wrote
that order down. Demo 4 hands one bounded job to a subagent, which is a small
agent inside a workflow.
Workflows are predictable, cheap, and testable. Agents handle cases you could not enumerate. Most research software wants a workflow, and the common failure is reaching for an agent because it is the more interesting thing to build.
A question that settles it: can I write down the steps? If yes, write them down. A model that re-derives your procedure on every run is a model that can get it wrong on any run.
Five shapes, and where you have already met them
1. Prompt chaining
One step's output is the next step's input, with a fixed sequence.
analyze_tissue ──► classify_tissue
measurement label
You built it in: Demos 1 and 2. The chain is the same in both — what changed was whether the hand-off was checked. In Demo 1 the model carried numbers between steps in prose; in Demo 2 it passed a file path and a schema stood at each end.
Where it fails: silently, when a step's output is not what the next step assumes. A chain is only as good as the contract between links, which is why the schema mattered more than the sequence.
Add a gate between steps when a step can produce something the next one
should refuse to touch. Demo 7's usable check is exactly that.
2. Routing
Classify the request first, then send it to the handler built for it.
You built it in: Demo 4, without noticing. A subagent's description: line
is a router — the main agent reads the descriptions and picks. That is why a
vague description misroutes, and why the field is worth writing first.
Where it fails: when categories overlap, or when there is no honest default. A router with no "I don't know" branch will always pick something.
3. Parallelisation
Run several things at once, then combine. Two different reasons to do it:
- Sectioning — independent pieces of one job, done side by side. Twelve slides, twelve analyses, no interaction.
- Voting — the same job done several times, majority wins.
Where voting fails: when the error is systematic rather than noisy. The
fold-artifact slide from Demo 1 returns mild_injury at p=0.70 every single
time. Five votes give five identical wrong answers and a false sense of
agreement. Voting narrows variance; it cannot touch bias.
Use sectioning freely. Use voting only when you have reason to believe the failures are independent — and say out loud what that reason is.
4. Orchestrator–workers
A central agent breaks a job into pieces, hands each to a worker, and assembles the results.
You built it in: Demos 4 and 7. In Demo 7 the main agent is the orchestrator: it runs the analyst, takes the report, hands it to the verifier. The workers never talk to each other — the orchestrator passes artifacts between them, which is why results go to files.
Where it fails: when the orchestrator has to understand the domain to split the work sensibly. Splitting is a judgement call, and a bad split produces confident work on the wrong pieces.
It earns its place when steps must be sequenced or results combined and judged. Running N independent jobs and collecting the output is a loop, not an orchestrator — and a loop has no opinions to get wrong.
5. Evaluator–optimiser
One component produces; another critiques; repeat until the critique is satisfied.
You built it in: Demo 7 — and you also built the version of it that does not work. A critic that can redo the work usually agrees with the work. Demo 7's v1 verifier re-ran the analysis and confirmed a wrong answer; v2 could only compare the report against the files on disk, and rejected it.
The rule that makes this pattern work:
The evaluator must be able to fail differently from the producer.
Ask it of any reviewer agent you add: what can this see that the worker could not? If the answer is "nothing, it just looks again more carefully", you have added cost and a rubber stamp.
Where it fails: loops that never converge, and critics that are too agreeable to be useful — which is most of them, by default.
Three instruments people confuse
| what it does | catches | misses | |
|---|---|---|---|
| Verifier | compares a claim against a source of truth | systematic error, wrong claims, undisclosed caveats | anything the source of truth is also wrong about |
| Referee | decides between two components that disagree | cases where disagreement itself is the signal | errors both components share — silently |
| Vote | runs n times, keeps the majority | random variation | bias, completely |
All three get called "adding a check". Only one of them catches a model that is confidently wrong the same way every time.
Choosing
Put these in order and most designs answer themselves.
- Can I write the steps down? Yes → workflow. Stop here most of the time.
- Does one step need a model? Give it a schema, not a paragraph. (Demo 2.)
- Would a step flood my context, or need fewer tools than I have? Subagent. (Demo 4.)
- Would a wrong answer be quietly believed? Add a check — and decide what it may look at before you decide what model runs it. (Demo 7.)
- How will I know any of this is better? Repeated runs, an interval, and a comparison against the simpler thing you are replacing. If you skip this, you have a demo rather than a result. (Week 3.)
The failure mode worth naming
Agent designs get elaborate in the wrong place. More agents doing the work, more delegation, more orchestration — and still nothing that could have caught the answer being wrong.
The simplest arrangement that makes the failure visible.
Demo 7 is the smallest useful example: two agents, one of which does less than the other, and is the one that works.
Sources
- Building effective agents — Anthropic. The workflow/agent distinction and the five shapes above.
- Agentic design patterns — DeepLearning.AI.
- The eight design questions in Demo 4 §2A are the short version of this page, aimed at someone about to write their first subagent file.