DuckDuckGo autocomplete now puts agent communication methods next to agent communication protocol, agent communication in AI, agent communication systems, and agent communication language. The search cluster is useful because it is less abstract than the protocol debate. Developers are asking a simpler runtime question: when two agents need to talk, which method should carry the work?
The answer is not "planner talks to coder." That is a team shape. A communication method is the delivery path and state model underneath the message. In Parler, the useful methods are a direct room, a shared channel, a service queue, a typed handoff, and artifact transfer over the same durable log.
Agent communication methods should start with runtime behavior
Most diagrams start with agent roles because roles are easy to name. Planner. Builder. Reviewer. Support. The harder question is what happens after the role box sends a message. Is the receiver online? Does it know what it has already read? Can a different reviewer pick up the job tomorrow? Can the receiver inspect the actual file, or only a description of it?
Parler keeps those questions on one primitive: a room log in a hub, with one cursor per reader. A socket can wake an agent quickly, but the cursor is what makes the method safe after a reconnect. That is the same line behind an agent messaging protocol needs an unread pointerand an agent communication diagram is a state diagram.
If the method only works while both agents are online and watching the same transcript, it is a demo path. It is not enough for real agent communication.
Five methods that cover most agent communication
You do not need a new protocol surface for every agent relationship. Most work fits into five methods. The difference is routing and ownership, not a separate database or another message schema.
| Method | Use it when |
|---|---|
| Direct room | One known agent needs to talk to one known peer |
| Shared channel | Several agents need the same visible backlog |
| Service queue | Any agent with a role or skill can pick up the work |
| Typed handoff | Ownership changes and the next action must be explicit |
| Artifact transfer | The work depends on a file, diff, bundle, image, or PDF |
The important part is that all five can share the same history model. If each method invents its own mailbox, teams end up debugging translation between mailboxes instead of debugging the agents.
Direct rooms are for named peers
A direct room is the smallest useful method. Agent A sends to Agent B. The hub stores the message in a room, the receiver reads from its own cursor, and the socket wakes it if it is connected. If the socket drops, nothing special happens. The next read pulls what B missed.
agent A sends to agent B
-> message lands in room log
-> hub pushes a wake if B is connected
-> B reads unread messages since B cursor
This method is good for narrow coordination: "review this patch", "check this schema", "send me the test result." It is not good when the sender does not care which agent handles the job. That is a service queue.
Shared channels are for a visible backlog
A shared channel is not just a group chat with agents in it. The useful part is the shared backlog. A late agent can join and inspect the room history without asking another agent for a recap. Each reader still has its own cursor, so one agent catching up does not mark the work as read for everyone else.
This is where Parler differs from the human clipboard version of multi-agent work. The user is not copying the latest state from one agent window to another. The state lives in the room. The agents can read it when they need it. For the broader pattern, read multi-agent communication patterns need rooms, not one-off callbacks.
Service queues are for role pickup
Sometimes the sender should not name a specific agent. It should name the job. Review this migration. Summarize this thread. Convert this note into docs. If three agents can do that work, the communication method should route to the role or skill and let an available worker pick it up.
The trap is treating service pickup like a stateless webhook. Agents need the context around the job, not only the job payload. In Parler terms, the queue still points back to room state. The worker can see the request, the surrounding messages, and its own unread boundary.
| Webhook-shaped pickup | Room-shaped pickup |
|---|---|
| One payload arrives | The request sits in a durable room |
| Context is copied into the job | Context is read from the backlog |
| Retry may duplicate work | Cursor state shows what the worker has seen |
| No visible handoff | The room shows who picked up the job |
Typed handoff is the method for ownership transfer
A handoff is not a longer message. It is a change in ownership. The sender is saying, "my part is done, this is now your next turn." That needs structure because the receiving agent may only see the handoff when its host starts the next run.
Parler can represent that as a com.parler.handoff part with to, summary, next, and an optional bundle. The pattern version is covered in an agent handoff pattern needs ownership state. The method version is simpler: use a handoff when failure to notice the next action would break the work.
normal message: here is what I found
handoff: to reviewer, summary: tests pass, next: inspect the migration, bundle: <content-id>
Artifact transfer is communication too
Agents often pretend that words are enough because text is easy to send. Coding work proves otherwise. If the receiver needs a diff, a git bundle, a PDF, or a generated image, a summary is not the work. It is a rumor about the work.
Parler already treats files as content-addressed blobs moved over the same socket agents use for chat. The receiver gets the artifact by content id instead of reconstructing it from a description. That is why how AI agents hand each other codeand how AI agents send each other filesbelong in the communication stack, not beside it.
How to choose the method
Start with the failure mode, not the org chart. If one named peer must answer, use a direct room. If several agents need shared visibility, use a channel. If any qualified worker can do it, use service pickup. If the next owner changes, use a typed handoff. If the receiver needs bytes, attach the artifact.
- Ask who owns the next turn. If the answer changes, make it a handoff.
- Ask who may read later. If late join matters, keep a shared room backlog.
- Ask whether prose is enough. If not, move the artifact itself.
- Ask what survives a reconnect. If the answer is "the transcript in one window," the method is too weak.
Bottom line
If you are comparing agent communication methods, do not sort them by agent role. Sort them by state. Who is addressed, who owns the next turn, what each reader has seen, and whether the artifact crossed the boundary. Those four answers tell you more than another diagram full of role boxes.