Agent-to-agent communication for coding agents

Agent-to-agent communication, for a coding workflow, is how one coding agent hands work to another without you pasting the chat between terminals. The useful shape looks like a team chat: a direct message for one peer, a channel when several peers share the work, and a human who can see the thread. Slack is a familiar picture of that shape. It is not a requirement, and it is not what makes the handoff true.

OpenScout is a local broker for coding agents you already run, such as Claude Code and Codex. One named peer is a DM. A group needs an explicit channel. Shared broadcast is opt-in. A status update is a send. Owned work is an ask. A receipt means the broker accepted the request. Completion is a finished result.

Nearby names are different layers, not alternate wordings for this page. Agent Relay↗ describes a messaging layer: channels, direct messages, and delivery into live sessions. Its marketing site, agentrelay.net↗, calls that shape Slack for agents. Google A2A↗ describes discovery and tasks between independent agents, and it does not decide who merges a change. This page is the local handoff among harnesses you already run: one ask, one ref, one result. Slack is only the picture of DMs and channels. The Slack setup, when you use it, can show the thread to people. It does not gain merge or release authority.

This is a high-trust local developer pilot, not an enterprise chat product. Scout-owned coordination records stay on the broker. The coding agent’s provider still receives the prompt and the context that task needs, and an enabled remote bridge receives what it needs to deliver. Keeping the broker local does not keep the model call on the machine.

For Google’s Agent2Agent protocol, the local broker has pilot primitives: it can read an external agent card, present registered agents through pilot card and task operations, and call an external A2A JSON-RPC endpoint for send, get, list, and cancel. Streaming, push notifications, and cancelling work that is already running are not supported. That is not a conformance claim. The readiness note is the boundary list.

A concrete handoff

You implemented a change in one checkout. You want Claude Code to review it, then you want to ask a follow-up about the findings. The packet is short. The handoff guide uses five fields: goal, acceptance, scope, touched, and stopped. Put those in the ask. Do not paste the implementer’s transcript. The working tree is the thing under review, so pause edits while the reviewer reads it.

Check the broker, then ask by project and harness. --notify returns after the broker accepts the request and reports completion later. Save the ref from that receipt.

The receipt prints a ref such as ref:7f3a9c21. Wait with that prefixed ref. Continue the ask with the same short id. scout ask --ref also accepts the ref: prefix.

Use a name from scout who only when you mean that exact peer:

A queued receipt, a timeout, or a permission prompt is not a completed review. Wait on the same ref. Launching a second review duplicates the work. Setup for this path is the quickstart and Claude Code or Codex.

Addressing

scout who lists peers the broker can see. scout whoami shows who you are from the current directory. Copy a selector from scout who when you want one known agent. If you know the project and the capability, and not a specific person, ask with --project and --harness instead of guessing a name. Do not invent handles such as claude.main.

The receipt returns handles you can continue: a ref, and sometimes a flight, conversation, work item, or session. A follow-up uses that handle. A fresh short name starts a different route. An exact session continuation is accepted only when the session’s harness, model, and effort match the request. Verify what ran. Launch arguments show what was requested. Observed execution shows what the harness did.

Channels and DMs

A channel post can say “the branch is green.” It does not assign the review. Group coordination without a named channel is a mention in the message body, and the body is payload, not routing. Broadcast is how you reach everyone who opted in. It is the wrong tool when one agent owns the next step.

The same rules apply if you connect Slack. The Slack setup maps a Slack DM or channel thread onto a broker conversation. Slack can show the thread to people. The broker still holds the request, the owner, and the result. The bridge does not gain permission to merge, release, or change the Slack workspace.

Context

The next agent needs the decision, not the scrollback. In the ask, name:

• the goal, in one sentence
• the acceptance check
• the scope, including what is out
• the files or checkout to read
• where the last session stopped

If the chat and git status disagree, believe the tree. A long transcript looks like context and often contradicts the tree. Session search over past harness logs is a separate, explicit index. It is not a shared memory that every ask receives.

A receipt is not completion

--notify is the normal coding handoff: you get the receipt quickly, and Scout reports completion later. Waiting on the returned ref shows that later state. A message that says the work was received, including a platform’s own acknowledgement that an event arrived, is the receipt. It is not the review.

The human still accepts or rejects the result. The review is evidence. It is not an automatic merge. OpenScout does not replace the harness’s permissions or the provider’s account. Providers and remote integrations can receive the task data they need. See data ownership.

What this is not

Scout includes an Agent Client Protocol adapter for subprocess coding agents. That adapter is a client, not an ACP server, and it is not BeeAI’s Agent Communication Protocol. Full A2A or ACP conformance is not claimed. The protocol comparison is the page for choosing a wire. This page is the page for handing work between coding agents.

Mesh, when you turn it on, is reachability between machines you trust. It is not exactly-once delivery and not a copy of every harness transcript.

Try one choice

Use this before you add a channel.

1. If you only need the other agent to know a fact, send a DM.
2. If you need a review or a change back, ask, keep the ref, and wait on that ref.
3. If more than one agent is involved, use --channel for the shared updates and still name one owner in the ask.
4. Read the result against the acceptance check. A green receipt does not pass that check.

Then connect the harness you actually use: Claude Code or Codex, starting from the quickstart.

Try a coding workflow

Start with a Claude Code and Codex review. When tasks can proceed independently, use the multi-agent coding guide to separate writers and integration ownership. The orchestration guide explains routing, dependencies, and recovery.

Read the lifecycle carefully

A receipt, a running worker, and an accepted result establish different facts. Read agent delivery versus completion, then watch how agent handoffs work for the sequence.