Single-Agent vs. Multi-Agent

One student can research, write, and proofread a report. A team can divide those jobs, but then it must communicate, coordinate, and resolve disagreements. Multi-agent systems have the same trade-off: specialization may help, while coordination creates new failure points.

Single agent: Goal → one agent → tools → result

Multi-agent:  Goal → coordinator → specialists → combined result
                         ↑              ↓
                         └── handoffs ──┘

What You Will Learn

• What changes when one agent becomes several specialized agents.
• How manager, peer, and handoff patterns divide responsibility.
• When specialization or separate contexts can justify multiple agents.
• How communication, duplicated work, conflicting decisions, cost, and failure propagation arise.
• Why a strong single-agent baseline should come before a multi-agent design.

A Real Multi-Agent Example

Anthropic has described a research system in which a lead agent creates a strategy, delegates parallel searches to subagents, and then combines their findings. This can help when independent research directions fit into separate context windows, but it also consumes more tokens and requires careful coordination. (Anthropic, How We Built Our Multi-Agent Research System)

The lesson is not “more agents are smarter.” It is: parallel specialists can help when the task naturally splits and the value justifies the coordination cost.

Every agent in this course so far has been one agent — one reasoning core, one loop, one accumulating state. That’s been a deliberate choice, not an oversight, because understanding a single agent properly is the correct foundation before adding more of them. This module is a bridge, not a destination: it introduces why and when a task might benefit from several agents working together, and it’s honest about the real cost that benefit comes with.

The actual mechanics of coordination — how agents communicate, hand off work, share or don’t share state, and recover when one of them fails — is substantial enough to be its own dedicated subject, and that’s exactly where the next stage of this learning path picks up. This module’s job is narrower: give you the right instinct for recognizing when that deeper subject is even worth reaching for.

When one agent starts to strain

Recall Module 3’s architecture — one agent core, reasoning and planning, with tools and knowledge feeding into a shared environment. This works cleanly as long as the agent’s job stays coherent. Now imagine asking a single agent to research a technical topic, write a polished report about it, and rigorously critique that report for factual accuracy — all as one undifferentiated responsibility. Nothing about the agent loop from Module 4 structurally prevents this.

But three different kinds of work are now sharing one context, one toolset, and one reasoning process: research needs broad, exploratory tool use; writing needs a completely different kind of judgment about clarity and structure; critique needs a skeptical posture toward the very output the same reasoning process just produced.

Module 3’s context-assembly concerns and Module 5’s “fewer, more distinct tools beat many overlapping ones” lesson both start to strain under this kind of breadth — not because the agent loop is broken, but because one agent is now doing the job three different specialists might do better separately.

The two shapes, side by side

Single agent

Goal → Agent → Tools

Multi-agent

              Research Agent
             /
Goal → Manager
             \
              Writing Agent

A single agent, as covered throughout this entire course, pursues one goal with one reasoning process. A multi-agent system splits that same overall goal across several agents, each with a narrower role, coordinated in some way — here, through a manager agent that delegates subtasks to specialists and integrates their results. It’s worth naming this specific shape, since it’s the simplest and most common starting point: one coordinating agent, several specialized agents beneath it, no peer-to-peer communication between the specialists themselves.

Other coordination shapes exist — agents communicating directly with each other, layered hierarchies of managers coordinating other managers — and those are exactly the subjects the next stage of this learning path covers properly. This module sticks to the simplest shape specifically because it’s enough to reason clearly about the actual trade-off, without needing the full coordination taxonomy first.

Why specialization can help

The core argument for splitting an agent’s responsibilities across several specialized agents is directly an extension of ideas you already know. A research-focused agent can have a narrower, more coherent toolset — search and retrieval tools, nothing about writing style. A writing-focused agent’s context can stay focused on the research findings and the target audience, without carrying the noise of every search query that produced them.

A critique agent, separate from the agent that produced the original output, brings a real, structural form of independence — the same reasoning process that wrote something is generally worse at finding its own flaws than a separate process would be, which is directly why Module 6’s reflection and verification concepts are often more effective when performed by a distinct agent rather than the same one grading its own work.

You’ve already seen this benefit realized in a real system. Novo Nordisk’s “Co-Scientist” architecture, covered in Module 13, deliberately splits clinical data analysis from external literature consultation across specialized agents working together, rather than one broad agent handling both — precisely because these are different kinds of work, each benefiting from a narrower, more focused context and toolset. eSentire’s Atlas platform does the same for security operations, with “task-specific Atlas Agents” investigating threats rather than one undifferentiated agent handling the entire incident-response lifecycle. Both are real, production systems where specialization was a, deliberate design choice, not complexity added for its own sake.

Why it costs more

None of this is free, and it’s worth being as honest about the cost as this course has been about every other trade-off. More agents means more LLM calls for the same underlying task — a, direct increase in cost and latency, since each agent’s reasoning step is a full model call, and coordination between agents adds calls beyond what a single agent’s loop would have needed.

