Today each coding agent is a brilliant island. Our bet is that the next leap comes from agents that know about each other, not from a smarter single agent. Isolation tools like worktrees and containers stop agents from colliding, but they do nothing to let them cooperate. There are three ways to connect agents: shared files, a central orchestrator, or a mesh of direct links. We think a mesh wins for real work, provided links are directional, consented to, and clearly labelled so peer context is never mistaken for instructions. Synapse is our attempt at the local version of that mesh today.
Brilliant islands
Picture a normal afternoon in 2026. Claude Code is planning a migration in one terminal. Codex is implementing the first step in a worktree next to it. A third session is reviewing yesterday's pull request. Each one is capable.
None of them knows the others exist.
The planner decides to keep the old table for one more release. The implementer never hears about it and writes code that drops it. The reviewer flags a pattern the planner already ruled out an hour ago. You notice all three problems, because you are the only part of the system that sees everything. So you copy, paste, summarize and correct.
This is the state of the art today: strong individual agents, joined by a human acting as the message bus. Each new model makes the islands bigger. It builds no bridges.
Isolation solved the wrong half
Most of the tooling built around coding agents this year is about keeping them apart. Git worktrees give each agent its own checkout. Containers and remote sandboxes give each agent its own filesystem and processes. Workspace apps give each task its own terminal, branch and diff.
That work matters. Two agents editing one file at once is a real problem, and isolation fixes it. But isolation answers only one question: how do we stop agents from damaging each other's work? It says nothing about the other question: how do agents benefit from each other's work? A worktree keeps the implementer's files safe from the reviewer. It does not tell the reviewer what the implementer just decided, or why.
Human teams solved both halves long ago. Engineers have their own branches and laptops, and also a chat channel, a standup and a design doc. Coding agents today have the first and almost none of the second.
Three ways to connect agents
If agents need to be aware of each other, there are roughly three shapes that awareness can take.
| Shape | How it works | Strength | Weakness |
|---|---|---|---|
| Shared files | Agents read and write a notes file such as AGENTS.md, CLAUDE.md or a .context folder | Simple, durable, works with any agent | Only what someone chose to write, only when someone reads it; goes stale |
| Orchestrator | One boss agent spawns workers, assigns tasks and collects results | Clear control, easy to reason about | Every piece of information goes through one context window; workers rarely see each other; usually needs agents launched its way |
| Mesh | Agents link directly to each other; each sees what its linked peers are doing | Information flows where it is needed, works with agents you already started | Needs rules about who sees what, and how much |
Shared files are good for long-lived decisions and poor for what happened five minutes ago. The orchestrator is what most frameworks reach for first, and it works well for scripted pipelines. In open-ended work, the boss agent's finite context window becomes the bottleneck for every detail. The implementer that hits a surprising constraint has to report up, and the boss has to decide whether to relay it down to the reviewer. That is the human message bus problem again, just with a model in the human's seat.
A mesh skips the middle. If the reviewer needs to know what the implementer decided, link the reviewer to the implementer. Nobody has to decide in advance which details are worth forwarding.
Our bet is that serious multi-agent work will look more like a mesh with a little structure on top than like a tree with a boss at the root. Orchestrators will still exist, but as one more node in the mesh rather than the only path between nodes.
What makes a mesh safe
A mesh where every agent sees everything would be noisy at best and dangerous at worst. Three properties make it workable.
Links are directional. "B can see A" is a different statement from "A can see B". A reviewer usually needs to see the implementer. The implementer often does not need the reviewer's full reasoning, only its verdict. Direction keeps each agent's context focused, and it lets you build pipelines (planner to implementer to reviewer) without everyone drowning in everyone else.
Links are consented to. Someone, a person or an agent acting for one, decides to create each link. That matters more as the mesh grows beyond one laptop. A teammate's agent should never start reading yours because it happens to be reachable. Every edge should have an owner who chose it and can remove it.
Peer context is labelled. This is the subtle one. When agent B receives text from agent A, that text must arrive marked as "this is what a peer said", not as "this is what your user wants". Otherwise any agent in the mesh can steer any other agent, intentionally or by accident. A peer's transcript might contain a pasted web page, a log line or an instruction meant for a different task. The receiving agent should treat it as information to weigh, never as a command to follow.
We expect these three rules to become standard for any tool that connects agents.
What exists today
Synapse is what we build, so read this section with that in mind.
Today Synapse runs locally on a Mac. It finds every live coding agent on the machine: Claude Code sessions from Claude Code's own session registry, and other CLIs (Codex, Gemini CLI, OpenCode, Cursor Agent, Amp, Copilot CLI and others) by scanning processes and their working folders. It does not need you to relaunch or wrap anything, so it also sees agents started inside other workspace tools or plain terminals. They appear as nodes on a canvas, grouped by repo.
You drag a line from A to B, and on each prompt B gets what A has said since last time, capped at 8,000 characters per link. Links are directional; draw both ways for a pair. Any two linked agents can message each other, including Claude Code to Codex. Agents can also link themselves through MCP tools. Shared context is labelled as coming from peers, and agents are told not to treat it as user instructions. Everything stays on your machine, and the open-source release makes no network calls.
It has real limits. Messages are pulled, not pushed, so an idle agent does not wake up on a message (push is planned). Context is readable for Claude Code, Codex and Gemini CLI only. It is an early project, macOS first.
A team mesh in a few years
Here is a scenario we expect to become ordinary within a few years.
Priya's planning agent has spent the morning on a design for rate limiting. Her teammate Alex is running an implementing agent on the API gateway in another city. Alex's agent hits a question: should limits apply per key or per account? Instead of Alex messaging Priya, waiting, and pasting the answer back, Alex's agent sends a request to read Priya's planning agent. Priya gets a notification, picks which of her agents to share, and accepts. Alex's agent reads the plan, finds that the decision was per account, and carries on. It cannot message or drive Priya's agent. It can only read what she allowed.
Later a reviewer agent, linked to both, checks the pull request against the plan itself, not a summary someone remembered to write.
Parts of this are no longer speculation. The Synapse Mac app has a new, optional feature along these lines: you add trusted people, an agent sends a request for context, and the person accepts or denies and chooses which agents to share. Access is read-only, and being trusted grants no access by itself. It lives on a branch and in the Mac app, not in the open-source main release yet, and it has rough edges we are still fixing.
What we expect next, across the industry and not only from us:
- Meshes will span vendors. Teams already mix Claude, Codex and Gemini. A connection layer that only works inside one vendor's agents will feel as limiting as a chat tool that only works inside one company.
- Links will carry policy. Which agents may read which, for how long, and how much. These will look a lot like file permissions today.
- Humans will move from bus to editor. You will spend less time carrying information between agents and more time deciding which links should exist and checking what flowed through them.
Agents will keep getting smarter. Our bet is that the bigger change will come from the wiring between them.
FAQ
What is an agent mesh?
An agent mesh is a set of coding agents linked directly to each other, so each one can see what its linked peers are doing. It contrasts with an orchestrator, where one central agent passes all information between workers. In a mesh, information flows along the links you choose.
Is a mesh better than an orchestrator agent?
For fixed pipelines, an orchestrator is simple and predictable. For open-ended work, a mesh avoids pushing every detail through one context window and works with agents you already started. We expect most real setups to combine them, with an orchestrator as one node in a mesh.
Do worktrees or containers let agents share context?
No. Worktrees and containers isolate agents so they do not overwrite each other's files. They do not tell one agent what another decided. You need a separate layer, such as shared notes, a message tool or links between agents, for that.
Is it safe to let one agent read another agent's conversation?
It can be, with three rules: links are directional, someone consents to each link, and peer context is clearly labelled as information rather than instructions. Without the labelling, text in one agent's transcript could steer another agent. Synapse labels shared context as coming from peers for this reason.