Loading lesson…
AI Agents / Agent Systems
When more than one agent helps, and when it hurts.
Reviewed by Yuvaraj
A single capable agent, one model, a focused system prompt, and a well-chosen set of tools, handles most tasks you will throw at it. Multi-agent systems only earn their complexity when one agent genuinely cannot: when the work splits into specialties that need different instructions, when a single context window can no longer hold everything, or when independent subtasks can run in parallel. This lesson is about recognizing those moments, picking a topology, wiring up communication, and staying honest about the overhead you take on.
There are three defensible motivations, and everything else is coordination cost you pay to get them.
If your problem does not clearly benefit from at least one of these, a single well-designed agent is almost always the better call.
| Topology | Shape | Best when |
|---|---|---|
| Orchestrator / supervisor | A lead agent plans, delegates to workers, and merges their results | The task decomposes into distinct specialist subtasks |
| Pipeline | Each agent's output becomes the next agent's input | Work has fixed sequential stages |
| Debate / critic | One agent proposes, another critiques and forces a revision |
Ask about this lesson, or about anything in AI. Answers cite the lessons they draw on.
Finished this lesson?
Mark it complete to earn XP, keep your streak, and schedule a review.
| Quality and error-catching matter more than latency |
| Blackboard / shared state | Agents read from and write to a common store | Loosely coupled agents contribute to one evolving artifact |
Agents coordinate through two mechanisms. The first is structured messages: a handoff carrying a defined schema, not free-form chat, so the receiver can parse it reliably. The second is shared state or memory: a blackboard that multiple agents read and update. Delegation is the orchestrator deciding which worker owns which subtask, then integrating what comes back. Keep messages typed and keep one authoritative store of truth, most multi-agent failures trace back to neither being true.
The handoffs look like this:
orchestrator -> researcher : {task: "find 5 credible sources on X", constraint: "primary or peer-reviewed"}
researcher -> orchestrator: {sources: [...], confidence: "low, mostly blog posts"}
orchestrator -> writer : {outline, sources}
writer -> orchestrator: {draft}
orchestrator -> critic : {draft, rubric}
critic -> orchestrator: {issues: ["claim in para 3 unsupported"], verdict: "revise"}
Where it fails: the researcher honestly flags confidence: "low", but if the orchestrator ignores that signal, the writer treats weak sources as authoritative and confidently states unsupported claims. The critic, if it was not given the sources, cannot catch the fabrication, so the error propagates all the way to the output. The fix is architectural, not a better prompt: carry the confidence flag forward, give the critic access to the sources, and loop back to research when confidence is low.
For a curious beginner
Think of a solo expert versus a small team. A team wins when the work truly divides into different skills that can proceed at once. For a quick, unified task, the meetings and handoffs of a team just slow everything down.
How it is actually used
Establish a single-agent baseline first. Add agents only when you hit a concrete wall: the context window overflows, one prompt is being pulled in conflicting directions, tools interfere with each other, or subtasks are truly independent. Every added agent is another prompt to maintain, another failure surface, and more tokens per run.
The underlying mechanism
Cost and latency roughly add across agents, and errors compound. If each of handoffs preserves correctness with probability , end-to-end reliability is about . At and , that is . More agents can mean lower reliability unless each handoff is validated.
Common mistakes
Stay honest about the hype
Claims that fleets of agents will "autonomously coordinate like a human organization" are best labeled EMERGING and are usually overstated. Reliable systems today keep coordination explicit and constrained, a fixed topology, validated handoffs, and hard step budgets, rather than hoping agents negotiate roles on their own.