real communication overhead exists between agents — one agent’s output becoming another’s input is an extra step that a single agent’s internal reasoning wouldn’t have needed at all. Shared state, when multiple agents need visibility into the same evolving task, is more complex to manage correctly than Module 7’s single- agent state — who owns the authoritative version of a shared fact when two agents might update it?

And debugging becomes harder: when a multi-agent system produces a wrong outcome, determining which agent’s reasoning caused the problem requires tracing across several agents’ individual traces, not just one — a real, direct extension of Module 12’s observability challenge, now multiplied across however many agents are involved.

This is worth stating as plainly as Module 8 stated its own version of this trade-off: a task well-suited to one well-designed agent can perform worse when artificially split across several, purely from this overhead, with no compensating benefit — because the task never needed the specialization in the first place. More agents is not automatically more capable, any more than more autonomy was automatically better in Module 9, or more workflow structure was automatically safer in Module 8.

A practical test for whether the split is worth it

Given both sides of this trade-off, it’s worth having something more concrete than “it depends” to apply. Ask first whether the subtasks involved are, meaningfully different in kind — not just different in topic, but requiring different tools, different context, or a different reasoning posture, the way research, writing, and critique do. If the subtasks are all fundamentally the same kind of work, applied to different inputs, a single agent looping through them is very often the better choice — splitting identical work across multiple agents adds coordination cost without adding specialization benefit.

Ask second whether independence between agents is valuable for this specific task — a critique agent’s value comes directly from not sharing the same reasoning process (and therefore the same blind spots) as the agent it’s reviewing; this kind of independence is worth real coordination overhead specifically when Module 6’s honest warning about a model reviewing its own output applies.

And ask third — this is the practical, Module 8-style question worth asking before anything else — whether the value of specialization outweighs the real, concrete cost of more calls, more coordination, and harder debugging for this specific task’s actual stakes. Novo Nordisk’s clinical research and eSentire’s security operations both involve high-stakes, high-value outcomes where that overhead is clearly worth paying. A simpler, lower-stakes task might not clear that same bar.

Applying this to a concrete scenario, all the way through

Let’s run the three-part test above against the research-write-critique example, rather than leaving it abstract. A team is building a system to produce technical documentation summaries for a developer audience.

Are the subtasks different in kind? Research means searching and synthesizing scattered technical sources — an exploratory, broad-toolset task. Writing means shaping synthesized findings into something readable for the target audience — a narrower, more stylistically-focused task with little need for search tools at all. Critique means evaluating the written output against the original sources for factual accuracy — a verification task, structurally closer to Module 6’s reflection concept than to either of the other two. These are, meaningfully different kinds of work, not the same work applied to different topics — the first part of the test passes.

Does independence between agents matter here? Yes, specifically for critique — Module 6 already established that the same reasoning process reviewing its own output tends to share the same blind spots that produced the output in the first place. A separate critique agent, with no stake in defending the writing agent’s choices, brings real, structural independence a single agent reflecting on its own work cannot fully replicate.

**Does the task’s value justify the real overhead? ** This depends entirely on stakes and volume, and it’s worth being honest that the answer could reasonably go either way. For documentation that ships to paying customers at real scale, the coordination cost of three agents is very likely justified by the quality improvement, particularly the independent critique step catching real errors before they reach a reader.

For a single, low-stakes internal draft reviewed by a human anyway, a single agent looping through research, draft, and a built-in self-check step might be the better, cheaper choice — the human review already provides the independence a separate critique agent would otherwise add.

Notice what this exercise demonstrates: the test doesn’t produce one universal answer for “documentation generation” as an abstract task category. It produces a, context-dependent answer that changes based on stakes and volume — exactly the same judgment Module 8 asked you to apply to workflows versus agents, now applied one level up, to single agents versus multiple.

Why our own recurring agent never needed this split

It’s worth noticing, briefly, why the Customer Support Resolution Agent that’s run through this entire course never once needed to become a multi-agent system, because the absence is as instructive as the presence would be. Its work — checking an account, checking payment history, checking a gateway, deciding on an action — is the same kind of work throughout: sequential, dependency-driven investigation, where each step’s tool and reasoning style stays consistent with the others.

There’s no distinct “different kind of work” to specialize, and no obvious independence requirement — nothing here resembles the critique-agent case above, where a separate reasoning process catches what the original one would miss.

Running this module’s three-part test against it honestly returns a clear “no” on all three questions, which is exactly why a single, well-designed agent has been the right architecture for it from Module 1 onward — not an oversight this course was building toward correcting, but the correct answer for this particular task all along.

Why debugging gets harder, concretely

It’s worth making the debugging cost from earlier in this module less abstract. Imagine the three-agent documentation system above produces a summary containing a subtle factual error the critique agent should have caught but didn’t. In a single-agent version of this same pipeline, Module 12’s tracing gives you one sequential record to review — research, draft, self-check, in order, within one agent’s accumulated state.

