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:

  1. A single agent has a capability ceiling. For sufficiently complex, decomposable work, a team can scale beyond that ceiling through specialization, separate contexts, parallelism, and independent validation.
  2. A team pays a coordination tax. But that tax exists in a single-agent system too, hidden in an increasingly confusing prompt and volatile context. MCP lets us externalize it into explicit, reusable collaboration infrastructure.

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.

What Is MCP? (The 30-Second Version)

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:

  • instructions describing its job and boundaries
  • an LLM providing reasoning and language capabilities
  • selected MCP tools connecting it to the outside world

An agent team does not replace that model. It composes it recursively:

  • a specialized agent can be exposed as an MCP tool
  • another agent can discover and call that tool
  • shared collaboration services can also be exposed through MCP

The result is not a new species of software. It is a scale-out architecture built from the same capability model.

A Single Agent Is The Right Place To Start

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:

  • short
  • mostly sequential
  • contained within one context
  • served by a small, coherent toolset
  • easy to validate directly
  • not valuable enough to justify additional inference and infrastructure cost

Before adding agents, scale up the single agent:

  • improve its instructions
  • use a stronger model where the economics make sense
  • reduce and clarify its tools
  • move deterministic computation into MCP servers
  • package repeatable workflows as prompts
  • give long-running work an explicit task lifecycle

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 Single-Agent Ceiling

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.

The Agent Scaling Dilemma

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 Agent Scaling Dilemma: a single agent starts cheaply but its hidden coordination cost rises sharply, while an agent team requires more initial investment and then scales more gradually

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.

Teams Scale Reasoning Out

Scale-out is useful when a problem can be divided into bounded responsibilities.

Different agents can have:

  • different instructions
  • different tools and permissions
  • different working contexts
  • different artifact ownership
  • different validation responsibilities
  • even different models chosen for the economics of their role

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.

The Coordination Tax Exists Either Way

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:

  • coordination
  • no coordination

It is:

  • implicit coordination inside one prompt and context
  • explicit coordination through contracts, artifacts, memory, tasks, and ownership
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:

  • How is work decomposed?
  • Which agent owns each responsibility?
  • What is the input and output contract?
  • Where do intermediate artifacts live?
  • Who may update authoritative state?
  • How are duplicate work and conflicting changes prevented?
  • How are progress, retries, timeouts, and cancellation represented?
  • Who resolves contradictory findings?
  • What information may be remembered, for how long, and for whom?
  • How do identity, authorization, and audit context propagate?
  • How are token, latency, and infrastructure budgets enforced?

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.

The Three MCP Services An Agent Team Needs

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

Enter fullscreen mode Exit fullscreen mode

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:

  • a clear name and description
  • a typed input contract
  • a structured output contract
  • explicit error behavior
  • task or artifact references where appropriate
  • scoped permissions
  • observable invocation boundaries

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:

  • plans
  • evidence
  • reports
  • spreadsheets
  • generated code
  • structured state
  • append-only decision logs
  • validation results

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:

  • stable file names or artifact URIs
  • an explicit owner for authoritative files
  • single-writer rules where consistency matters
  • append-only logs for decisions and rejected changes
  • versioning or optimistic concurrency for shared updates
  • access control by team, task, and role
  • cleanup and retention policies

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:

  • operating lessons
  • recurring failure patterns
  • durable team conventions
  • previously validated approaches
  • task history that is useful for later retrieval

Semantic search lets an agent retrieve the small subset relevant to its present work rather than loading 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:

  • scope: agent, user, task, or team
  • provenance: who or what wrote the memory
  • timestamps and retention
  • permissions
  • confidence or validation status
  • deletion and correction

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.

Systems Of Record And Tasks Still Matter

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.

A Team Of Agents Can Look Like An MCP Server

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:

  • discovery already exists through tool descriptions
  • invocation already exists through tool calls
  • structured results and output schemas already exist
  • tasks can represent deferred work
  • resources and artifact links can carry context
  • security, testing, and observability can remain on the MCP surface

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.

