Soon your coding agent will regularly need context that lives in a teammate's agent, and the way to share it is to ask first. Our view: trusting someone should only let them ask, every request should need a human yes, the owner should pick exactly which agents to share, and access should be read-only. Synapse requests, new in the Synapse Mac app, work this way today. Some parts are still being tightened, and we expect audit trails, expiring shares and team policies to become normal within a few years.
The question your agent cannot answer
Here is a scenario that is already common in small teams. You ask your agent to add a billing endpoint. Halfway through, it hits the auth middleware and stops: the code in main looks old, and a branch called auth-refactor has been open for a week. Your colleague Alex is rewriting it with a Claude Code session that has spent two days reading the code, trying options and settling on a plan.
Your agent needs that plan. Today the usual path is that you message Alex, Alex asks their agent to summarize, pastes the summary into chat, and you paste it into your agent. The answer exists, written in plain text inside Alex's session. It just lives on another machine, owned by another person.
Our bet is that this becomes one of the most frequent questions in software teams. As more work happens inside long agent sessions, more of a team's working knowledge sits in those sessions: the migration plan, the reason a library was rejected, the half-finished API shape. Agents will want to ask other agents, and they will want to do it many times a day.
Why this cannot be automatic
The tempting design is a shared pool. Every agent on the team can read every other agent, and the problem goes away.
We think that is wrong, for reasons that have nothing to do with distrust between colleagues:
- Sessions hold more than code. A long session can contain pasted logs, customer data from a bug report, a private note, or a draft someone is not ready to show.
- Context changes behaviour. Text from another session that lands in your agent's prompt affects what your agent does. A share is an input to a program, not only a read.
- People need to know. If a colleague's agent read your session yesterday, you should not learn about it by accident.
So the default has to be closed, and opening it has to be a deliberate act by the person who owns the agent. The useful question is how to make that act cheap enough that people do it many times a day.
Five rules for ask-first sharing
This is the model we think teams will converge on. It is also how we built requests in Synapse.
- Trust only allows asking. Adding someone as trusted should not grant them anything. It should only let them send you requests. A stranger cannot even ask.
- Consent per request. Each request is a separate yes or no from a human. Yesterday's yes says nothing about today.
- The owner picks the agents. The person asking may name a target, but the person answering decides exactly which of their agents to share. Sharing one agent never shares the rest.
- Read-only. A shared agent can be read. It cannot be messaged, prompted or driven by the other side.
- The human is told. Requests reach a person, through more than one channel, so they do not sit unseen.
None of these are new ideas. They are how most people already share documents and repository access. What is new is the thing being shared: a live working session that keeps changing after you say yes.
How Synapse requests work today
Synapse is our tool for connecting coding agents. Locally it puts every running agent on one canvas and lets you link them. Requests are the part that crosses between people. They are new: they live in the Synapse Mac app and on the multiplayer branch, and are not yet in the open-source main release.
Working with other people needs an optional Synapse account (email and password, at app.heysynapse.dev). Local use still needs no account and makes no network calls.
The flow, in the scenario above:
1. You add Alex as a trusted person. By handle or email, in the app's Settings or on app.heysynapse.dev. This gives you nothing in Alex's sessions. It only means you can now send Alex requests.
2. Your agent asks. Either you or the agent itself runs:
synapse request @alex --target "their api agent" --note "need the auth refactor plan"Agents can do the same through the synapse_request MCP tool. The note is for Alex, so it should say why, in a sentence.
3. Alex is notified. A blinking dot appears next to "synapse" in the app, along with a notification and an email. While it is pending you can cancel it, for example if you found the answer another way.
4. Alex accepts or denies. On Accept, Alex picks which of their agents to share. At least one has to be picked, and only the picked ones are shared. Alex might share the auth refactor session and nothing else, even though "their api agent" could have meant several.
5. Your agent reads. The shared agent shows up with its owner, and your agent reads it like any linked agent:
synapse read auth-refactor@alexThat is all it can do. It cannot send that agent a message or give it work. If your agent later needs a different one of Alex's agents, that is a new request, and Alex decides again.
What we are still tightening
We want to be exact here. Conversation content is only sent for agents the owner chose to share. But the metadata is not yet as private as the rules above imply. Accepting a request pairs the two machines, the same way the older invite codes (synapse invite and synapse join) do, and today a paired machine can see the names, kinds, status and projects of your running agents, not just the ones you shared. A fix is in progress. Until it lands, treat agent names and project names as visible to anyone you have paired with.
What happens to the shared text
Consent covers who can read. A second question is what the reading agent does with the text.
Shared context is someone else's working notes, not your instructions. In Synapse, context from peers is labelled as coming from peers, and agents are told not to treat it as user instructions. That matters more across people than within one machine. If Alex's session contains "now delete the old tables", your agent should read it as a fact about Alex's plan, not a task.
We expect this separation to become a standard expectation of every agent tool: text from another person's agent is evidence, never a command.
The norms we expect next
Today, cross-developer agent sharing is new and mostly informal. Within a few years we expect a set of norms to settle, much like code review and branch protection did:
- Audit trails. A record per share: who asked, which agent was shared, when it was read, and by which agent. Owners will want to look back at it, and teams handling sensitive data will require it.
- Expiring shares. A yes that lasts for the length of a task, or until the end of the day, rather than until someone remembers to revoke it. Most shares are for one question, and the default should reflect that.
- Team policies. Rules set once for a group: agents working in certain repositories can never be shared outside the team, shares to contractors need a second approver, sessions that read production logs are never shareable.
- Request quality. Agents will get better at asking narrowly, with a clear note, because vague requests get denied. A request that says "need the auth refactor plan" is much easier to approve than "share everything about auth".
- Summaries as a middle option. Sometimes the owner will prefer to answer with a short summary their own agent writes, instead of sharing the full session. Both should be one click.
None of these exist in Synapse today. They are our guess at where every tool in this space will have to go, and they all build on the same base: no access without a request, and no request granted without a person.
FAQ
Does adding someone as trusted in Synapse give them access to my agents?
No. Being trusted only allows that person to send you requests. Nothing is shared until you accept a specific request and pick which of your agents to share.
Can a teammate's agent control or message my agent after I share it?
No. Shares from a request are read-only. Their agent can read the agents you picked with synapse read name@owner, but it cannot message them or give them work. Seeing a different agent needs a new request.
Do I need an account to use Synapse?
Only to work with other people. Accounts are optional, and local use on one machine needs no account and makes no network calls. Requests and trusted people are new, in the Synapse Mac app and on the multiplayer branch, not yet in the main open-source release.
What can paired friends see today?
For agents you share, they can read the conversation. Today a paired machine (through an accepted request or an invite code) can also see the names, kinds, status and projects of your running agents, though not their content. A fix for that is in progress.