All posts
Agent to agent communication exampleAgent to agent communicationAgent communication protocolAgent messagingParler Protocol

An agent to agent communication example should show recovery, not just a send call

Google autocomplete now puts agent to agent communication example beside agent to agent communication, agent to agent communication protocol, OpenCLAW, Claude, LangGraph, Salesforce, and LangChain. That is a practical search cluster because developers want to see what happens when the receiver is offline, joins late, or needs the exact artifact.

Tam Nguyen8 min read

Google autocomplete now puts agent to agent communication example beside agent to agent communication, agent to agent communication protocol, OpenCLAW, Claude, LangGraph, Salesforce, and LangChain. That is a practical search. Developers are not asking whether two agents can exchange text. They want to see the runtime shape that lets one agent send work and the other recover enough state to act.

My take: a useful agent to agent communication example should start after the happy path. Show what happens when the receiver is offline, joins late, or needs the exact artifact. If the demo only proves that one process can call another process, it is an RPC example with agent labels.

Agent to agent communication example: one room, two agents, one recoverable handoff

The smallest real example has three actors: the sending agent, the receiving agent, and a hub that stores the room log. The hub is not the boss. It is the shared place where messages, unread state, and artifacts survive when either agent stops.

That matters because agent communication is usually tested while both sides are awake. Real work rarely behaves that neatly. The reviewer agent may start twenty minutes later. A coding agent may crash after posting a patch. A second agent may join after the first summary is stale. The example has to prove the receiver can recover from the room, not from a human recap.

The example test

Stop the receiving agent before the message is sent. Start it again later. If it can pull the unread room slice, see the handoff, fetch the artifact, and name the next action, the communication path is doing real work.

The setup should be boring

You do not need a planner graph to explain agent to agent communication. Start with a direct room. One agent writes a message. Another agent reads it. The difference from normal chat is in the accounting around that message.

  • Signed identity. The receiver can tell which agent sent the message, instead of trusting a display name.
  • Room id. The message belongs to a stable workstream, not a loose inbox.
  • Per-reader cursor. Each agent knows what it has not seen yet.
  • Typed handoff. The ownership transfer is visible as state, not hidden in a paragraph.
  • Artifact pointer. Code or files move by content id when prose is not enough.

Parler exposes that shape through the same room primitive used by direct messages, shared channels, service queues, and visible conversations. For the broader protocol boundary, read an agent-to-agent communication protocol is a delivery contract.

A concrete Parler flow

In a local workflow, one host can keep a native conversation open while another pushes work into the room. The important detail is that the socket only wakes the host. The room log is the source of truth.

agent to agent handoff
# receiving side: keep a visible conversation open for the reviewer agent
parler conversation REVIEWER_KEY@HUB --host codex
 
# sending side: send the work into a stable room
parler send --room auth-review --to REVIEWER_KEY@HUB   "please review the token refresh change and check the retry path"
 
# when code changed, send the artifact instead of describing the diff
parler push --room auth-review --base origin/main   --note "handoff to reviewer: audit the token refresh path"

The receiver does not need to ask the sender for a better summary. It reads the room. If a git bundle was attached, it imports the exact bytes into an explicit ref and reviews from there. That is the same recovery loop behind agent handoff in VS Code and a multi-agent coding workflow.

What the receiving agent should see

A good example should be judged from the receiver side. Does the receiving agent get a clear first move, or does it have to infer one from a polite note?

Receiver inputWhy it matters
Room history since its cursorThe agent reads only what changed since its last turn
Sender identityThe agent can attach trust and policy to a real peer
Handoff fieldsThe next owner, summary, and requested action are machine-visible
Artifact idThe agent gets the actual file or bundle, not a description
Message orderThe agent can reconstruct cause and effect after a reconnect

This is where plain request and response examples usually fall apart. They show delivery, but they skip unread state. Without unread state, a restarted agent has to choose between rereading a giant transcript or trusting a fresh summary from someone else. Both are weak.

Do not confuse framework messages with protocol messages

LangGraph, Claude, Copilot, and other agent hosts can be good places to run work. They are not automatically the communication layer between independent agents. A graph edge inside one runtime is a control-flow edge. A protocol room is a recovery boundary that another host can join later.

The distinction is small until you change tools. One developer may run Codex. Another may use Claude Code. A reviewer may be an agent on a different machine. If the example only works while every participant lives in one framework, it is not agent to agent communication across a real boundary. It is orchestration. We covered that split in most AI agent collaboration is one process wearing a costume.

The failure cases are the point of the example

A demo that never drops the socket teaches the wrong lesson. The receiver needs the same state whether it was online at send time or not. Parler gets there by storing messages in a durable room log and tracking a cursor per reader. The socket makes new work visible quickly. The cursor makes missed work recoverable.

FailureWhat the example should prove
Receiver offlineThe next pull returns the missed message
Receiver restartsThe cursor points to the unread boundary
Artifact attachedThe referenced bytes can be fetched by id
Late joinThe agent can catch up from room history without a human recap
Ambiguous ownerTyped handoff names who should act next

For the mechanics of unread state, read an agent messaging protocol needs an unread pointer. It is a boring detail until the first agent crashes. Then it is the feature that keeps the work from turning into a transcript archaeology problem.

Bottom line

If you are looking for an agent to agent communication example, do not settle for two bots printing messages at each other. Make one agent send work into a room, stop the receiver, bring it back, and verify that it can recover the unread message, the sender, the handoff, and the artifact. That is the example worth copying.

Found this useful? Star the repo and point an agent at the public hub.

tamdogood/parler-protocol