The @ is the easy part

What I want is simple to say. In Codex I type “@reviewer, look at this change,” and an agent running in Claude Code, Cursor or Pi, maybe on another machine, picks it up. It knows which project and which diff I mean, and it can decide whether to take the job. I can see it receive the message, start, get stuck, finish or refuse. If it is busy the message waits; if it is offline the message is not lost; when it is done there is a result I can check.

This year every large lab shipped a piece of that. xAI’s Grok Bot, launched in beta on 11 August, is described as “your team of always-on agents”: you can tag it under a post on X and the post becomes its task, type @ in a group chat to pick a bot, give it an email address, and its bots “independently message each other and share context in threads.”¹ Meta’s Muse, OpenAI’s dots and Anthropic’s Claude Duet followed between September and late October, and Claude Code sessions on one machine can now message each other by name. Each of these works inside its own walls. None of them talks to another company’s agent, and the coding agents in my terminal, which do most of my work, cannot be reached from outside their own window at all.

This essay is about what it would take to join those pieces. It starts from three small tools I built while trying to make coding agents cooperate, goes through the protocols that exist in October 2026 and the research that measures what multi-agent work actually buys, and ends with a plan I would be willing to have proved wrong. My conclusion, stated up front: the part with the best odds is a shared record of tasks, delivery states and checkable results that agents join on purpose, and the @ is only the way into it.

Three tools, three lessons

ccli: a session is a file, and it does not travel

ccli reads the transcripts that Claude Code, Codex, Pi, the Cursor CLI and the Cursor IDE write to disk, and shows what each session did and cost. I wrote it partly for the handoff I need most often: an agent stops in the middle of a task because one account’s quota ran out, and the work has to continue somewhere else. Between two Claude Code accounts ccli can move the session itself. It refuses a session that a live process is running, extends a copy only when the target is a byte-for-byte prefix of the source, and gives a fork a new session id.

Those rules are the first lesson. A session is a file with one writer at a time, and its identity is the file’s. You can move it between accounts of the same tool. You cannot move it between tools: a Claude Code transcript means nothing to Codex. What crosses from one tool to another is a written account of the work, the task, what was done, what is left and where the evidence is, and never the conversation itself.

The second lesson is about presence. ccli can tell which Claude Code sessions are running, because Claude Code writes a small file per live process. Codex, Pi and the Cursor tools keep no such registry, so ccli cannot say whether their sessions are running at all. An index of sessions answers “which contexts exist that I could resume?” It does not answer “which of them is listening right now?”, and resuming a stored conversation is a different operation from delivering a message to one that is open.

olympus: put the agreement where nobody can deny it

In July I wrote olympus, a coordination layer that lives entirely in one git repository: a registry of members, human or agent, with their domains and permissions; interface contracts; tasks; and mailboxes, one folder per member and one file per letter, which makes them “conflict-free by construction.”² Its README lists the failures it was built against. Two of them come up again and again. One it calls “I’ve done it”: the agent says the work is done and nothing was written. The other is the waiting deadlock: “A asks B a question and idles; B is heads-down and never saw it.”

The lesson from olympus is that the shared record has to be the authority. A letter is information, not an instruction, so a message cannot make an agent do anything its own rules would not allow. A task is claimed by a commit, so two agents claiming it at once collide in git rather than in conversation. A task is done when a named test and a commit say so; prose does not count. The waiting deadlock, though, olympus could not fix by itself, because a letter in a mailbox does nothing until someone reads it.

wakeme: delivering into a running agent is the hard part

So I wrote wakeme, which wakes a Codex thread when something it watches changes, for example a new letter in an olympus mailbox. Its notes from 31 July, checked against stock Codex 0.146.0, are the most precise statement of the delivery problem I have.³

Stock Codex had no primitive to wake, notify or subscribe to a thread. Its App Server could rejoin a running thread, and it had a method to steer a turn in progress, which is exactly what unattended automation must never call. The obvious approach, read whether the thread is idle and then start a turn, has a check-then-act race: between the read and the start, a person can begin typing or another trigger can arrive. wakeme therefore starts work only through an atomic admission on the server, an experimental thread/wake that I added on a branch of my Codex fork. It returns either the id of the turn it started, or that the thread is busy, already has a trigger waiting, or is in plan mode. Without the fork, wakeme falls back to a cold start with codex exec resume, which is always correct and never instant.

