Context Sharing & Coordination

Three agents, three git worktrees, one goal: migrate a service off a deprecated auth library. The team split the work the way the previous chapter recommends — by file boundary, no lock contention expected, each agent free to run for hours without stepping on the others’ changes. Two hours in, the lead engineer checks in and finds that two of the three agents have independently written the same token-refresh helper, each one convinced it was first to notice the gap. The third agent stopped forty minutes earlier. It needed to know which of two SSO providers the team is actually keeping, guessed, and spent the rest of its budget building against the one being retired.

The instinct is to fix this with more communication — put all three agents in one shared channel, let each see what the others are doing, give them a bigger combined context. That instinct is understandable and it is aimed at the wrong layer. Isolation was never the problem; the worktrees did their job, and no file was touched twice. The actual problem is that three isolated agents had no shared, durable record of what work existed and who owned it; no way to ask each other a targeted question without dumping a full transcript into the ask; and no mechanism to pause for a decision that only a human could make. Three distinct failures, and a single chat thread would have papered over none of them — it would have added noise to all three agents’ context windows without fixing any of the underlying gaps.

What the best-documented system actually does

It is worth returning to the most carefully documented production multi-agent system in the field, already covered in Chapter 4 for its orchestrator–worker pattern: Anthropic’s own multi-agent research system. Its coordination design is a deliberate absence, not an oversight. Subagents run in parallel waves, each with its own context window, and report back to a single lead agent by condensing their findings into a short result rather than handing over their working transcript. The lead agent runs subagents synchronously, waiting for one wave to finish before starting the next. There is no subagent-to-subagent channel at all — a subagent that needs information another subagent has must go through the lead, or not get it.

The best-documented production multi-agent system gives its subagents no way to talk to each other — coordination happens exclusively through the lead, and even that is synchronous.

On Anthropic’s multi-agent research system

For a research task decomposed into independent searches, that constraint is nearly free — the subagents genuinely do not need each other. Anthropic’s own writeup flags the limit anyway: its appendix recommends that future systems let specialized agents “create outputs that persist independently” rather than routing everything through the lead agent’s conversation, specifically to avoid information loss and the token cost of copying large results through every hop. That is a research-system fix for a research-system problem — a lead agent that reads too much of what its subagents produce. Chapter 6’s worktree-isolated coding agents have a different shape entirely: there may be no lead agent at all, just several long-running peers working for hours in parallel, each of which needs a shared record independent of any one agent’s context window.

The primitive problem

Absent a designed answer, teams improvise, and the improvised tools have the wrong semantics for the job. A shared markdown TODO file has no claim semantics — two agents can read “unclaimed” at the same moment and both start work, and the file itself becomes exactly the kind of merge-conflict surface the worktree split was supposed to avoid. A Slack channel or a shared context blob has no queryable state — an agent cannot cheaply ask “is this claimed yet” without an LLM call to re-read the whole channel history, which is slow, costs tokens, and is not guaranteed to notice the answer. And almost nobody builds a blocking primitive for the third case, so an agent facing a decision only a human can make either halts silently until someone happens to check on it, or — more often, and more expensively — guesses and keeps going.

These are three separable problems, and conflating them into “agents should be able to talk to each other” is exactly the mistake that produces ad hoc tooling. What work exists, is claimed, and is done needs a durable, queryable record — not a conversation. What one agent needs to ask another needs addressed messaging, independent of either agent’s own context window — not a shared transcript. What blocks on a decision needs an explicit, resolvable wait with an owner and a timeout — not a hope that someone notices in time.

Three coordination primitives

Three primitives cover the space, each matched to one of the failures above. None of them require a shared context window between agents, and none of them are solved by giving agents a bigger one — they are infrastructure decisions, living in durable storage outside any single agent’s transcript, not context-engineering decisions inside it.

None of these three require every agent to see every message, every task, or every open question. A shared task list only needs one writer to win a claim; a message bus only needs the addressed or subscribed readers to see a given entry; a decision gate only needs the one blocked agent and whoever is authorized to resolve it. Scoping tightly is not an optimization here — it is what keeps the shared state small enough to stay durable and queryable, instead of quietly turning into another transcript everyone has to re-read.

Agent-to-tool, not agent-to-agent

The three primitives above are usually built inside one product, for agents a team already controls. A separate, and precisely different, problem is what happens when an agent needs to reach a tool, a data source, or another agent it does not control — and here the industry has settled on two protocols that solve genuinely different problems, despite getting flattened into “the agent protocols” in casual conversation. The Model Context Protocol, which Anthropic open-sourced on November 25, 2024, standardizes how a single AI application connects to external tools, data sources, and prompt templates. Its own architecture documentation is explicit about the shape: an MCP host — the AI application itself — creates a dedicated MCP client for each MCP server it talks to, and each client maintains one connection to one server, exchanging tools, resources, and prompts over a JSON-RPC data layer. That is agent-to-tool, by design, and it addresses what Anthropic’s original announcement called an N×M integration problem — every AI application otherwise building a custom connector for every data source.

The Agent2Agent protocol, which Google released on April 9, 2025 and handed to the Linux Foundation for vendor-neutral governance on June 23, 2025, standardizes something else: how independent agents — potentially built by different vendors, on different frameworks — discover each other and delegate work. Each agent publishes a machine-readable Agent Card describing its skills and how to reach it; work is exchanged as a Task with an explicit lifecycle running from submitted through working to completed; and the protocol’s own specification is careful to say that agents “collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations.” Agents negotiate as peers rather than one agent consuming another as a callable function. That is agent-to-agent, and it is a discovery-and-delegation problem, not a context-connection one.

Google’s own announcement calls A2A “an open protocol that complements Anthropic’s Model Context Protocol,” which is itself a tell: the two vendors felt the need to state the boundary explicitly, because it gets crossed constantly in practice. A shared task list, a message bus, and a decision gate between agents a team already runs, inside one product, are an application-level design choice — not a cross-vendor discovery problem, and not something either MCP or A2A is required to solve. A2A earns its complexity once an agent genuinely needs to hand work to an external agent it has never talked to before, built by a team it does not control. Most engineers reading this chapter do not have that problem yet; they have the first one, and it is worth not reaching for a discovery protocol to solve it.

A shared bus, in practice

Operon’s own coordination bus is a concrete, in-product instance of exactly the first problem — worth describing precisely because it maps cleanly onto the three primitives above, and because it is deliberately not an A2A implementation. Every agent on the bus is a session the same product already spawned and already owns; there is no discovery step, because there is nothing to discover.

The claim mechanism is the detail worth noticing, because it is the whole answer to the opening scene’s duplicated helper function: a task’s status only flips from pending to claimed if it is still pending at the moment of the write, so two agents racing for the same task never both believe they own it — one gets confirmation, the other gets nothing and moves on to the next available task. That single conditional write is doing the entire job a shared markdown file cannot, and it costs nothing in tokens because neither agent has to read or reason about it — the database enforces it.

Not Checkpoint Thinking

It is worth being precise about a boundary this chapter does not cross. Checkpoint Thinking, covered in Volume V, governs a single session’s own plan — pausing before that one agent advances to its next step, so a person can review a diff before more code gets built on top of it. A decision gate governs something orthogonal: the boundary between agents, or between an agent and a human, not the boundary between one agent’s own plan steps. A session can have both at once — its own checkpoints between steps, and gates where its progress depends on someone else’s answer entirely — and the two fail in different ways, which is reason enough to keep them as two separate mechanisms rather than collapsing them into one generalized pause button.