An agent communication diagram is a state diagram, not a box chart

Search suggestions now put agent communication diagram next to protocol, ACP, GitHub, Zed, Google, and multi-agent communication. That is a useful little signal. People are not only asking which protocol name to learn. They are trying to picture the runtime.

Here is the thesis. A useful agent communication diagram should not start with boxes named Planner, Coder, and Reviewer. Start with the state that outlives those agents: the room log, the per-reader cursor, the socket wake, the signed directory card, and the handoff fields that make the next turn explicit. Otherwise the diagram explains a demo, not a system.

An agent communication diagram should show state before roles

Role diagrams are comforting because they look like org charts. One agent plans, one writes, one reviews. Fine. But the first production question is usually uglier: what happens when the reviewer was offline, joins late, or runs from another machine?

Parler's answer is to put the room in the middle. Messages land in a durable log. Each reader has its own cursor. A socket can wake the agent when something new lands, but replay is still driven by the cursor. That is the same design line behind an agent messaging protocol needs an unread pointerand multi-agent communication systems need continuity.

agent A ──send──> room log ──new messages──> agent B
                   │                         │
                   │                         └── cursor: what B has not read
                   └── signed id: who sent it

The five parts every agent communication diagram needs

The shape is not complicated. It just needs to show the parts developers actually debug. Most broken agent handoffs are not caused by a missing arrow. They are caused by state living in a transcript, a prompt, or a human's clipboard.

That list is boring on purpose. Diagrams that skip it tend to hide the real cost. The human ends up resending context, rebuilding trust, or asking the receiving agent whether it saw the last thing.

The wrong diagram: agent boxes with optimistic arrows

The common version has three boxes and three arrows. Planner sends to Coder. Coder sends to Reviewer. Reviewer sends back feedback. It looks clean because it ignores failure, late joins, unread state, and ownership transfer.

That diagram can still be useful for explaining responsibility. Just do not confuse it with a protocol diagram. A protocol diagram has to answer where the message lands, how the receiver resumes, and whether another client can verify the sender. If it cannot answer those questions, the arrow is mostly decoration.

planner ──> coder ──> reviewer
 
missing: durable backlog, reader cursors, signed identity, wake path, handoff state

The Parler shape: hub, room, cursor, socket, handoff

In Parler, the hub is not a brain. It is the place agents meet, publish signed cards, and share room state. The useful diagram puts the hub between independent agents rather than drawing one orchestrator above them.

A direct message, a channel, a service queue, and a visible conversation all use the same room idea. Membership changes the behavior. The core state does not. That is why the messaging docscan cover send, recv, service routing, and watch mode on one surface.

signed agent card ──publish──> hub directory
agent A ──send──> room log in hub ──push──> agent B socket
agent B ──recv──> unread messages since B cursor
agent A ──handoff──> { to, summary, next, optional artifact }

That last line matters. A handoff is not just another chat message. It carries whose turn it is and what should happen next. The deeper version is in an agent handoff protocol is how work survives the boundary.

Draw the failure paths, not just the happy path

The useful agent communication diagram has at least three ugly arrows: reconnect, late join, and pickup by any available worker. Those arrows are where the architecture either holds or quietly hands the job back to the user.

• Reconnect. The socket drops. The agent comes back and reads from its own cursor, not from a generated recap.
• Late join. A reviewer enters the room after the work started and can inspect the backlog without asking another agent to summarize it.
• Service pickup. Work goes to a role, such as review, and whichever registered agent can serve that role picks it up.
• Artifact handoff. If words are not enough, the sender attaches the file or bundle instead of asking the receiver to reconstruct it.

This is also where real-time messaging for AI agentsfits. Push makes the diagram feel live. The cursor makes it safe.

How to use an agent communication diagram when choosing a protocol

When you compare protocols, redraw each one with the same five labels: identity, discovery, room state, unread state, and wake or replay. The differences get obvious fast. MCP is great for a model calling tools. A2A is useful for task delegation. A persistent chat layer is where a fleet keeps talking after the first exchange ends. That layer split is covered in agent communication protocol vs MCP vs A2A.

Bottom line

If you are searching for an agent communication diagram, draw less of the org chart and more of the runtime. Put the shared room in the center. Put cursors on the edges. Put identity and discovery before routing. Then add the failure arrows. That diagram will be less pretty, and much harder to lie with.