Three more rules from wakeme carry over to any agent-to-agent design. It never answers an approval or input request on a person’s behalf. It advances its record of what it has delivered only after the exact matching turn completes; a busy thread, an error, a cancellation or an unknown outcome all leave the record where it was, so the delivery is repeated rather than lost. And it does not pretend the transport is perfect. In its own words, “Effective exactly-once comes from semantics, not transport”: the wake says only “rescan the authority,” so a duplicate, lost or reordered signal ends in the same state, and a duplicate costs one cheap turn that finds nothing new.

wakeme’s architecture document drew the whole stack in four layers:

flowchart TB
  H["Human surface<br/>pull requests, project boards, notifications<br/>watch, approve, merge"]
  C["Collaboration record<br/>olympus: tasks, letters, decisions in git"]
  W["Wake runtime<br/>wakeme: observe, batch, wake"]
  E["Execution<br/>Codex App Server and its terminal UI: threads, turns, approvals"]
  H --- C --- W --- E

The four layers wakeme’s design assumed in July 2026. Each can be removed on its own: without wakeme, people wake the agents by hand; without olympus, wakeme is a general tool that wakes a thread when a source changes.

Put the three together and the problem has a shape. ccli is an index of contexts. olympus is a durable shared record. wakeme is honest delivery into a running agent. Agent-to-agent collaboration is those three joined, across tools and machines, with a person able to see and stop all of it.

What a name points to

Treat an agent as a model and you lose its tools, permissions and memory. Treat it as a session and you mistake one run, which can end at any moment, for a lasting identity. The pieces have to be named separately:

Thing	The question it answers
The person or organisation	on whose behalf the work is done, and who can grant and revoke it
An agent identity or alias	who usually takes this kind of work, such as reviewer
A durable task	what this piece of work is: inputs, scope, deadline, the test for done
A session instance	which context is doing it, and whether it has restarted or forked
A client connection	who can safely deliver to, cancel or display that session right now
The model and its tools	what it can actually do, at what cost, inside which data boundaries

So “@reviewer” and ”@ that running session” must mean different things. The first asks for a capability, and the system may hand it to an existing session or start a new one. The second asks for a message to enter one specific context, which needs that client’s cooperation: someone has to order the message against the person’s own typing, show where it came from, decide what happens if the session forked, and persist it in the session’s history.

What should last is the task, the authority behind it, the versions of its inputs and its results. A session is closer to a lease on a context: useful, but compacted, resumed, forked and closed, and changed by the next client update. Make the session the only source of truth and both offline recovery and cross-client work become fragile.

Personal agents got addresses

The products launched this year show what an address can be.

Grok Bot gives each person a set of bots reachable from where they already are. On X, “Tag @bot in a post or reply on X to hand that post to your Grok Bot as a task”; in a group chat, “Type @ and select a Bot”; in Slack, a team’s bots each get a handle of their own. Users can claim an email address for their bots, one per person; the address belongs to the person rather than to any bot, and for teams every outgoing email waits as a draft until a person presses Send. Bots in a group chat “pass work, assign ownership,” handoff between them is an asynchronous message, and they can hand coding tasks to Cursor’s cloud agents.¹

OpenAI’s dots, launched on 29 September, each have a handle like @yourname-dot, are reachable in ChatGPT, Slack, Teams and by phone, and can “create Work or Codex tasks on a connected computer.”⁴ Anthropic’s Claude Duet, a research preview from 21 October, is “a new app where Claude works as a proactive agent,” carrying over memory, skills and connected apps.⁵ Meta’s Muse, from 8 September, went the other way on purpose: it is “contained so no one else’s agent can reach it.”⁶

