20 Dec 2025 AI Engineering 5 min read

Peer Agents and Subagents From First Principles

Subagent and peer agent name two different architectures, not two words for one. We derive the distinction from first principles — who owns the context, who owns the lifecycle — and show how trust boundaries, token cost, and testability follow, with measured numbers from Anthropic's multi-agent research system and the A2A protocol as of December 2025.

One Term Hides Two Architectures

"Multi-agent system" covers two constructions that share almost nothing. A subagent is a worker that an orchestrator spawns, briefs, and discards. A peer agent is an independent instance with its own lifecycle, its own memory, and its own identity. The industry uses the words interchangeably. The architectures are not interchangeable: they differ in who owns state and who owns control, and from those two properties follow trust boundaries, cost curves, and test strategy.

Two questions separate the patterns. First: who owns the context — does the callee's work flow back into a memory the caller controls, or into memory the callee keeps? Second: who owns the lifecycle — can the caller create and terminate the callee at will? Every claim in this article reduces to these two answers.

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

Subagents Are Delegation Inside One Orchestrator

A subagent runs inside one orchestrating process. The orchestrator creates it with a scoped brief, the subagent works in an isolated context window, and its condensed result returns to the parent. Then it ceases to exist. Anthropic's research system, described on 13 June 2025, is the canonical example: a lead agent decomposes a query, spawns three to five parallel subagents, and synthesizes their findings. Claude Code shipped user-configurable subagents in July 2025 — Markdown files with a system prompt and an explicit tool allowlist.

Equally important is what a subagent does not do. It holds no durable state, cannot be addressed from outside, and cannot outlive its parent; reuse means respawning with a fresh brief. These are not gaps. They are the constraints that keep the pattern small enough to analyze.

Peer Agents Are Independent Instances With Own State

A peer agent is a separately deployed instance: own process, own memory, own task queue, own uptime. No orchestrator owns it; coordination happens through messages. Google's Agent2Agent protocol (A2A), announced on 9 April 2025 with more than 50 partners and donated to the Linux Foundation on 23 June 2025, standardizes this shape: agents publish capability descriptions, exchange tasks over HTTP, and track long-running work in their own state machines. A2A deliberately complements MCP (November 2024), which connects one agent to tools — not agents to each other.

Peers are the right shape when agents belong to different teams, vendors, or security domains — when no single orchestrator can own everything. They are the wrong shape when one team controls the whole workflow. In that case peers add network hops, contract versioning, and distributed failure modes to a problem that in-process delegation already solves.

Dimension	Subagent	Peer agent
Lifecycle	Created and terminated by the orchestrator	Independent; starts and stops on its own
State	Ephemeral; result returns to the parent	Persistent; own memory and task state
Identity	Runs under the caller's credentials	Own identity; authenticates every caller
Communication	In-process delegation via tool call	Network protocol such as A2A over HTTP
Failure domain	Contained in one process	Distributed; partial failure is normal
Cost lever	Orchestrator prompting and spawn limits	Contract design and message size

Trust Boundaries Follow Ownership

A subagent inherits its caller's trust. It runs under the same credentials; its permissions can only be narrowed, for example through tool allowlists. Verification is cheap because the parent can read the full transcript of everything the subagent did. A peer agent sits behind a trust boundary. It must authenticate callers, its internals are not inspectable, and every incoming message is a potential prompt-injection vector. A2A treats agents as opaque endpoints by design — an interoperability feature and a verification cost at the same time.

The practical rule: model the boundary as it is, not as it is convenient. Treating a third-party agent as a subagent extends it your credentials. Treating your own subagent as a peer buys authentication and contract overhead for a boundary that does not exist. Both errors are common; only the first one is dangerous.

Why the Distinction Drives Cost

The cost data is public. Anthropic measured in June 2025 that single agents use about 4 times the tokens of a chat interaction and multi-agent systems about 15 times. Token usage alone explained 80% of performance variance on the BrowseComp evaluation; an Opus 4 lead with Sonnet 4 subagents outperformed a single Opus 4 agent by 90.2% on their internal research eval. Delegation multiplies tokens because the parent pays three times: to write the brief, to run the worker, and to read the result.

Peers add a second multiplier. Because no memory is shared, every message must carry its own context, and both sides re-establish understanding on each exchange. Persistent state also costs money while idle. The control levers differ accordingly: subagent cost is governed by orchestrator prompting — spawn counts and effort scaling — while peer cost is governed by contract design. Multi-agent architectures pay off only where task value covers the multiplier; Anthropic said this plainly.

Why the Distinction Drives Testability

A subagent tests like a function. The brief is the input, the returned summary is the output, and no state survives between runs. You can replay a recorded delegation and assert on the result; the orchestrator transcript is a complete trace. The model remains nondeterministic, but the harness is closed: one process, one clock, no network.

A peer agent tests like a distributed system. State persists between messages, so every test needs setup and teardown of the peer's memory. Failure modes include timeouts, partially completed tasks, and version skew between independently deployed agents. The applicable discipline is the microservice one — contract tests against the protocol, mocks at the message boundary — with nondeterministic components on both sides. This is tractable, but it is an order of magnitude more work. Teams should price that in before choosing peers.

Outlook From December 2025

As of December 2025, the production systems that demonstrably work are orchestrator-subagent designs; peer deployments are mostly pilots. We expect that ranking to hold through 2026. Delegation inside one trust domain is cheaper to run and cheaper to test, and most enterprise workflows still live inside one trust domain. Peers will grow where the boundary is mandatory — between companies, between vendors — and the A2A project under the Linux Foundation, with more than 100 supporting companies as of June 2025, is the likeliest substrate.

The open problems are unglamorous: agent identity, billing across boundaries, and replayable traces of opaque peers. Whoever makes peer agents testable will set the de-facto standard, protocol or not. Our own default at Blue IT Systems is unchanged: subagents first, and a component is promoted to peer only when a trust boundary forces it.