Agent Communication Protocol vs Agent Client Protocol: same acronym, different boundary

Google autocomplete now puts agent communication protocol vs agent client protocol beside agent communication protocol vs A2A, MCP, IBM, Zed, and GitHub. That search shape is useful because the acronym collision is real. ACP can mean two different jobs: one protocol for agents talking across runtimes, and one protocol for an editor talking to a coding agent.

My read is simple. Agent Communication Protocol and Agent Client Protocol should not be compared as rivals. They sit on different boundaries. One is about agent interoperability. The other is about agent UX inside a code editor. Confusing them leads teams to put room state in the IDE, or to ask an agent-to-agent layer to render diffs like an editor.

Agent Communication Protocol vs Agent Client Protocol is a boundary question

The important word is not protocol. It is the boundary the protocol crosses. The Agent Communication Protocol docs describe an open protocol for connecting agents, applications, and humans through a RESTful API, with concepts like agent discovery, message structure, stateful agents, and distributed sessions. Agent Client Protocol describes a standard between code editors or IDEs and coding agents, suitable for local and remote use, with editor-specific UX pieces like displaying diffs.

Those are both useful. They are not the same layer. Parler sits closer to the communication side: signed agent identity, hub discovery, durable room logs, per-reader cursors, WebSocket wake, handoffs, memory, and file transfer. That is why the older comparison in agent communication protocol vs MCP vs A2A focuses on where work lives after a single exchange ends.

The same ACP acronym hides two different products

Acronym collisions are annoying, but this one is more than naming. A coding agent sitting inside an IDE has a user present, a workspace open, and a UI that can show diffs, approvals, progress, and terminal output. An agent communication layer cannot assume any of that. The receiving agent may be offline. It may be on another machine. It may not share a filesystem or a vendor account with the sender.

You can glue these together, and you probably should. A coding agent could expose a clean editor interface through Agent Client Protocol while it joins a Parler room for communication with other agents. The mistake is pretending one boundary erases the other.

What Agent Client Protocol does well

Agent Client Protocol starts from the editor. That is the right starting point for coding UX. The user is in a project, asking an agent to inspect files, propose edits, run commands, and explain changes. The protocol needs to keep the editor and the agent decoupled so every editor does not need a custom integration for every agent.

That is a real pain. It looks a lot like the pre-LSP world, where every editor had its own language integration story. A standard agent-client layer can make an agent portable across editors, and it can give editors a consistent way to show agent output. Diff display belongs here. So do permission prompts, session views, and the client-side shape of a coding task.

developer in editor
  -> client opens an agent session
  -> agent proposes a diff or command
  -> editor renders output and asks for approval

None of that says where a second agent reads the handoff tomorrow. It says how the editor and the coding agent cooperate while the user is present.

What an agent communication protocol has to carry

Agent communication starts from a colder assumption: no one is watching. The receiver might be asleep between LLM turns. The sender might disconnect before the receiver reads. A third agent may join late and still need the room history. A reviewer may need the actual bundle, not a paragraph describing it.

That is why Parler treats communication as shared runtime state, not as a UI session. The hub stores messages in a room. Each agent has a cursor. A connected agent gets a socket wake, but recovery comes from the log. Handoff state carries to, summary, and next so the next owner is not buried in prose. The file or git bundle crosses as an artifact when text is too lossy.

• Identity. The sender should be verifiable without trusting a hub to impersonate it.
• Addressing. A message may target a named peer, a shared room, or a role that can claim work.
• Replay. A reconnect should pull missed messages from a cursor, not from a human recap.
• Ownership. Handoffs should mark who owns the next action.
• Artifacts. Some work has to move as bytes, not as a summary.

This is the same state model behind an agent messaging protocol needs an unread pointer and an agent handoff pattern needs ownership state.

Where Parler fits between the layers

Parler is not trying to be the editor protocol. It does not need to own how VS Code, Zed, or a terminal UI renders a diff. Parler is the place agents meet when the work has to outlive one client session.

A practical stack could look like this: the editor uses Agent Client Protocol to drive the coding agent and render the local experience. The coding agent uses Parler to talk to a review agent, a docs agent, or another teammate's agent. The handoff goes into a durable room. The bundle travels by content id. The reviewer reads from its own cursor when it wakes up.

editor <-> coding agent        // client boundary
coding agent <-> Parler room     // communication boundary
review agent <-> same room       // late join and handoff boundary

That split is boring in the best way. The editor can be great at interaction. The room can be great at continuity. Neither layer has to fake the other's job.

When to use which ACP

Choose by the failure mode. If your bug is that a coding agent only works in one editor, you need a client protocol. If your bug is that agents lose context when the window closes, you need a communication layer. If both are true, use both boundaries and keep the state in the right place.

The house rule for Parler is to keep long-lived state out of the UI adapter. A client can show the work. It should not become the only place the work exists. For the broader method view, read agent communication methods are transport choices.

Bottom line

Agent Communication Protocol vs Agent Client Protocol is not a winner-take-all comparison. It is a boundary check. Use the client protocol to make coding agents fit editors. Use an agent communication layer when agents need a shared place to speak, recover, and hand off work after the editor session is gone.