For coding agents, Claude Code added messaging between sessions on one machine: one session finds another with ListAgents, sends with SendMessage, and can name the target as @session-name. The receiving session can be set to accept, hold or refuse incoming messages, and a message cannot change its configuration.⁷ Codex lets agents message each other only inside one session’s tree of subagents.

I like Grok Bot’s design most, because it gets the order right. The address belongs to an identity that outlives any one conversation. A mention turns a piece of content into a task. The person owns the address. The side effect that matters, an email leaving, waits for a human hand. Address, inbox, task and a human gate on effects: that is the shape agent-to-agent work needs. What every one of these products stops at is its own wall. Grok Bot’s bots talk to each other, dots hands work to Codex, Claude Code sessions talk to each other, and none of them, as far as their documentation says, talks to anyone else’s.

The protocols, layer by layer

The protocol work of 2026 is further along than “nobody has defined how agents talk.” Each protocol covers one boundary well.

A2A, the Agent2Agent protocol, released version 1.0 in March 2026 and joined the Linux Foundation’s Agentic AI Foundation in August.⁸ It defines how one agent service finds and uses another. An Agent Card, served at /.well-known/agent-card.json and optionally signed, describes what the agent offers. Clients send messages, stream results, and get, list, cancel and subscribe to tasks, which move through SUBMITTED, WORKING, INPUT_REQUIRED, AUTH_REQUIRED and four terminal states, COMPLETED, FAILED, CANCELED and REJECTED. An A2A service can start workers internally as needed. What it standardises is the service boundary. How a person’s interactive terminal session is found, queued and written into its history is left to whoever implements the service.

MCP, a founding project of the same foundation, lets a client use tools, resources and prompts. It is a good way to expose a common entry point for agent communication: look up agents, submit a task, read a mailbox, fetch a result. But a call to an MCP send tool proves only that the request reached the tool. It does not prove the target session received anything, and an MCP connection’s lifetime is not the conversation’s.

The Agent Client Protocol, ACP, created by Zed, standardises how a client drives a coding agent: session/new, session/load where supported, session/prompt, a stream of session/update notifications, session/cancel, and requests for permission.⁹ Version 2 is still a draft. In it the response to a prompt only acknowledges that the prompt was accepted, completion arrives later as a state update, and session/load gives way to session/resume with a point to replay from. That draft is the closest any protocol comes to the delivery states in the next section, which is why it should not be read as a guarantee every client already makes. Adapters exist that put Codex (built on its App Server) and Claude’s agent SDK behind ACP, so one host can drive both. They drive sessions the host creates or loads. They do not take over a session someone already opened in another terminal.

Microsoft’s Agent Host Protocol gives several clients a synchronised view of the same agent session, and says plainly where it stops: “AHP coordinates clients, not agents. If agents need to talk to each other, that’s a separate concern.”¹⁰ AG-UI standardises the events between an agent and the interface a person watches. ANP proposes a suite for agent identity, naming, discovery and secure messaging across organisations. agentgateway is a data plane that proxies, among other things, the MCP and A2A traffic agents send.¹¹

Boundary	Existing work that fits	What it leaves open
An agent using tools and data	MCP	delegating to another agent
Independent agent services	A2A	delivery into a local interactive session, and its ordering against the person
A client driving a coding agent	ACP	naming across hosts, mailboxes, chains of delegation
Several clients sharing a session	AHP and similar hosts	tasks and permissions between agents
A person watching and stepping in	AG-UI, or the product’s own interface	identity, authority and whether a task really happened

So nobody needs to invent one protocol for every layer. What is not settled is the contract between them: how a request that a person authorised finds the right executor and becomes, in a way anyone can check, a task, a set of session events and a result.

The chain of states behind “sent”

Imagine two agents sending to the reviewer at once while a person is typing in the reviewer’s terminal. One message reaches the mailbox first and the other reaches the client first. The client writes the second into the transcript and crashes before telling the control plane. If the system shows one green “sent,” that failure can never be diagnosed.

I would record each stage separately, as the states a message passes through on its way to becoming a result:

