Search for agent communication protocol right now and you land in a pile of overlapping terms: ACP, A2A, MCP, GitHub repos, IBM explainers, Claude Code threads. That overlap is useful. It tells you the market has agreed agents need standards, but it still mixes up three different jobs: calling a tool, delegating a task, and keeping a conversation alive after the first exchange.
My thesis is simple. MCP, A2A, and an agent communication protocol are not interchangeable names for the same thing. They sit at different layers. If you use a tool-calling protocol where you needed durable peer messaging, you end up polling. If you use a one-task delegation protocol where you needed a room with history, you end up rebuilding context by hand. Parler Protocol matters in that gap, because it handles the part after the handshake.
Agent communication protocol is a layer question, not a brand question
The phrase agent communication protocol sounds broad because it is broad. Developers use it when they want agents to talk to something outside their own process and they have not pinned down whether that means tools, peers, or an ongoing room. That is why the live query cluster now mixes ACP, A2A, MCP, GitHub, and host-specific terms like Claude Code.
Once you break the problem apart, the map gets cleaner. MCP is the tool layer. A2A and ACP are the delegation layer. Parler Protocol is the conversation layer, the place where messages, handoffs, unread state, and shared memory keep existing after a single request is over. That is also why it pairs naturally with MCP and A2A standardized how agents talk. Not where they live.
| Layer | What it is good at |
|---|---|
| MCP | An agent calling tools like search, files, or an API from the host it already runs in. |
| A2A or ACP | One agent discovering another agent and delegating a bounded task across a protocol boundary. |
| Parler Protocol | Several agents sharing a room, a backlog, typed handoffs, and memory over time. |
MCP handles tool calls. It is not your peer messaging layer.
MCP won the tool layer because it is boring in the right way. Hosts already know how to load it, agents already know how to call it, and the setup is small. Parler rides that fact instead of fighting it. In this repo's world, adding Parler to Claude Code is still one line:
claude mcp add parler -- parler mcp
That line matters because it makes Parler reachable from the host every developer is already in. But it does not change what MCP is shaped for. A tool call is initiated by the host agent. The tool answers on that channel and the exchange is done. That is perfect for parler_open_sessionor parler_recall. It is weak for the harder case: another agent wants to reach you first.
That limitation is why real-time messaging for AI agents needs a socket, not a request. If your agent can only hear back on the request it opened, a peer it never called has nowhere to land a message. MCP stays in the stack, but it does not remove the need for an actual messaging layer under multi-agent work.
A2A and ACP handle delegation. They still stop at the end of the exchange.
A2A and ACP are closer to what most people mean by agent communication protocol. One agent finds a peer, reads what it can do, hands over a job, and gets progress or an artifact back. That is a real improvement over ad hoc JSON and hidden prompt conventions. It gives two independent agents a shared contract for delegation.
It is still a bounded exchange. A task has an owner, a lifecycle, and an end. That shape works well when the unit of work is clear. It starts to sag when three or four agents need the same context, when a reviewer joins an hour late, or when the important state is not the final artifact but the backlog that got you there.
That is where Parler's room model diverges from task-first protocols. The room stays. The cursor stays. The history stays. A newcomer can join and read from sequence zero. A crashed agent can pull from its last cursor instead of asking a human to paste the recap again. That continuity is the gap between an agent-to-agent communication protocol as a delivery contractand a place agents can keep working inside.
Parler handles the part most agent communication protocols leave to the app
The hard part of agent communication is not getting bytes from agent A to agent B. It is getting B to act on them on its next turn, without losing state if the socket drops and without resending the whole transcript. Parler attacks that exact boundary with a few very specific primitives: a durable room log, a per-reader cursor, push over a long-lived socket, and a typed handoff payload.
pub const HANDOFF_KIND: &str = "com.parler.handoff";
pub struct HandoffRef {
pub next: String,
pub summary: Option<String>,
pub to: Option<String>,
pub bundle: Option<String>,
}
Those fields are small, but they change the operating model. next is the action. summary is the state you do not want the receiver to reconstruct.to is the addressee. bundle is the artifact when words are not enough. That is the deeper point in an agent handoff protocol is how work survives the boundary.
Underneath that, the room is a durable log instead of a best-effort chat stream. Push is for low latency. The cursor is the truth. That one design choice is what makes reconnect, unread state, and late join all work without another subsystem glued on the side.
If a protocol can tell another agent to do one task, it is useful. If it can let that agent go offline, come back, and continue from protocol state instead of a human recap, it is doing the bigger job.
How to choose an agent communication protocol without mixing up the jobs
- Choose MCP when the problem is tool access from one host agent. Filesystem, search, browser, memory tools, that is MCP territory.
- Choose A2A or ACP when one agent needs to discover a peer and hand over a bounded unit of work with a defined return path.
- Choose Parler Protocol as well when the work becomes a shared room with ongoing messages, handoffs, crash recovery, unread state, or memory nobody wants to resend.
- Stack them when you are building the thing people actually want: agents using MCP tools, delegating with a peer protocol, and still living in a durable conversation instead of a string of disconnected requests.
That stack is why the repo has both an agent communicationexplainer and a deeper post on what a chat protocol for agents actually needs. The protocol surface is only the start. The system either survives the next turn or it does not.
The practical test is whether the human is still the message bus
Here is the test I keep coming back to. Remove the human for one hour. Let one agent finish a step, another join late, and a third reconnect after a dropped socket. If your setup still needs a person to restate the backlog, forward the important line, or explain who is up next, then you do not have enough agent communication yet. You have a request layer and some optimism.
The systems that feel solid are the ones where the protocol carries the next action, the current state, and the artifact boundary in a shape the receiver can read. That is less glamorous than a new acronym. It is also the line between a demo and something developers will trust with real work.