21 Jul 2026 AI Engineering6 min read

Subagents vs. Peer Agents — Two Working Modes of Multi-Agent Systems

Subagents and peer agents are both classed as multi-agent systems, yet they follow different state, lifecycle, cost, and trust models. Using verified figures from Anthropic and Cognition, we separate the two modes, explain Agent Cards, tasks, and contextId in A2A 1.0, and derive six rules for the architecture decision.

One Term for Two Architectures

The term multi-agent system covers two architectures that share little beyond the name. The confusion became visible in June 2025: Cognition published "Don't Build Multi-Agents" on June 12, followed one day later by Anthropic's "How we built our multi-agent research system". Both texts are sound because they describe different operating modes for different workloads. One delegates subtasks inside a single system; the other connects independent systems that are themselves agents. Conflating them distorts cost and reliability estimates and leads to the wrong protocol.

The distinction matters now because both modes matured within twelve months of each other. Orchestrator frameworks became commodity features of coding tools and research products, while the Agent2Agent protocol reached version 1.0 in March 2026 and gave independent agents a stable wire contract. Teams therefore face a real choice with real numbers attached — not a question of style.

Two peers — each with its own state and private graph. 1/4

Defining Subagents and Peer Agents

A subagent is an LLM instance spawned by an orchestrator for one bounded subtask. It receives its task description from the parent, works in its own context window, returns a result, and terminates. It has no address, no persistent state, and no existence outside the delegation. Anthropic's Research system is the reference implementation: a lead agent decomposes a query and spawns parallel search subagents.

A peer agent is an independent system. It runs on its own lifecycle, holds its own state, and is reachable at a network endpoint — often operated by another team or another organization. You do not spawn it; you send it a message and it decides how to respond. Delegation becomes communication. The table summarizes the differences.

Dimension	Subagent	Peer agent
Created by	Orchestrator, per subtask	Its operator; runs continuously
Lifetime	One delegation, then terminated	Independent of any single task
State	Own context window, discarded on return	Own persistent state and memory
Addressing	Internal spawn / tool call	Network endpoint via Agent Card
Trust boundary	Same process, same operator	Can cross team and org boundaries
Failure handling	Parent retries or replans	Task lifecycle states, timeouts, renegotiation
Testability	Evaluated end-to-end with parent	Contract allows simulated counterparts

What Orchestration Buys

Orchestration buys breadth. Anthropic reports that a multi-agent setup with Claude Opus 4 as lead and Claude Sonnet 4 subagents outperformed single-agent Opus 4 by 90.2% on an internal research evaluation. The mechanism is parallel context: each subagent gets its own window, so the system reads more than any single context can hold. Token usage alone explained 80% of performance variance in their BrowseComp analysis.

The price is explicit. Anthropic measured roughly 15 times the token consumption of a chat interaction; a January 2026 follow-up puts multi-agent overhead at 3 to 10 times a single agent on equivalent tasks. Anthropic also names the boundary: tasks where agents must share context or depend on each other's steps — most coding work, for instance — are a poor fit. Orchestration pays off on breadth-first, decomposable work, not by default.

Where Context Sharing Breaks Down

Cognition's essay states two principles: share full agent traces, not just individual messages; and actions carry implicit decisions, so conflicting decisions produce bad results. Parallel subagents that cannot see each other make incompatible implicit choices — style, APIs, edge-case handling — and the conflicts surface at merge time. Their 2025 recommendation was a single-threaded agent with continuous context.

Full-trace sharing, however, does not scale. Traces grow faster than context windows, and long contexts measurably degrade decision quality. In a 2026 follow-up, Cognition therefore describes setups that keep writes single-threaded and use additional agents only for analysis. Its clean-context reviewer finds bugs precisely because it does not inherit the coding agent's history, an effect Cognition attributes to context rot. Across organizational boundaries, the question disappears altogether: you cannot share context with a system you do not operate. That is where peer mode begins.

What A2A 1.0 Standardizes

The Agent2Agent protocol (A2A) addresses exactly this boundary. Google announced it on April 9, 2025 with more than 50 partners; the project now sits with the Linux Foundation, steered by a technical committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow. Version 1.0, released March 12, 2026, is the first release the project labels production-ready.

Three constructs carry the specification. The Agent Card is a JSON manifest describing identity, skills, security requirements, and supported interfaces — each with its own protocol binding (JSON-RPC, gRPC, or HTTP+JSON) and protocol version; v1.0 adds JWS signatures for cryptographic verification. A Task is a stateful unit of work with a defined lifecycle: interrupted states such as input-required, and terminal states (completed, canceled, rejected, failed) — a terminal task never restarts. The contextId groups related tasks and messages across a series of interactions.

Equally important is what A2A does not standardize: prompts, reasoning traces, and model context never cross the wire. The protocol defines the envelope — discovery, task state, artifacts — and leaves each agent's internals opaque. That opacity is not a gap; it is the property that makes cross-organizational operation possible at all.

Independence Enables Simulation

Because a peer is defined entirely by its contract — Agent Card plus task semantics — anything that honors the contract can stand in for it. This enables a pattern familiar from microservices: service virtualization. Before a real counterpart is available, you develop and test your agent against a simulated peer that speaks the same protocol. It accepts tasks, emits status updates, returns artifacts, and rejects malformed requests.

This is where independence earns its cost. A simulated peer can replay failure modes deterministically — timeouts, rejected tasks, input-required loops, revoked credentials — which live counterparts produce rarely and unpredictably. Subagents offer no equivalent, because their interface is an informal prompt composed at runtime; there is no stable contract to simulate against. Honest scoping: simulation validates protocol behavior and your agent's error handling. It does not validate the partner's actual semantics. An integration test against the real system remains mandatory.

Six Decision Rules

1. One operator, one task, results folding back into one answer: use subagents. 2. The work decomposes into branches that need not see each other — breadth-first search, parallel research: subagents pay off; if steps share state or depend on order, use one continuous agent instead of a swarm. 3. The counterpart has its own persistent state, lifecycle, or owner: it is a peer. You cannot spawn another organization's system; you can only address it.

4. A trust boundary is crossed — authentication, signatures, audit: use a protocol-defined peer, not an internal delegation; A2A 1.0's signed Agent Cards and security schemes exist for this case. 5. Check the budget: expect 3 to 10 times the token overhead of a single agent; the task's value must cover it. 6. If you must build against a counterpart you cannot yet reach, design contract-first and simulate the peer — this is only possible in peer mode.

Outlook: From Hierarchy to Federation

The two modes will complement rather than displace each other, much as functions and services do in conventional software. Inside a product, orchestrator-subagent hierarchies remain the efficient default: one operator, one budget, no protocol tax. At organizational boundaries, protocol-mediated peers take over. A2A 1.0's signed Agent Cards, multi-tenancy, and version negotiation are infrastructure for that boundary, not internal plumbing.

Near-term work will likely concentrate on the seams: registries for Agent Card discovery, conformance test suites, and simulated counterparts as standard tooling in agent CI pipelines. The questions Cognition identifies — when to escalate and how to transfer context without flooding the receiver — are communication problems. They will be solved incrementally, not by another wave of architecture. The systems that scale will be those that choose their mode deliberately.