The default: one agent, until the context objects

Lesson 5 of 5 in Multi-Agent Systems: When One Agent Isn’t Enough.

The default architecture is one agent. Not because multi-agent is wrong, but because everything in lesson 3 is a certainty and everything in lesson 2 is a hypothesis — you pay the tax on day one and collect the benefit only if your task truly had the shape you guessed.

So add agents the way you would add database shards: when a measured constraint demands it. The constraint that matters is the context, and it objects in observable ways — quality degrading as the window fills with disposable bulk, one agent needing credentials that another input source makes radioactive, subtasks provably independent and latency-bound. What is never a constraint: “our company has a research team and a writing team.” Departments exist because humans have coordination limits, careers, and budgets. Your agents have none of those — they have context windows, and the org chart says nothing about token flow.

One agent, more agents, or a workflow?

Interactive decision tree — outcomes:

  • Use a workflow

    Known, stable steps belong in deterministic orchestration code, with model calls (or a small agent) inside only the steps that need judgment. You keep testability and skip the whole multi-agent tax.

  • One agent is enough

    The context fits, the privileges are uniform, the path is dynamic — this is the single-agent sweet spot. Spend your effort on tools and evals, not on coordination machinery.

  • Split for privilege or capability

    A runtime-enforced boundary between the agent that reads untrusted input and the agent that holds credentials is a real security control — the lethal-trifecta defense. This split is justified even when the context would fit.

  • Supervisor + subagents, for context isolation

    Push the messy subtask into a fresh-window subagent that returns a compressed, source-cited report. Remember the price from lesson 3: summaries launder errors — keep worker traces.

  • Parallel fan-out

    Independent subtasks with pre-writable briefs are the one case where multi-agent buys back latency. Give shared resources a single writer, and integrate through one supervisor.

  • Stay single — fix the context, not the head-count

    Entangled subtasks that all need the shared material would just smear one overloaded context across several agents plus lossy briefs between them. Reach for compaction, memory, and retrieval instead; a split relocates the problem and adds the tax.

Interactive sorting exercise: Single agent, multi-agent, or workflow? Sort each scenario into the architecture the *task* — not the org chart — actually calls for.

One assumption ran silently through this whole module: you own every agent. Same codebase, same runtime, same logs. Drop that assumption — your procurement agent negotiating with a supplier’s sales agent — and coordination stops being an architecture question and becomes a protocol question: how do two agents that share nothing discover each other, authenticate, and track a task across company lines?

That protocol is A2A (Agent2Agent): announced by Google in April 2025, donated to the Linux Foundation that June, spec 1.0.0 since March 2026. It gives every agent a discovery document (an Agent Card at a well-known URI), a task lifecycle with the interrupted states you met in lesson 4, and authentication via standard web security schemes. The complementary framing to remember: MCP is vertical — one agent reaching down to its tools — while A2A is horizontal — agents reaching across to each other as peers. The full story, including where that tidy framing leaks, lives in the protocols domain.

Tool: Orchestration Sandbox — Wire up supervisor–worker, handoff, and fan-out topologies yourself — and watch the token meter and failure modes react as you add agents.