Agent-to-Agent Communication: Protocols and Patterns

Two agents working on the same task without communication is worse than one agent working alone. They duplicate effort. They make conflicting decisions. They overwrite each other's work.

Communication is the difference between a team and a collection of individuals. And the communication protocol you choose determines the ceiling of what your multi-agent system can accomplish.

I've built systems with every communication pattern in the book. Message queues. Shared databases. Event buses. Blackboard systems. Each has a sweet spot, and each has failure modes that will surprise you if you're not prepared.

Message Passing: The Simple Foundation

The simplest communication pattern is direct message passing. Agent A sends a structured message to Agent B. Agent B processes the message and sends a response.

The message format matters more than you'd think. Unstructured text messages create ambiguity. "The code looks good but needs some changes" is useless as a message between agents. Which code? Good compared to what? What changes?

Structured messages with defined schemas eliminate this ambiguity. A review message includes the file path, the line range, the issue category (bug, style, performance, security), the severity, and a specific suggested fix. The receiving agent can parse this deterministically and act on it without interpretation.

Define your message schemas upfront. Use TypeScript interfaces or JSON Schema. Validate every message against the schema before sending it. Reject malformed messages loudly rather than trying to interpret them.

Message routing determines which agent receives which message. In a simple pipeline, messages flow linearly: Agent A to Agent B to Agent C. In a complex system, messages route based on content: security issues go to the security agent, performance issues go to the performance agent, style issues go to the style agent.

A central message bus decouples senders from receivers. Agents publish messages to topics. Other agents subscribe to topics they care about. Adding a new agent is as simple as subscribing to the relevant topics. Removing an agent doesn't break the system because publishers don't know or care about subscribers.

Shared Memory: Building on Each Other's Work

Message passing works well for sequential workflows. But collaborative work, where multiple agents contribute to a shared artifact, needs something richer.

Shared memory gives agents a common workspace. A shared document, a shared codebase, a shared knowledge base. Agents read the current state, make their contribution, and write the updated state back.

The obvious challenge is concurrency. Two agents read the same file, both make changes, both write back. One agent's changes are lost. This is the classic concurrent write problem, and it's solved the same way it's solved everywhere else: with locks, versioning, or conflict-free data structures.

Optimistic concurrency with version checking works well for most agent scenarios. Each agent reads the current version of the shared resource. Makes its changes. Attempts to write with a version check. If the version has changed since the read, the write fails and the agent retries with the updated state.

This pattern requires that agent changes are idempotent, or at least re-computable from the updated state. Which is a good design practice regardless.

The shared memory pattern excels in document creation workflows. An outline agent creates the structure. A research agent fills in facts and citations. A writing agent transforms the outline into prose. An editing agent refines the prose. Each agent builds on the previous agent's work through the shared document.

Event-Driven Communication

Sometimes agents don't need to talk to each other directly. They need to react to things that happen.

Event-driven communication inverts the control flow. Instead of Agent A telling Agent B to do something, Agent A publishes an event ("code committed to repository"), and Agent B reacts to that event by running tests. Agent C reacts to the same event by updating documentation. Agent D reacts by triggering a deployment.

The power of events is decoupling. Agent A doesn't know that Agents B, C, and D exist. It just publishes events about its own activity. New agents can subscribe to existing events without modifying any existing code.

Events also create a natural audit trail. The sequence of events tells the story of what happened, when, and why. This is invaluable for debugging and for understanding the system's behavior over time.

The downside of events is the loss of explicit control flow. In a message-passing system, you can trace the exact path of communication. In an event-driven system, the execution path emerges from the subscriptions, which can be harder to reason about.

Negotiation Protocols

The hardest communication pattern is negotiation. Two agents disagree, and the system needs to resolve the disagreement.

A code agent adds a dependency. A security agent flags that dependency as having known vulnerabilities. A performance agent notes that the dependency adds 200KB to the bundle size. What happens?

Without a negotiation protocol, you get deadlock. The code agent insists the dependency is needed. The security agent insists it's dangerous. Nobody wins, nothing ships.

A good negotiation protocol defines priority hierarchies, escalation paths, and compromise strategies.

Priority hierarchy: Security concerns outrank performance concerns, which outrank convenience concerns. If the security agent says no, the answer is no unless there's no alternative.

Escalation path: If agents can't resolve a conflict within two rounds of negotiation, escalate to a supervisor agent (or a human) with a summary of each agent's position.

Compromise strategies: Can the dependency be pinned to a version without the known vulnerability? Can the performance impact be mitigated by tree-shaking or lazy loading? Can the functionality be achieved with a different, safer dependency?

Negotiation is the most complex communication pattern, and it's the one that separates demo multi-agent systems from production ones. Real work involves trade-offs. Agents that can negotiate trade-offs produce better outcomes than agents that can only accept or reject.

Choosing the Right Pattern

Use message passing for sequential workflows where one agent's output becomes another's input. Simple, predictable, easy to debug.

Use shared memory for collaborative work where multiple agents contribute to the same artifact. More complex but enables richer collaboration.

Use events for reactive systems where agents should respond to changes without explicit coordination. Highly decoupled but harder to trace.

Use negotiation when agents have competing objectives and the system needs to find optimal trade-offs. Most complex but most capable.

Most production systems use a combination. Message passing for the main workflow, shared memory for collaborative subtasks, events for monitoring and side effects, negotiation for conflict resolution. The art is knowing which pattern to apply where.