toli: connecting existing Claude Code, Codex & other coding agents over A2A, even on different machines

[arjunvlama]

Hi everyone! I maintain toli (Apache-2.0, Go, built on a2a-go).

I built it after running into a problem with a colleague: our coding agents had different context, and we kept having to relay messages between them manually.

toli puts existing coding agents that don't natively speak A2A (Claude Code, Codex, OpenCode, OpenClaw, Pi) on the network as A2A agents. They can delegate tasks, ask each other questions, exchange results, and collaborate across machines without switching agent harnesses.

Each developer runs a self-hosted daemon. Local agents connect over MCP on localhost, while daemons communicate over A2A. There's no central server: developers pair their agents with one-time invites and control which peers each agent can talk to.

Repo: https://github.com/arjunvlama/toli

How it maps onto A2A

A few design decisions that might interest this community:

• Agent Cards and privacy: One card per agent. Public cards carry identity and connection info with an empty skills list; skills are on the authenticated extended card (GetExtendedAgentCard).
• A2A 1.0 + 0.3: Each card advertises both interfaces (/a2a/<agent>/ and /a2a/<agent>/v0.3/). We use a2a-go's compatibility package to translate between versions at the edges.
• Interactive task lifecycle: Agents can respond with input-required to ask questions, report progress with working, and finish with completed and artifacts. toli also wakes supported running agent sessions when new work arrives.
• Session continuity: We use A2A contextIds to group related tasks and messages, including client-supplied IDs with peers that support them.
• Polling and consistency: We currently poll for task updates rather than using push notifications. To avoid regressing state, we reject stale responses that omit already-observed messages or attempt to replace a terminal state.
• Authentication: Each pairing exchanges bearer tokens, one for each direction.

The local side (MCP)

• Each agent gets its own MCP endpoint and token on the local daemon. The MCP tools map onto A2A: delegate sends a message and creates a task on a peer, update_task moves a task the agent accepted through working / input-required / completed, and get_delegated_task_updates reads the peer's latest reported state.
• Waking sessions: When work arrives, toli wakes the agent's running session using whatever that harness supports: a session socket (Claude Code), a CLI command (Codex, OpenClaw), or a plugin that pulls notifications (OpenCode, Pi). Sessions register via harness hooks when they start.
• The human stays in charge: agents can only use the peers their human paired them with; nothing on the MCP side can add peers.

Questions for the community

1. Interactive agents: Has anyone else put existing interactive agent sessions, rather than request/response services, behind A2A? Waking an idle coding-agent session and delivering incoming work turned out to be one of the harder parts.
2. Task generations: The Task.generation work for 1.1 looks useful for detecting stale reports and enabling long-polling. Is anyone tracking when Go and other SDKs will support it?
3. Client-supplied context IDs: §3.4.1 allows servers to accept them but advises clients not to assume support. Is there an agreed way for an Agent Card to advertise that capability?
4. Task trees across agents: Something we're exploring next: a task fans out into subtasks across multiple agents and machines, which may delegate further. We'd like the originating agent to be able to discover and track the entire task tree. referenceTaskIds provides references to related tasks, but doesn't establish parent-child relationships or enable cross-server discovery. Is there an established pattern for this, or any planned work in A2A?

Happy to share implementation details, compare interoperability notes, or hear where our interpretation of the spec could be improved!

[capitaharlock]

With public cards leaving skills empty, does GetExtendedAgentCard filter skills for the requesting peer, or does every peer authorized to talk to that agent get the same skills list?

[arjunvlama]

Today it's the latter. The reason they're on the extended card is so that only the peers that are authorized to talk to that agent can see its skills, not a peer of another agent connected on the same daemon/machine. This is in case the skills have sensitive information about the project the agent is familiar with or something.

[mqucal100]

You built this after relaying messages between your agent and a colleague's, once a peer is paired, can its owner narrow what that peer may ask for later, or revoke one agent without re-pairing the daemon? I'd be curious how often that came up between the two of you.