flowchart TB
  subgraph seen["What the control plane can see"]
    direction LR
    A["accepted<br/>by the control plane"] --> S["stored<br/>durably"] --> C["claimed<br/>by a client"]
  end
  subgraph only["What only the receiving side can see"]
    direction LR
    P["admitted<br/>by its policy"] --> R["recorded<br/>in the session's history"] --> T["taken on<br/>as a task"] --> D["result submitted<br/>with evidence"]
  end
  seen --> only

Seven states from accepted to a submitted result. Any of them can end instead in rejected, expired, canceled or failed, and each component can vouch only for the states it saw.

Each layer can prove only what it observed. The transport can say a message was stored. A client can say it claimed it. Only the receiving side can say its policy allowed it and its history now holds it. Even then, each state proves less than it seems to. Being in the transcript does not prove the model understood the request. A model answering does not prove an external effect happened. wakeme’s protocol notes make the same point about its own layers: if a turn completed without actually processing a letter, the letter is still open in the repository, and the next rescan is the retry.

That turns a vague wish into concrete requirements, all of them dull and all of them decisive: message ids, keys to drop duplicates, an order per session, deadlines, queue limits, queueing by default while the receiver is busy, cancellation, and recovery after a crash. Do not promise that anything runs exactly once. If an external API call succeeded and the process died before recording it, a blind retry runs the effect twice. The system needs idempotent operations or a separate record of commits, and when it cannot tell, the state to show is “result needs checking,” never success.

The client adapter’s duties follow. It has to know which session instance it is delivering to, so that a history resumed by two processes does not receive the same message twice. It has to put the message into the session’s formal history without overwriting input the person has typed and not yet sent. And it has to report only the acknowledgements it can prove. Typing into a terminal with tmux send-keys can demonstrate the effect, never provide these guarantees, and resuming a stored conversation is not delivering a message to the one that is running, which is exactly what wakeme learnt the hard way.

Does more talking make better teams?

The research of 2026 is more restrained than the demos. A September preprint found that multi-agent harnesses help “specifically in long-horizon tasks with sparse dependencies, while single-agent harnesses remain superior in tightly coupled, sequential workflows,” and traced the gap to growing context overhead.¹² An October study of teams of coding agents found that teams on ProgramBench “cost three to seven times as much” as one agent, that planning was “the most valuable use of workers,” and that implementers and verifiers stopped improving beyond four.¹³ Each result belongs to its own benchmark. Neither is a law of software engineering, and both point the same way. In April, bloop, the company behind Vibe Kanban, one of the better-known third-party boards for running many agents, shut down, although the project continues as community-maintained open source.¹⁴

That changes what free communication is for. The scarce resource is probably the receiver’s attention, its context budget and its ability to merge work reliably, far more than bandwidth. If every agent can consult any other at any time, the result is duplicated work and recursive fan-out. A scheduler should first ask whether a task splits into fairly independent results, when a second opinion is worth its cost, and when one strong agent with tools is enough. A room shared by people and agents can stay open, but background work should be asynchronous by default, a busy session should queue, and automatic re-delegation should be limited by budget and depth.

Measure against a single agent. Success rate, wall-clock time, total tokens and cost, duplicated work, human interventions, recovery time and unauthorised actions belong in the same table. If two agents only produce more messages, without a better result or a shorter critical path, being more like a team is no reason to keep them.

Messages carry attention, results carry facts

On one machine, shared files and git already work well. “Please look at the auth change in commit abc123, mainly the permission fallback; the test log is in this file” usually beats forwarding a whole conversation. But a path points to the same content only in the same workspace at the same moment. Across machines, or with uncommitted changes, it can point to a different file.

So a reference that crosses runtimes should carry the workspace and repository identity, a commit or snapshot, a relative path, a digest of the content and the permission to read it. Uncommitted work can travel as a patch or a controlled snapshot. The receiver checks the digest first, then reads what it needs. Results work the same way: a conclusion should link to a diff, a test log, data or a command that reproduces it, never just “I checked.”

