21 Jul 2026 AI Engineering 6 min read

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

Subagents and peer agents are both called multi-agent systems, but they differ in state, lifecycle, cost, and trust model. This article separates the two working modes with verified numbers from Anthropic and Cognition, explains what A2A 1.0 standardizes — Agent Cards, tasks, contextId — shows why independence enables simulating counterpart systems, and gives six decision rules for choosing the right mode.

One Term for Two Architectures

The term multi-agent system covers two architectures that share a name and little else. In June 2025 the confusion became visible: on June 12, Cognition published "Don't Build Multi-Agents"; one day later, Anthropic published "How we built our multi-agent research system". Both texts are correct — they describe different working modes on different workloads. One mode delegates subtasks inside a single system. The other connects independent systems that happen to be agents. Conflating the two produces wrong cost estimates, wrong reliability expectations, and wrong protocols.

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 does not scale. Traces grow faster than context windows, and long contexts measurably degrade decision quality. In a 2026 follow-up, Cognition reports that the multi-agent setups that work keep writes single-threaded while additional agents contribute analysis — their clean-context review agent finds bugs precisely because it does not carry the coder's history, an effect they attribute to context rot. Across organizational boundaries the question disappears entirely: you cannot share context with a system you do not operate. That is the case for peer agents.

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 compose rather than compete, the way functions and services compose in conventional software. Inside a product, orchestrator-subagent hierarchies remain the efficient default: shared operator, shared budget, no protocol tax. At organizational edges, protocol-mediated peers take over — A2A 1.0's signed cards, multi-tenancy, and version negotiation are edge infrastructure, not internal plumbing.

We expect near-term work to concentrate on the seams: registries for Agent Card discovery, conformance test suites, and simulated counterparts as standard tooling in agent CI pipelines. The open problems Cognition names — when to escalate, how to transfer context without drowning the receiver — are communication problems, and they will be solved incrementally, not by a new architecture. The systems that scale will be the ones that know which mode they are in.