Most people's experience with AI is a conversation with one assistant. ChatGPT, Claude, and similar products present one conversational partner. You ask it a question, it reasons, perhaps calls a few tools, and gives you an answer.
That experience creates a natural architectural instinct: if one agent is useful, make that one agent more capable. Give it better instructions. Connect more tools. Add more context. Increase its token budget. Upgrade the model.
That is the right place to start.
It is not an infinitely scalable place to finish.
At some point, the single agent is no longer doing one coherent job. Its instructions contain a job description, an organization chart, a workflow engine, a memory policy, a delegation policy, a review checklist, and a recovery procedure. Its context contains the request, the plan, intermediate evidence, failed attempts, tool results, and the agent's own conclusions about all of them. Its tool list spans several domains. It is asked to investigate, calculate, edit, criticize, validate, and finally approve its own work.
The architecture still looks simple because there is only one box labeled "agent." The complexity did not disappear. It moved inside the box, where it became harder to see, test, and govern.
This article is about what happens after that point.
The previous article reduced an agent to three parts: instructions, an LLM, and MCP tools. That remains the correct foundation. This article extends it with two arguments:
The practical pattern is to scale up one agent while simplicity remains an advantage, then scale out into a team when implicit coordination becomes the bottleneck.
The Model Context Protocol (MCP, spec 2025-11-25) is the interface layer between AI clients and external systems through tools, prompts, and resources. Throughout this series, we have treated MCP servers as the governed capability layer for enterprise AI: thin, remote, mostly stateless interfaces to internal systems and SaaS systems.
An agent is an MCP client with:
An agent team does not replace that model. It composes it recursively:
The result is not a new species of software. It is a scale-out architecture built from the same capability model.
Teams introduce real cost. A coordinator has to decompose work, select collaborators, wait for results, resolve conflicts, and synthesize an answer. Multiple agents consume more tokens and create more failure boundaries. Shared state needs ownership, permissions, and lifecycle rules.
For many tasks, none of that is justified.
Use one agent when the work is:
Before adding agents, scale up the single agent:
This follows the same principle used throughout the series: do not add probabilistic orchestration where a deterministic capability would be better. If server code can reliably perform a calculation or enforce a known workflow, use server code. A second agent is not a substitute for a well-designed tool.
But scaling up eventually reaches diminishing returns.
The ceiling is not a single model limit. Several pressures compound.
Context saturation
One agent must carry the plan, evidence, intermediate results, conversation history, and its own reasoning in one working context. A larger context window increases capacity, but it does not guarantee that every relevant detail receives the right attention at the right time.
Tool overload
A generalist agent needs more tools. The tool-design article showed that tool performance can fall off a cliff as the choice set grows. Dividing work across specialists lets each agent see a smaller, more relevant capability surface.
Role collision
Planning, execution, criticism, approval, and final communication require different behavior. Encoding all of them into one instruction set creates conflicting objectives: move quickly but verify everything, explore alternatives but remain concise, propose a solution but distrust it.
Sequential throughput
One agent explores one trajectory at a time. When a problem contains several independent research paths or checks, a team can work on them concurrently using separate contexts.
Path dependence
An early mistaken assumption shapes later reasoning. The same agent reviewing its own work sees the conclusion through the context that produced it.
Weak self-verification
Telling an agent to "double-check your answer" is useful, but it does not create an independent reviewer, an authoritative state boundary, or a requirement that validation succeed before completion.
These pressures explain why adding more instructions can make an agent worse. Each new rule may be sensible in isolation, but the complete prompt becomes a crowded control plane for responsibilities that should have explicit owners and interfaces.
Database architecture has long faced a similar decision: scale up one system while that remains economical, then scale out when the growing system crosses a complexity or capacity boundary. The same curve applies to agents.
The diagram is a conceptual architecture curve, not benchmark data.
The single-agent line begins lower. One prompt, one loop, and one deployment are hard to beat for a prototype. During initial growth, better instructions, a better model, and a curated toolset extend its useful range.
The team line begins higher because collaboration infrastructure must exist before the team can work well. Agents need contracts, shared artifacts, state ownership, memory boundaries, validation, status tracking, and governance.
The crossover arrives when keeping those concerns implicit inside one agent becomes more expensive and less reliable than representing them explicitly. Beyond that point, the team architecture can add specialized capacity without continually expanding one agent's prompt, context, and tool surface.
This is the important distinction:
A team is not cheaper because coordination disappears. A team becomes scalable because coordination is made explicit, reusable, and governable.
Scale-out is useful when a problem can be divided into bounded responsibilities.
Different agents can have:
A research agent can explore one branch while another explores a second branch. A finance agent can receive only finance tools and policy. A reviewer can inspect an artifact without inheriting every assumption made by its author. A coordinator can work from concise findings instead of carrying every raw document in its own context.
There is growing evidence that this helps for the right task shapes. Anthropic reported that its multi-agent research system outperformed its single-agent baseline by 90.2% on an internal research evaluation, especially for breadth-first queries with independent directions. The same report also says the multi-agent system used about 15 times as many tokens as ordinary chat and was a poor fit for work with tightly coupled dependencies. (Anthropic engineering)
A controlled study across 180 agent configurations found a similar boundary: centralized coordination improved performance substantially on parallelizable tasks in its benchmarks, while every tested multi-agent topology degraded performance on sequential reasoning tasks. (Towards a Science of Scaling Agent Systems)
The conclusion is not that more agents are always better. It is that teams raise the ceiling when the work benefits from partitioning, parallel exploration, specialization, or independent checking.
Multi-agent systems are often criticized for adding coordination overhead. That criticism is correct but incomplete.
A complex single agent also coordinates. It decides which responsibility it is performing, tracks intermediate state, remembers failed approaches, checks its evidence, manages its tool results, and decides whether its own answer is valid. The difference is that all of this happens implicitly inside probabilistic reasoning.
The choice is therefore not:
It is:
| Concern | Hidden Inside One Agent | Externalized In A Team |
|---|---|---|
| Responsibility | Sections of one large instruction prompt | Small role-specific instructions and agent contracts |
| Delegation | Internal reasoning about what to do next | Typed calls to selected collaborators |
| Working state | Conversation and model context | Named, durable artifacts with explicit owners |
| Prior attempts | Whatever remains salient in context | Append-only hypothesis or decision logs |
| Validation | The author checks its own conclusion | An independently instructed reviewer or referee |
| Mutation | Any reasoning step may silently revise the working answer | A designated writer validates and records changes |
| Long-running work | The caller waits or invents hidden state | Task identifiers, status, retry, cancellation, and results |
| Learning | More instructions added to the prompt | Scoped, searchable team memory |
| Failure analysis | Reconstruct the model's reasoning after the fact | Inspect calls, files, logs, status, and validation results |
Making coordination explicit does not make it free. It makes it addressable.
The engineering checklist becomes concrete:
Those questions are difficult to answer when their only implementation is prose buried in one system prompt. Once they are implemented as collaboration services, the investment can support many teams rather than one carefully tuned agent.
In an MCP-native platform, three shared services cover most of the collaboration substrate:
┌─────────────────────┐
│ coordinator agent │
└──────────┬──────────┘
│
┌─────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────────┐
│ team-mcp │ │ team-fs │ │ team-memory │
│ delegation │ │ artifacts │ │ semantic recall │
└──────┬──────┘ └──────┬──────┘ └────────┬────────┘
│ │ │
specialized agents shared case files reusable lessons
│ │ │
└─────────────────────┼───────────────────────┘
│
▼
domain MCP servers
│
▼
systems of record
The names matter less than the separation of responsibilities.
team-mcp
: The Coordination Plane
team-mcp
exposes selected agents as MCP tools.
A coordinator might see:
finance_checker
policy_reviewer
research_agent
independent_validator
Each agent has the same things a good MCP tool has:
From the caller's perspective, delegation remains ordinary tool use. The coordinator reads descriptions, selects the right capability, supplies the required context or artifact references, and reads the result.
This does not mean every agent should see every other agent. That would recreate the tool-overload problem at the team layer. team-mcp
should expose a small, role-appropriate roster to each caller. A lead agent may see administrative specialists; an evidence agent may see domain specialists; a writer may see only validated artifacts and the validator.
The team topology becomes a governed capability graph rather than an unrestricted group chat.
team-fs
: The Artifact Plane Agents often collaborate on durable work products and documents:
Passing all of that through tool-call payloads wastes context and creates brittle handoff chains. team-fs
gives the team a shared workspace. Agents exchange stable file or artifact references instead of repeatedly copying entire documents through the coordinator.
The filesystem should not be an ungoverned scratch directory. Useful conventions include:
The names of shared files effectively become a small business API for the team. evidence.md
, current_plan.json
, contradictions.log
, and final_report.md
communicate purpose more reliably than a collection of anonymous text blobs in model context.
team-memory
: The Semantic Context Plane Shared memory exists for information that should remain useful beyond one call or artifact:
Semantic search lets an agent retrieve the small subset relevant to its present work rather than the team's entire history.
But memory is not a system of record. It may be stale, incomplete, contaminated, or retrieved in the wrong context. A robust memory service needs:
Current task facts should normally remain in task state, artifacts, or systems of record. Memory can recall that "board updates require supporting evidence." It should not be treated as authoritative evidence that "Alice selected the science-fiction movie."
That separation prevents semantic memory from quietly becoming a shadow database.
The three collaboration services do not replace operational systems.
Customer state belongs in the CRM. Work status may belong in a ticket or case system. Approvals belong in an approval system. Financial truth belongs in financial systems. Agents should access those sources through governed domain MCP servers rather than recreate them in team memory or loose files.
Tasks cut across the architecture. When delegated work becomes long-running, retryable, approval-gated, or independently auditable, the caller should receive a task handle rather than block on a large hidden conversation. The experimental Tasks capability introduced in the MCP 2025-11-25 specification provides one protocol model for durable state, polling, deferred results, and cancellation. (MCP Tasks)
The durable task says what is happening. team-fs
holds the work products. team-memory
holds reusable learning. Systems of record remain authoritative for the business.
With that infrastructure in place, the recursive model from the previous article becomes practical:
Inside one governed MCP-native platform, a team of agents can be presented as an MCP server that exposes selected specialized agents as tools.
The important word is presented. The team is not literally only a server process. Behind that surface are agent runtimes, shared files, memory, tasks, domain systems, permissions, and observability. MCP gives all of them a consistent interface boundary.
This is why a dedicated agent-to-agent protocol may be unnecessary inside one MCP-native platform:
Cross-organization or independently administered agent ecosystems may have broader interoperability requirements. But inside one governed platform, the burden of proof should be on adding a second protocol, not on reusing the capability layer already in place.
Logic-grid puzzles provide a useful demonstration because they have exact answers and can grow in controlled increments.
Consider a movie-night puzzle. A small version has three people and three categories: which movie each person watched, which snack they ate, and where they sat. A harder version adds people, streaming platforms, arrival times, drinks, more clues, and longer chains of dependencies.
The canonical test ladder grows from:
| Difficulty | People | Categories | What Changes |
|---|---|---|---|
| Very easy | 3 | 3 | Basic smoke test |
| Easy | 4 | 4 | More assignments and platform ownership |
| Medium | 4 | 5 | Ordered arrival constraints |
| Hard | 5 | 5 | A fifth person and longer evidence chains |
| Very hard | 5 | 6 | Full stress case with cross-category dependencies |
The standalone agent receives one long instruction set covering intake, clue parsing, hypothesis testing, grid updates, validation, and final explanation. It can solve the smaller puzzles.
As the puzzle grows, a more dangerous failure appears than merely returning "I don't know." The agent can announce that it solved the puzzle while its answer violates a clue, assigns a value twice, or leaves an unsupported conclusion. Asking the same agent to review its work does not reliably fix the problem because the proposed solution and the assumptions that produced it share the same context.
The team uses the same underlying model capabilities, but distributes responsibility:
The collaboration infrastructure is not incidental to the result.
Through team-mcp
, the Lead Investigator calls these responsibilities as tools. Through team-fs
, the team shares explicit case artifacts:
clues.md
constraints.md
puzzle_grid.json
hypotheses.log
update_requests.log
contradictions.log
final_solution.md
final_proof.md
Through team-memory
, the team can retain reusable operating lessons such as "every board update requires clue IDs or an evidence summary." It deliberately does not store current grid assignments or temporary guesses as semantic memory. Current case facts belong in the case files.
The single agent is asked to remember, reason, mutate state, and validate itself. The team turns those responsibilities into separate contracts with an inspectable chain of evidence.
That is the capability crossover in concrete form. The individual agents are not magically more intelligent than the standalone agent. The system becomes more capable because it adds bounded contexts, explicit ownership, controlled mutation, durable state, and independent validation.
A later article will cover the full experiment: the team design, prompts, puzzle ladder, failure traces, repeated evaluations, and the cost of achieving the higher completion rate.
A multi-agent architecture should earn its overhead against a strong single-agent baseline.
For the puzzle experiment, a run succeeds only when:
The most revealing measurement distinguishes claimed success from actual success:
false_completion = declared_success && !actual_success
That captures the case where an agent crosses its capability ceiling without recognizing that it crossed it.
A serious comparison should also record:
Run each puzzle multiple times because model behavior is probabilistic. Compare both quality and economics. A team that improves completion by one percentage point at fifteen times the cost may be a poor design for a low-value task. The same cost may be trivial for a high-value investigation that the single agent cannot complete reliably.
The purpose of the crossover is to make the decision measurable, not ideological.
An agent team is a strong candidate when the work has several of these properties:
Keep one agent when:
And use neither architecture for work that should be deterministic. If a known algorithm, database query, workflow engine, constraint solver, or ordinary service can produce the answer reliably, put that capability behind an MCP server and let agents call it.
A practical decision sequence is:
The goal is not to maximize agent count. It is to choose the smallest architecture that reliably completes the task.
Exposing an agent as a tool does not weaken the security requirements from earlier articles. It adds new places to apply them.
For every agent capability, ask:
Shared collaboration services need their own controls:
team-mcp
enforces the allowed collaboration graph and delegation budgetsteam-fs
enforces role-based paths, ownership, and mutation rulesteam-memory
enforces scope, provenance, retention, and deletionTesting also moves up one level. Test each agent contract independently, then test the complete team on real scenarios. A specialist that performs well in isolation can still fail as a team dependency if its description is ambiguous, its output is difficult to consume, or the coordinator calls it at the wrong time.
Multi-agent systems do not escape MCP discipline. They multiply the reasons to apply it well.
Once the architecture is explicit, much of the market vocabulary becomes easier to place.
Supervisor/Router agent
An agent instructed to coordinate, review, or route work, with selected collaborators exposed as tools.
Sub-agent
A specialized agent called by another agent through a bounded capability contract.
Swarm
A label for a larger or more decentralized group of agents, often with overlapping capabilities and looser routing rules to execute in parallel.
The patterns may be useful. The names do not remove the need to define responsibilities, state, validation, permissions, and failure behavior. A vague swarm with no ownership is not more scalable than an overloaded single agent. It has merely distributed the ambiguity.
Tasks, artifacts, evidence, ownership, and validation make an agent team legible to humans as a useful side effect. A person can inspect a case file, approve a task, correct an artifact, or review a validation result without needing access to an agent's hidden prompt state.
That does not make this a human-agent collaboration article. The next step requires its own treatment:
A later article will extend this architecture into hybrid teams in which human experts and AI agents contribute different capabilities through the same tasks, artifacts, and governed interfaces.
Carry these principles forward:
Start with one agent.
It has the lowest coordination cost and is the right default for bounded work.
Do not confuse a simple diagram with a simple system.
Coordination hidden inside one prompt and context is still coordination.
Scale up before scaling out.
Improve instructions, models, tools, workflows, and deterministic services first.
Teams raise the ceiling for the right task shapes.
Specialization, parallel contexts, explicit ownership, and independent validation enable harder work.
The coordination tax exists either way.
Teams make it explicit so it can be tested, observed, governed, and reused.
Use team-mcp for delegation.
Use team-fs for working artifacts.
Use team-memory for reusable learning.
Measure the crossover.
Compare completion, false confidence, latency, tokens, and cost against a strong single-agent baseline.
Use the smallest architecture that completes the task reliably.
Sometimes that is deterministic software, sometimes one agent, and sometimes a governed team.
The scalable idea is not "more agents." It is the separation of responsibilities and state behind explicit interfaces.
Scale up while simplicity wins. Scale out when coordination becomes the bottleneck.
This article extended the capability-first model from one agent to a governed team. The rest of the series provides the layers underneath it and the next steps beyond it.