One 2026 study gives this an experimental footing. PACT projects verbose agent output into compact updates of action and state; in its tests it “lifts OpenHands’ resolve rate at -10% tokens-per-resolved” and leaves SWE-agent’s resolve rate unchanged while halving its input tokens.¹⁵ I would give a formal message at least these fields: the intent, the action asked for, references to inputs, the facts already known, the open questions and the test for done. Natural language still does the negotiating and explaining. Scheduling, authority and verification need fields a program can read.

There is a benefit that is easy to miss. The receiver does not inherit the sender’s whole history. What is shared is the evidence for the task, not two context windows glued together. That costs less, and it gives secrets, stale instructions and injected prompts fewer chances to travel down the chain.

Will models talk in their own internal state?

It is no longer true that different models can only exchange natural language. Structured data always crossed models, and a paper from August, the method it calls XKV, trains a translator so that frozen models that “may differ in family, depth, KV-head count, head dimension, and tokenizer” can exchange key-value caches directly; end to end it ran 26% faster than the LCF-X baseline and 6.8 times faster than text.¹⁶ Latent communication between different models is possible.

Speed alone does not make it fit for an open network. The translator is trained for each pair of models, a model upgrade can break it, and internal state is hard to audit and may carry inputs the receiver was never meant to see. LCGuard, a defence from May, learns transformations of the cache that reduce how much of a sender’s private input an adversary can reconstruct from it, which shows how real that leak is.¹⁷ A causal audit from August warns that “Benchmark deltas do not by themselves establish latent-thought transmission; establishing it takes a mismatched-cache audit.”¹⁸ A study of cache integrity from June adds that “A visible message may look harmless even if the hidden state has been changed,” and shows an HMAC manifest that accepted all 774 honest payloads and rejected all 295 tampered ones.¹⁹

I would keep latent communication on the performance research track, inside clusters someone controls end to end. Open, auditable collaboration across clients rests for now on text, structured state and references to results with a source. If the latent layer matures, it can speed up chains of work that already run correctly, without replacing a person’s authority or the evidence for a result.

Authority is not a signature

Once agents can talk to each other directly, a low-privilege agent that read an injected instruction in a web page or a repository file can ask a high-privilege peer to read a secret or push code for it. A signature proves who sent a message, not that anyone allowed the request. OWASP’s guidance for multi-agent systems says it in one line: “A valid message signature does not grant permission to perform the requested action.” It also asks receivers to sign the sender, recipient, type, payload, times and a unique id, and to reject repeated ids atomically across every instance of the receiver.²⁰

A workable chain of delegation starts with a person’s authorisation and keeps, at every hop, both on whose behalf the work is done and who is acting now. OAuth 2.0 Token Exchange, RFC 8693, already separates the two: the subject is “the party on behalf of whom the request is being made,” the actor “represents the identity of the acting party,” and an act claim records that “delegation has occurred.”²¹ For a task, the permission should also bound the receiver, the repository and paths, the actions allowed, outside network access, the budget, the deadline and how many more times it may be delegated. Each hop may only narrow it, and the tool that executes the action checks it outside the model.

A2A leaves this to implementations on purpose. Its latest specification says that “The A2A protocol does not define the scope, representation, validity, or revocation semantics of the authorization decision or credential obtained” when a task asks for authorisation;²² that clause was added in July and is not yet in a tagged release. Products show the same principle in small ways. Grok Bot holds a team’s outgoing email for a person to send, and a Claude Code session can hold or refuse what other sessions send it. In February NIST started an initiative on standards for agents, with identity and authorisation among its first topics.²³

Revocation stops actions that have not happened yet. It cannot unsend an email or undo a push, so the audit log has to record requests and results, with a limit on how long it keeps sensitive content. And there is a boundary people forget: passing internal code to another model service can change where the data goes. Model-independent does not mean the person agreed to let any provider read the same material.

Do you need a gateway?

You need a logical control plane. Name resolution, available capabilities, durable mailboxes, task events, permission checks and the audit trail have to live somewhere. That can be a daemon on one machine, an event log in the workspace with a sidecar, or a federated service across machines. A central gateway is one way to deploy it, not its definition.

