How Agents Actually
Talk to Each Other
"Agents talking to each other" is not one architecture. It is a family of designs that behave very differently. This interactive guide maps all five patterns — from paired review to cross-org protocols.
Five Communication Patterns
Each pattern solves a different coordination problem. Click any card to explore its architecture, real-world implementations, and practical guidance.
Pattern Explorer
Select a pattern to see its architecture, data flow, real implementations, and when to use it.
Worker
Reviewer
Paired Peers & Review Bridges
Two agents run in persistent sessions (e.g. tmux), bridging messages between them. One agent builds while the other critiques. When both reviewers agree on a problem, it is a strong signal the issue is real.
Key Implementation
Meta agent loop running codex and claude side by side in tmux. Bridges messages between persistent sessions. Iterates against a shared PLAN.md.
Claude Code's experimental Agent Teams feature. Team Lead + shared task list + peer-to-peer messaging. Teammates self-claim tasks and message each other directly.
Shared Artefacts
When to Use
- You want friction inside the loop — disagreement as quality signal
- Each agent specialises: one pushes forward, the other challenges
- Cross-harness collaboration (Codex + Claude + Gemini CLI)
- Tasks benefit from pair programming dynamics
Watch Out
- If both agents can say anything about everything, the loop becomes noise
- Require explicit proof, not vague "looks good"
- Treat agreement as signal, not truth
Agent
Specialist
{ reason, context, customer_id }
Typed Handoffs
The cleanest way to make agents "talk" is often to avoid conversation entirely. An agent delegates part of a task to a specialist via a structured handoff tool. The receiving agent gets only the context it needs.
Key Implementations
Dedicated handoff tools like transfer_to_refund_agent. Supports structured payloads, filtered history, explicit routing metadata.
State-driven behaviour: tools update variables like current_step or active_agent. The system changes prompts, tools, or routing accordingly.
What Gets Transferred
When to Use
- One specialist should take full control for a while
- Customer service routing — triage to specialist
- When passing too much context causes confusion
Watch Out
- Most failures come from passing too much context, not too little
- Never dump raw scratchpad into the next agent
- Keep the payload short and typed
Agent
Analyst
Shared-Thread Group Chat
Several agents in one shared conversational space, building on the same visible history. A selector model picks the next speaker based on shared context. The thread itself is working memory.
Key Implementation
Participants take turns broadcasting messages to all members. A planning agent breaks tasks, a web search agent retrieves data, a data analyst performs calculations. Stops at termination condition.
When to Use
- Agents genuinely need common public context
- Task is naturally collaborative, context fits budget
- One agent needs planning authority over the rest
Watch Out
- Broadcast history grows quickly — cap the number of turns
- Roles blur when descriptions are too loose
- If it starts resembling a meeting, structure is too loose
- Selector model may choose the wrong next speaker
Agent
Refunder
Proxy
Swarm-Style Routing
Between handoffs and group chat. Agents hand off to each other based on capabilities, sharing the same message context. Each agent decides locally who should take over — no central orchestrator.
Key Implementations
Agents make local decisions about task planning. Each speaker can decide who takes over after them. Routing is distributed, not centralized.
The original pattern. Lightweight agents with handoff functions. Shared context with local routing decisions.
When to Use
- Task path is not fully predictable up front
- Want local autonomy over sequencing, not just execution
- Ownership needs to move fluidly between specialists
Watch Out
- Keep the handoff graph small and explicit
- Every weak handoff decision pollutes the next turn
- Add strong termination conditions — swarms can keep moving without closing
A2A Protocol (v1.0)
The closest thing to genuine agent-to-agent communication. An open protocol for discovery, capability description, task lifecycle, and structured artefact exchange across trust boundaries. Released March 2026 with production-ready features.
v1.0 Features (March 2026)
Agent Card (Discovery)
{
"name": "Research Agent",
"description": "Searches and summarises sources",
"endpoint": "https://research.example.com/a2a",
"protocol_version": "1.0",
"skills": ["web_search", "summarisation"],
"auth": { "type": "oauth2", ... },
"signed": true
}Key Resources
Open standard for opaque agent interoperability. 100+ enterprise adopters.
Production-ready release with multi-protocol bindings, signed cards, and multi-tenancy.
When to Use
- Agents are genuinely independent (different stacks, orgs, or teams)
- Need capability discovery across trust boundaries
- Async execution with task lifecycle tracking
- Multi-vendor agent marketplace scenarios
MCP vs A2A — The Two Protocol Layers
MCP handles vertical integration (agent to tools). A2A handles horizontal collaboration (agent to agent). They are complementary, not competing. Most production systems in 2026 use both.
| Dimension | MCPModel Context Protocol | A2AAgent-to-Agent Protocol |
|---|---|---|
| Created by | Anthropic (March 2024) | Google (April 2025) |
| Primary function | Connect agents to tools, APIs, data | Connect agents to other agents |
| Direction | Vertical (agent ↓ tools) | Horizontal (agent ↔ agent) |
| Discovery | Tool manifests via MCP server | Agent Cards at well-known URLs |
| Communication | JSON-RPC over stdio/SSE/HTTP | HTTP + JSON, SSE, webhooks |
| Auth model | Server-level (varies) | OAuth 2.0 built into spec |
| State | Stateless tool calls | Stateful task lifecycle |
| Maturity (2026) | 5,800+ public servers | 100+ enterprise adopters |
| Best for | "Give agent access to X tool" | "Have agent A delegate to agent B" |
The Coordination Spectrum
These patterns form a spectrum from tightly coupled internal delegation to fully independent cross-org collaboration. Drag the slider to explore.
Subagents (Internal Delegation)
One runtime owns the work. The outer system decides what to call, what state to pass, and what comes back. This is structured delegation, not peer communication. Useful, but not agents talking to each other as agents.
What Actually Works
Across all these systems, the reliable ones reduce agent communication to a few well-behaved forms — not open-ended dialogue.
Shared Artefact
PLAN.md, checklist, PR diff. A small, legible object both agents can reference and modify.
Typed Transfer
Changes who owns the task. Short payload, routing reason, filtered history.
Public Thread
Clear roles, narrow tasks, explicit termination conditions. The thread is shared working memory.
Capability Card
Agent Card JSON — identity, endpoint, skills, auth. Digital business card for discovery.
Proof Step
Evaluation that decides whether the exchange actually helped. Tests pass. PR approved. Task verified.
"If the answer is 'let them chat more', the system usually gets worse. If the answer is 'give them a small, legible contract for review, transfer, or capability discovery', the system gets much more usable."— Bob Zhu
Decision Guide
Answer a few questions to find the right pattern for your use case.
The Multi-Agent Coding Stack (March 2026)
The shift from conductor (one agent, real-time) to orchestrator (multiple agents, async). Most developers in 2026 use all three tiers.
Interactive Pair
Single agent, real-time guidance. Your terminal or editor. Synchronous, sequential.
Local Orchestrator
Multiple agents in isolated worktrees. Dashboards, diff review, merge control. 3-10 agents on known codebases.
Cloud Async
Assign a task, close your laptop, return to a pull request. Agents run in cloud VMs.