Skip to main content

Module 1 — When several agents beat a single one

The previous course ended with a single agent that could think, use tools and stop on its own. It could also write a product page, review it and republish it — all inside one long system prompt. So why would anyone split that job across four separate agents? This module answers before we touch any code, because the wrong answer wastes an entire course.

The one experiment that reframes the question

Take the running project: a rough 800-word product brief that has to become a 10-page piece of documentation. Ask a single strong model to do it in one shot. You will get eight to nine pages of fluent prose, three of which quietly restate the same idea, one that invents a feature the brief never mentioned, and a title that does not match the file name convention the team uses.

Now split the job across four agents: an Analyst who lists what the brief actually contains, a Writer who drafts each section from that list, a Reviewer who cross-checks against a house style guide, and a Manager who arbitrates when the Writer and the Reviewer disagree. You will get the same ten pages, missing feature and all — except the Reviewer will flag the invention and the Manager will kill it before the Writer republishes.

The improvement is not fluency. Fluency was already there. The improvement is that a second pair of eyes belongs to a different agent, with a different goal, so it does not talk itself into being convinced by its own previous output.

Where specialisation genuinely pays

Three signals reliably predict that a crew will outperform a single agent, and they all come from the shape of the work rather than from any framework.

  • Distinct success criteria per step. The Analyst succeeds when its list of features is complete. The Writer succeeds when each section reads well. The Reviewer succeeds when contradictions are absent. Bundling these into one prompt forces the model to trade off criteria it should be optimising separately.
  • Different tools per step. The Analyst needs a file reader; the Writer needs almost nothing; the Reviewer needs a diff tool and access to the style guide. Attaching every tool to every step drowns the model in irrelevant options and multiplies wrong tool calls.
  • A checkpoint where a human might intervene. If the natural workflow contains a place where a person would say "hold, let me re-read", that is where two agents belong on either side of the checkpoint. One drafts, the other verifies against a source the first did not consult.

When none of the three signals is present, splitting is theatre. The classic mistake is asking two agents to "collaborate" on the same untyped chunk of text with the same tools — that is a single agent with a longer bill.

Where a single agent — or no agent at all — is better

The other honest answer is that many tasks in the wild look agent-shaped without being so. A one-shot classification, a translation, a summary of one document, a rewrite in a different tone — these are function calls dressed up as conversations. A well-prompted single model handles them, cheaper and more predictably than any crew.

Further down the stack, whenever the workflow is fully deterministic — extract three fields from a PDF, look them up in a database, email the result — a plain Python script beats every agent architecture that has ever been written. The cost is a hundredth, the failure modes are debuggable, and the output is reproducible byte for byte.

The right mental picture is a decision tree, not a preference. Deterministic flow → script. One judgement, one tool, one output → single agent. Multiple judgements with distinct criteria and cross-checks → crew.

The cost of the wrong choice

A crew that should have been a script is not just expensive — it is unreliable in a way that hurts the trust of everyone downstream. The Analyst is 96 % accurate, the Writer is 96 % accurate, the Reviewer is 96 % accurate, the Manager is 96 % accurate. Chained naively, the compound accuracy is roughly 0.96⁴ ≈ 85 %. Twice as many production incidents as the single agent, at four times the cost.

Going the other way is less dramatic but not free. A single agent that should have been a crew produces plausible content that quietly drifts from source truth. Nobody notices until an executive spots the fabricated feature on page seven and asks who signed off. The answer, in a single-agent setup, is nobody — because there was no signature.

The rule of the running project

Across this whole course, the four-agent crew earns its cost precisely because the Writer will never be trusted to review its own draft. If, at any module, you catch yourself giving the Writer a review tool "just to save an agent", stop — you have collapsed the crew back to a single agent with extra steps.

Summary

  • Splitting into a crew helps when steps have distinct success criteria, distinct tools, and a checkpoint where a human would intervene; otherwise it is theatre.
  • A one-shot judgement with one tool belongs to a single agent; a deterministic flow belongs to a plain script — pick each level knowingly.
  • Chaining four 96 %-accurate agents can compound down to roughly 85 %, so the crew has to buy back that loss with real cross-checks, not just repetition.
  • The Writer of our running crew is never trusted to review its own draft — that separation is what earns the multiplied bill.

Next module: writing an agent — role, goal, backstory and its own model choice — and instantiating the four members of our crew.