If I started today, I would build a host per user or per workspace. It keeps an append-only event log and a small store for results, registers the agent sessions it starts with short leases, and owns ordering, task claims and permissions. Clients submit requests through a CLI or MCP. Coding agents that it controls are driven over ACP, so it knows which session handles which prompt and what updates came back. Remote services that stand on their own talk A2A at the edge. A room is a shared view of the log, an @ is how you pick a recipient, and a task is a set of events with evidence.

The choice that matters most is to manage sessions from the moment they are created, which is the step wakeme’s fork took for Codex. A host that holds the connection knows what it delivered and when. It still has to show where a peer’s message came from, so that another agent’s words never arrive looking like a high-privilege instruction from the person. For sessions someone opened in another terminal, whose client offers no way in, the honest options are a mailbox, a notification or an explicit claim; do not fake live delivery. Whether a true @existing-session ever works depends on each client opening an entry point with acknowledgements.

The list I wrote for myself in July was blunt about the order of work: do not build a new interface first; build on stable primitives that already exist, a git repository, pull requests, issues as an inbox, GitHub Apps; and have one place where every agent’s state and every task’s progress is visible at a glance. olympus did the first half. The second half is the view, which is exactly what the event log makes cheap.

Discovery across the open network can wait. Proposals such as ANP explore identity, discovery and messaging between organisations, but being findable everywhere does not solve spam, permission, privacy, payment or trust in results. Direct peer-to-peer still needs offline mailboxes, roots of trust and a way to spread revocation. Getting collaboration right inside one workspace, and then exposing a stable agent capability as an A2A service, is a clearer path.

What I would bet on

These are judgements from the interfaces and constraints that exist today, not probabilities.

Likely: collaboration across models and clients inside a host that controls the sessions. The host creates or explicitly imports sessions, uses formal interfaces such as ACP for input and progress, keeps tasks in an event log and exchanges content as references with digests. Change the model or close a session and the work can still be resumed. The ACP adapters for Codex and Claude have already shortened the distance to a prototype.

Possible, with conditions: @ straight into any existing interactive session. The condition is that the target client opens a formal way in, with ordering, a mark of where the message came from, and acknowledgements. Without that, reading a transcript, resuming a session or typing into a terminal is not reliable delivery. This may become a standard across clients, or each client may build its own for years. Claude Code’s messaging between sessions and Grok Bot’s threads show it working inside one vendor’s walls.

Research for the long run: open agent networks across organisations, and latent exchange between different models. The first is hard because of identity, authority, the quality of discovery and the economics. The second is hard because of compatibility between models, whether information really passes, secrecy and audit. Both are worth following. Neither should be a condition of the first version.

This also corrects my starting goal. “Let every agent ignore its client and its model completely” cannot be done in the strict sense. The client decides when a message enters the agent’s loop, and the model changes the quality and cost of the same task. The useful goal is to make the task contract and the results portable, and to state and negotiate the differences openly. The system does not need every agent to be alike. It needs each one to say clearly what it can do and what it actually did.

An experiment that can fail

The plan below is written so that it can prove me wrong.

1. Define the meaning before connecting anything. Give agent aliases, tasks, session instances, permissions and results their own ids. Name the states, queued, admitted, working, completed, failed, rejected and expired among them, and say what evidence moves each one. Keep received and done apart.
2. Go deep on one machine and one workspace, with two clients that join on purpose. Let the host create the sessions, deliver one read-only review task and collect a conclusion with references. Then break it on purpose: keep the receiver busy, type while it delivers, kill the host, resume the session, send the same message twice. Check that no task reaches the wrong session, that no typed input is overwritten, and that a repeated claim does not repeat an effect. If the interface can only prove that a message reached the mailbox, the product says only that.
3. Add tasks that do things, with every tool call decided by a policy outside the model. Test narrowing re-delegation, revocation, expiry, an exhausted budget and a hostile peer message. When an external effect may have happened but cannot be confirmed, the state stops at needs checking. Until the receiver can enforce permissions, no agent executes work for another automatically.
4. Put it in real work and compare it with one agent. Use work that splits, such as code review, parallel fact checking and independent tests, and work that does not, as a control. Add agents only when quality, time and total cost come out ahead. Synchronising across devices, federating over A2A and richer identity come last.

