Between services we built APIs. Between agents, the thing that moves is context: what was tried, what was decided, what was ruled out. Today people carry that context by hand, with copy and paste. To make the exchange reliable it needs the same things APIs needed: a size budget, freshness, provenance, a delivery model, and a defence against hostile input. Synapse covers some of this today (an 8,000 character budget per link, pull delivery, peer labelling). Our bet is that agents will eventually agree on explicit context contracts, much like API schemas.
What moves between agents
When two services talk, they exchange structured requests. A payment service calls charge(amount, card) and gets back a result. Both sides agreed on the shape in advance. That agreement is the API.
When two coding agents work on the same project, the useful thing to exchange is rarely a request. It is context. Consider a planning agent, an implementing agent and a reviewer working on a database migration:
- The planner explored three approaches and ruled out an online schema change because the table is too large.
- The implementer tried a backfill script, found that a foreign key made it slow, and switched to batching by ID range.
- The reviewer needs to know both facts, or it will suggest the exact approaches that were already rejected.
None of this fits a function signature. It is a mix of decisions, dead ends, reasons and open questions, and it lives in each agent's conversation, not in the code. The diff shows what the implementer did, not what it tried first and why it stopped.
That is the core claim of this essay: between agents, context is the interface.
Today, the human is the transport
Right now most context moves between agents through a person. You read the planner's output, decide what matters, and paste it into the implementer's prompt. Later you summarize the implementer's struggles for the reviewer.
There are partial fixes in use today:
| Method | What moves | Who decides what to share | Weak spot |
|---|---|---|---|
| Copy and paste | Whatever you select | You | You are the bottleneck and you miss things |
| Shared notes file (AGENTS.md, CLAUDE.md, a notes folder) | What an agent chose to write down | The writing agent | Written late or not at all; goes stale |
| Message tools between agents | Explicit messages | The sending agent | Only what the sender thought to say |
| Delegation (one agent calls another as a tool) | A task and its answer | The calling agent | One way; the callee starts with almost no context |
| Live links to another agent's transcript | Recent conversation | The person or agent who drew the link | Needs budgets and labelling, see below |
Each is a different answer to one API question: who decides what crosses the boundary? Copy and paste puts the human in charge. Notes and messages put the sender in charge. Live links put the relationship in charge: if B is linked to A, B sees A's recent work without A having to anticipate what B needs.
The properties a context exchange needs
APIs matured by growing rules: schemas, versioning, rate limits, authentication. Context exchange will need its own set. Here are the five we think matter most.
Budget. A context window is finite and expensive. If the reviewer receives the planner's entire session, it has less room for the code it is supposed to review. So every link needs a budget, the way an API has a payload limit.
Today Synapse caps context at 8,000 characters per link (SYNAPSE_BUDGET). That limits size, not relevance, but it forces the question every future system must answer: when a budget is tight, what gets dropped first?
Freshness. Context ages fast. A decision from this morning might have been reversed an hour ago. A good exchange delivers what changed since the receiver last looked, not a full replay. Synapse does this on each prompt: it injects what linked agents said since last time. Within a few years we expect freshness to become richer, with markers like "superseded" when an agent reverses itself, so that receivers do not act on stale decisions.
Provenance. The receiver needs to know where each piece of context came from. "Use batching by ID range" means something different coming from the implementer that measured it than from a planner that guessed it. Provenance also matters across vendors: a Codex agent reading a Claude agent's conclusions should know that is what it is reading. Today Synapse labels shared context as coming from a named peer. Richer provenance (which tool output a claim rests on, which commit it refers to) is open territory.
Delivery: pull or push. Pull means the receiver gets new context when it next acts. Push means the sender can wake the receiver. Synapse is pull today. Claude Code and Codex see new context and messages on their next prompt, and other CLIs check through the synapse_inbox MCP tool. That means an idle agent does not wake up when a peer messages it. Push delivery is planned.
Pull is simple and safe: nothing interrupts an agent mid-task. Push is what you want when one agent is blocked on another. We expect most systems to offer both, with pull as the default.
Defence against injection. This is the property that worries us most. Once one agent's output becomes another agent's input, every agent becomes a possible route for prompt injection. A transcript can contain a pasted web page, a log line from a dependency, or a README with hidden instructions. If the receiver treats that text as instructions, an attacker who can reach one agent can steer all the agents linked to it.
The minimum defence is labelling: shared context arrives marked as coming from a peer, and the receiver is told it is information, not instructions from the user. Synapse does this today. Labelling is necessary and not sufficient. It depends on the receiving model honouring the label. Stronger defences will likely follow, such as limiting which tools an agent may call based on peer context alone, or requiring a human or the agent's own user to confirm actions that originate in shared context.
What exists in Synapse today
Synapse is what we build, so take this section as a description, not a neutral review.
Synapse runs locally on a Mac and finds every live coding agent on it. You link agents on a canvas, or agents link themselves through MCP tools. A link from A to B means B gets A's recent conversation on each prompt, up to the 8,000 character budget. Transcripts are read from disk for Claude Code, Codex and Gemini CLI. OpenCode, Cursor Agent, Amp and Copilot CLI show up and can exchange messages, but their context is not readable yet (planned). Any two linked agents can message each other across vendors, Claude Code to Codex included. All of it stays local, with no account and no network calls in the open-source release.
The new Synapse Mac app adds an early version of context exchange between people: an agent can request to read a trusted teammate's agent, and the teammate accepts or denies and picks which agents to share. Access is read-only. It is not yet in the open-source main release.
In the terms of this essay, Synapse today has a budget, freshness by "since last time", provenance at the level of which peer said it, pull delivery, and labelling against injection. It does not yet have relevance ranking, superseded markers, push, or any formal contract.
Context contracts
Here is where we think this goes.
Today an API contract says: this endpoint accepts these fields and returns these fields. Our bet is that within a few years, links between agents will carry something similar, a context contract. It might look like this:
link: planner -> implementer
budget: 6000 chars
include: [decisions, ruled_out, open_questions]
exclude: [tool_output, pasted_web_content]
freshness: since_last_read
on_superseded: mark
delivery: pull
escalate_push: when implementer is blocked on planner
trust: information_onlyEach line answers a question that today is answered implicitly, or not at all. What kinds of content cross this boundary? How much? What happens when a decision is reversed? Can the sender interrupt the receiver? Can the receiver act on this content without asking anyone?
A few things would follow if contracts like this become common:
- Agents would summarize for a reader. An implementer that knows the reviewer only receives decisions and dead ends could write those explicitly, the way a good engineer writes a pull request description.
- Handoffs would be checkable. You could ask whether the reviewer actually received the reason the planner ruled out an approach, instead of hoping.
- Security review would have something to review. A contract that excludes pasted web content and marks peer context as information only is a policy someone can audit.
None of this exists as a standard today, and it may look different from our sketch. We are confident about the direction: the boundary between agents will get explicit rules, as the boundary between services did.
FAQ
What does "context is the new API" mean?
Between services, the API defines what crosses the boundary. Between coding agents, what crosses is context: decisions, dead ends and open questions from one agent's work. Treating that exchange like an API means giving it budgets, freshness, provenance and security rules.
How much context should one agent pass to another?
Enough to avoid repeated mistakes, but not so much that it crowds out the receiver's own work. Synapse caps each link at 8,000 characters by default and sends only what changed since the receiver last looked. Future systems will likely filter by type of content, not only by size.
Can sharing context between agents lead to prompt injection?
Yes. If one agent's transcript contains hostile text, such as instructions hidden in a web page it read, a linked agent could act on it. The baseline defence is labelling peer context as information rather than user instructions, which Synapse does. Stronger controls on what actions peer context can trigger are still needed across the industry.
Does Synapse push context to agents?
No, not today. Synapse is pull based: Claude Code and Codex receive new context and messages on their next prompt, and other CLIs check with the synapse_inbox MCP tool. An idle agent does not wake up on a message. Push delivery is planned.