A Puzzle That Exposes The Ceiling

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:

  • a Lead Investigator chooses the next bounded question and coordinates work
  • a Hypothesis Log records proposed, accepted, rejected, and repeated ideas
  • an Evidence Clerk checks deductions against the numbered clues
  • a Board Manager is the only agent allowed to update the authoritative grid
  • a Referee independently checks every clue, uniqueness, completeness, and evidentiary support
  • a Final Report Writer produces the answer only after the Referee validates it

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.

Measure The Crossover, Do Not Assume It

A multi-agent architecture should earn its overhead against a strong single-agent baseline.

For the puzzle experiment, a run succeeds only when:

  • the final answer exactly matches the gold solution
  • every clue is satisfied
  • no category contains duplicate assignments
  • no person has a missing assignment

The most revealing measurement distinguishes claimed success from actual success:

false_completion = declared_success && !actual_success

Enter fullscreen mode Exit fullscreen mode

That captures the case where an agent crosses its capability ceiling without recognizing that it crossed it.

A serious comparison should also record:

  • exact task-completion rate
  • unsupported conclusions
  • validation failures
  • retries and rejected updates
  • wall-clock latency
  • token usage
  • model and infrastructure cost
  • tool calls and delegated agent calls

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.

When To Scale Out

An agent team is a strong candidate when the work has several of these properties:

  • independent branches can run in parallel
  • the evidence exceeds one useful working context
  • specialists need different tools, policies, or permissions
  • intermediate artifacts have clear owners
  • independent validation materially improves correctness
  • the work is long-running, retryable, or resumable
  • different models can be used economically for different roles
  • the value of a correct result justifies higher inference cost

Keep one agent when:

  • the task is short and sequential
  • every step depends tightly on the previous step
  • all participants would need the same complete context
  • coordination would cost more than the work
  • one agent already meets the target completion rate

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:

  1. Can deterministic software do the work? Build a tool or workflow.
  2. Can one agent do it reliably with a bounded context and toolset? Use one agent.
  3. Does the remaining work benefit from specialization, parallelism, durable collaboration, or independent verification? Build a team.

The goal is not to maximize agent count. It is to choose the smallest architecture that reliably completes the task.

Security And Governance Multiply With The Team

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:

  • who may call it?
  • which tools and files may it access?
  • whose identity does it act on behalf of?
  • which other agents may it delegate to?
  • which outputs may be written to shared state?
  • what prevents recursive delegation from running without a bound?
  • how are untrusted instructions and artifacts contained?
  • what is logged for reconstruction and audit?

Shared collaboration services need their own controls:

  • team-mcp enforces the allowed collaboration graph and delegation budgets
  • team-fs enforces role-based paths, ownership, and mutation rules
  • team-memory enforces scope, provenance, retention, and deletion
  • domain MCP servers continue to enforce business authorization closest to the data

Testing 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.

Supervisors, Sub-Agents, and Swarms

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.

Agent Teams Are Also Preparing For Human Teammates

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:

  • which decisions should remain human
  • where human domain expertise outperforms model reasoning
  • how agents should escalate uncertainty
  • how authority and accountability work in a mixed team
  • how interfaces help people supervise without becoming coordination bottlenecks

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.

The Team Model In One View

Carry these principles forward:

  1. Start with one agent.
    It has the lowest coordination cost and is the right default for bounded work.

  2. Do not confuse a simple diagram with a simple system.
    Coordination hidden inside one prompt and context is still coordination.

  3. Scale up before scaling out.
    Improve instructions, models, tools, workflows, and deterministic services first.

  4. Teams raise the ceiling for the right task shapes.
    Specialization, parallel contexts, explicit ownership, and independent validation enable harder work.

  5. The coordination tax exists either way.
    Teams make it explicit so it can be tested, observed, governed, and reused.

  6. Use team-mcp for delegation.
    Expose a small, role-appropriate set of specialized agents as typed capabilities.

  7. Use team-fs for working artifacts.
    Give important state stable names, clear owners, mutation rules, and history.

  8. Use team-memory for reusable learning.
    Keep semantic recall separate from authoritative task and business state.

  9. Measure the crossover.
    Compare completion, false confidence, latency, tokens, and cost against a strong single-agent baseline.

  10. 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.

Continue the Series

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.