In the three-agent version, you now need to determine which of three separate things happened: did the research agent retrieve something subtly wrong in the first place, did the writing agent introduce an error while paraphrasing correct research, or did the critique agent fail to catch an error that was present in what it reviewed?

Each of these points to a different agent needing attention, and distinguishing between them requires cross-referencing three separate traces against each other — a different, harder diagnostic task than reviewing one agent’s single, linear record, and a direct, concrete illustration of why this module treated “harder debugging” as a real cost, not a minor inconvenience.

What this module deliberately isn’t covering

It’s worth being explicit about the boundary here, because this module has only scratched the surface on purpose.

How agents in a multi-agent system communicate with each other, the different coordination patterns beyond the simple manager-delegate shape shown above — peer-to-peer coordination, hierarchical delegation, parallel versus sequential execution — how shared state gets managed correctly when multiple agents need consistent visibility into it, and what happens when one agent in a coordinated system fails or is compromised (a extension of Module 11’s agent-to-agent trust concern) are all real, substantial subjects.

Covering them properly, with the same depth this course has given every single-agent concept, is exactly what the next stage of this learning path exists to do. This module’s job was narrower and, hopefully, now accomplished: giving you the instinct to recognize when that deeper subject is worth reaching for, rather than defaulting into multi-agent complexity because it sounds more sophisticated than the single, well-designed agent this entire course has spent thirteen modules teaching you to build well.

Numbered Comparison: Does Another Agent Earn Its Cost?

Suppose a single research agent completes a report in 8 minutes using 40,000 tokens and scores 78 out of 100 on a fact-check evaluation.

1. A proposed multi-agent version uses three research agents plus one coordinator.
2. Parallel research reduces elapsed time to 5 minutes.
3. Total token use rises to 110,000 because agents repeat background reading and exchange summaries.
4. The fact-check score rises to 88 because independent searches find more supporting evidence.
5. If accuracy is critical and the extra cost is acceptable, the split may be worthwhile.
6. If a score of 78 already meets the requirement, the single agent remains simpler, cheaper, and easier to debug.

These numbers are illustrative, not vendor benchmark results. They show the measurements a team should compare using its own tasks.

Common Misconception

Incorrect idea: Several agents automatically produce a better answer than one agent.

Why it is incorrect: Multiple agents can repeat work, pass incomplete summaries, disagree, and multiply cost. They help when work separates cleanly and coordination produces a measurable improvement.

Key Takeaways

• A single agent starts to strain when it’s asked to handle several distinctly different kinds of work — different tools, different context needs, different reasoning postures — within one undifferentiated loop.
• Specialization’s real benefit is a narrower, more coherent context and toolset per agent, plus independence for tasks like critique, where the same reasoning process reviewing its own output is structurally weaker than a separate one would be.
• Novo Nordisk’s Co-Scientist system and eSentire’s task-specific Atlas Agents are both real, production multi-agent systems where specialization was a deliberate, justified choice — not complexity added for its own sake.
• Multi-agent systems cost more: more LLM calls, real coordination overhead, harder-to-manage shared state, and debugging that requires tracing across several agents’ traces instead of one.
• A task in practice well-suited to a single, well-designed agent can perform worse when artificially split across several agents, purely from coordination overhead, with no compensating benefit.
• The real test for whether a split is worth it: are the subtasks different in kind, does independence between them matter, and does the task’s actual value justify the real, concrete overhead multi-agent coordination adds.
• This module deliberately stayed at the conceptual level — real coordination patterns, communication mechanics, shared-state management, and agent-to-agent trust are covered in full depth in the next stage of this learning path.

Think Like an AI Engineer

• Take the research-write-critique example from this module and argue the other side: under what circumstances would a single, well- designed agent looping through all three steps sequentially outperform three separate, coordinated agents?

• Novo Nordisk’s Co-Scientist system splits clinical data analysis from literature consultation. Using this module’s three-part test, justify why that specific split is worth the coordination overhead, rather than just asserting that specialization is generally good.

• Design a simple task from your own domain that would perform worse if artificially split across multiple agents. Be specific about which of this module’s cost categories — extra calls, coordination overhead, shared-state complexity, harder debugging — would hurt the most.

• This module mentioned that debugging a multi-agent failure means tracing across several agents’ individual traces rather than one. Sketch, at a high level, what additional information beyond Module 12’s single-agent tracing you’d want captured to make that cross-agent debugging tractable.

Module 15 closes this entire course with the question that’s been building since Module 1: given everything you now know — workflows, agents, autonomy, security, evaluation, and now the cost of multiple agents — how do you decide, for a real task in front of you, what to build? A complete, practical decision framework, and this course’s closing principle: use the least autonomous architecture that reliably solves the problem.