The conditions for stopping matter more than the vision. If neither client can confirm that a message entered its formal history, give up the promise of live delivery into arbitrary old sessions. If retries after a crash repeat external effects, do not widen the fan-out. If several agents do not beat one over time, call the result infrastructure for collaboration and visibility, not a machine that adds intelligence.

Questions that stay open

Will names in an open network of agents be squatted like domain names, and who checks an Agent Card? An agent claiming to be good at security review and an agent that has delivered trustworthy reviews for a year are different things. Reputation needs a record of tasks that can be checked, not self-description.

How much should a person be in the room? Fully live, they are interrupted constantly; fully in the background, they lose their grip on authority and correction. Perhaps the best experience lets a person see every event at any time but tells them only about decisions, rising risk and finished results. That needs real use to settle, not protocol design.

And a deeper one. Communication between agents may end up looking less like a chat room run at high speed and more like software systems exchanging promises that can be executed. A good message should let the receiver judge exactly what it is asked to do, on what authority, on which version of the input, by when, and how to prove it is done. Conversation still has its place, as long as it ends in a next step someone can check.

Starting from ccli, I first saw a lot of scattered sessions. Looking further, what is worth connecting is not a pile of terminal windows but the work that persists behind them. The @ is the entry, a session is one run, and a gateway is one way to deploy the control plane. What could let different agents work together is durable tasks, authority that only narrows, and results anyone can check.

Footnotes

1. xAI, “Introducing Grok Bot”; “Tag @bot on X”, not available to accounts in the UK, EU, EEA or Australia; “Message and collaborate”; “Give your Bot an email address”. ↩ ↩²

2. olympus. ↩

3. wakeme, in particular docs/protocol.md and docs/architecture.md; the experimental thread/wake is on the wakeme-thread-wake branch of my Codex fork. ↩

4. OpenAI, “Meet dots”. ↩

5. Anthropic, “Introducing Claude Duet”. ↩

6. Meta, “Introducing Muse: The World’s First Personal AI Agent Built for Everyone”, 8 September 2026. ↩

7. Claude Code docs, “Message your other Claude Code sessions”. ↩

8. A2A specification; “A2A joins AAIF”, 17 August 2026. ↩

9. Agent Client Protocol, v1 overview and migrating to v2; adapters codex-acp and claude-agent-acp. ↩

10. Agent Host Protocol, “AHP and the Agent Client Protocol”. ↩

11. AG-UI; ANP; agentgateway. ↩

12. “Rethinking Multi-Agent Collaboration: When More Is Less”, arXiv:2609.19759, September 2026. ↩

13. “Scaling Inference-Time Compute with Teams of Coding Agents”, arXiv:2610.17471, October 2026. ↩

14. Vibe Kanban, “Goodbye bloop”, 10 April 2026. ↩

15. “What Should Agents Say? Action-state Communication for Efficient Multi-Agent Systems”, arXiv:2606.05304, June 2026. ↩

16. “Dual-Cache Latent Space Communication between Heterogeneous Language Models”, arXiv:2608.20617, August 2026. ↩

17. “LCGuard: Latent Communication Guard for Safe KV Sharing in Multi-Agent Systems”, arXiv:2605.22786, May 2026. ↩

18. “When Does Latent Communication Pay? A Causal Audit of Relayed KV Caches in Multi-Agent LLMs”, arXiv:2608.04893, August 2026. ↩

19. “When Latent Agents Lie: KV-Cache Integrity in Multi-Agent LLM Collaboration”, arXiv:2606.28958, June 2026. ↩

20. OWASP, “AI Agent Security Cheat Sheet”, section 7. ↩

21. RFC 8693, “OAuth 2.0 Token Exchange”, January 2020. ↩

22. A2A specification, section 7.6.4, “In-Task Authorization Scope”. ↩

23. NIST, “Announcing the AI Agent Standards Initiative”, February 2026. ↩