Quick Answer: Agent-to-agent communication lets AI agents delegate work to other agents using structured protocols. The leading standard is Google's A2A protocol (April 2025), which uses Agent Cards for discovery and JSON-RPC over HTTPS for transport. Used alongside MCP for tool access, A2A is the foundation of modern multi-agent systems.
A single AI agent can reason, use tools, and complete tasks. But a single agent cannot be everywhere at once — and that is where agent-to-agent (A2A) communication changes everything.
By 2026, 40% of enterprise applications will embed AI agents, up from under 5% in 2024 (Gartner). The vast majority of those deployments involve multiple agents working together. They need a shared language — a way to discover each other's capabilities, hand off work, exchange data, and confirm completion without human intervention.
This guide covers everything: the protocols driving agent-to-agent communication, the patterns they enable, the security risks they introduce, and how to choose the right approach for your system. Whether you are building on cowork.ink or wiring up agents from scratch, this is your technical reference.
What Is Agent-to-Agent Communication?
Agent-to-agent communication is the ability for one AI agent to discover, invoke, and collaborate with another AI agent — without a human issuing every instruction.
This is distinct from an agent calling a tool (like a web search or database query). Tool calls are vertical: agent → tool → result. Agent-to-agent communication is horizontal: agent ↔ agent, with each side having its own reasoning, memory, and capabilities.
The key capabilities that A2A communication enables:
- Task delegation — a coordinator agent assigns a subtask to a specialist agent
- Capability discovery — agents advertise what they can do, so others can find them
- Context sharing — agents pass structured data across sessions and systems
- Result negotiation — agents agree on output formats before execution begins
Without this layer, multi-agent systems rely on shared databases, message queues, or brittle human-designed APIs. With it, agents can form dynamic networks that reconfigure themselves based on what is needed — a pattern that pairs naturally with event-driven AI agent architectures where incoming events trigger cross-agent workflows.
Before Google published the A2A protocol in April 2025, there was no open standard for agent-to-agent communication. Each platform (LangGraph, AutoGen, CrewAI) had its own internal wiring. A2A is the first widely adopted attempt at a universal lingua franca across agent systems — now backed by 50+ technology partners including Salesforce, SAP, and Workday.
A Brief History of Agent Communication Protocols
Understanding where we are requires knowing how we got here. Agent communication has been an open research problem for decades.
1993–2006: KQML and FIPA-ACL
The Knowledge Query and Manipulation Language (KQML) and the later FIPA Agent Communication Language (FIPA-ACL) were the first serious attempts at inter-agent messaging. They defined speech acts (inform, request, subscribe), ontologies, and structured message envelopes. Both were technically elegant — but they required agents to share a common ontology, which proved intractable at scale.
2020–2022: Function calling and the LLM era
When OpenAI introduced function calling, agents gained a practical way to invoke tools. This was a massive leap for agent-tool integration but said nothing about agent-agent interaction. Two GPT-4 agents could not natively "talk to each other" — you had to orchestrate them in code.
2023–2024: Framework-internal wiring
LangGraph introduced stateful agent graphs. CrewAI added role-based agent teams. AutoGen (later AG2) enabled conversational multi-agent loops. These were powerful but siloed — agents built in one framework could not communicate with agents in another. See our comparison of AG2, CrewAI, LangGraph, and the OpenAI Agents SDK for how these frameworks stack up.
2024: MCP standardizes tool access
Anthropic released the Model Context Protocol (MCP) in November 2024, providing a universal standard for connecting agents to tools and data sources. Within a year, MCP had 97 million downloads and over 1,000 servers in its ecosystem.
April 2025: A2A goes horizontal
Google published the A2A protocol — the first open standard specifically for agent-to-agent communication. Where MCP is vertical (agent → tools), A2A is horizontal (agent ↔ agent). The timing was precise: the industry had solved tool access with MCP, now it needed peer communication.
The Four Protocols Shaping Agent Communication
The protocol landscape has four major players. Most teams eventually need more than one.
MCP defines how an agent accesses tools, resources, and prompts from external servers. It is the "USB port" of the agent world — any MCP-compatible agent can use any MCP server. MCP is not designed for agent-to-agent delegation; it has no concept of a remote agent's identity or capability advertisement.
A2A introduces Agent Cards (JSON manifests), task lifecycle management, and streaming responses. A client agent discovers a remote agent's capabilities via its Agent Card, sends a task, and receives artifacts. A2A is built for enterprise-grade security (OAuth 2.0, HTTPS/TLS) and scales across organizational boundaries.
ACP focuses on asynchronous, REST-native message exchange. Where A2A is built on streaming JSON-RPC, ACP is a simpler HTTP-based protocol better suited to environments where long-lived streaming connections are impractical. It is gaining traction in IBM's agentic tooling and the BeeAI community.
ANP extends agent communication to a decentralized network layer. Agents publish their capabilities using Decentralized Identifiers (DIDs), and any agent on the internet can discover them without a central registry. ANP is early-stage but represents the most ambitious vision: an open internet of agents with no platform dependencies.
For a focused comparison of MCP and A2A, see our dedicated MCP vs A2A guide.
How A2A Works Technically
A2A is the most widely adopted agent-to-agent protocol today. Understanding its mechanics is essential for any engineer building multi-agent systems.
Agent Cards: Capability Discovery
Every A2A-compatible agent publishes an Agent Card — a JSON document served at a well-known endpoint (typically /.well-known/agent.json). The card declares:
- The agent's name, description, and version
- Supported capabilities (tasks it can handle)
- Input/output formats it accepts
- Authentication requirements (OAuth scopes, API keys)
- Endpoint URL for task submission
This is how a client agent knows what a remote agent can do before initiating a conversation. It is analogous to an OpenAPI spec, but for agent-to-agent interaction specifically.
Task Lifecycle
A2A interactions are organized around tasks — discrete units of work with a defined lifecycle:
- Submitted — client agent sends a task via
tasks/sendortasks/sendSubscribe - Working — remote agent processes the task (may stream intermediate updates)
- Input Required — remote agent needs clarification (handled via
tasks/sendagain) - Completed — task is done; artifacts are returned
- Failed / Cancelled — terminal error states
Tasks can produce artifacts — the output objects that contain the agent's result. Artifacts can be text, structured JSON, files, or any other declared MIME type.
Transport: JSON-RPC 2.0 over HTTPS
A2A uses JSON-RPC 2.0 as its messaging format, transported over HTTPS. This means:
- Every message has an explicit method name and typed parameters
- Authentication is handled at the HTTPS layer (OAuth 2.0 bearer tokens)
- Any HTTP client can interact with any A2A endpoint — no SDK required
Streaming with Server-Sent Events (SSE)
For long-running tasks, A2A uses Server-Sent Events to stream incremental updates back to the client agent. The client subscribes via tasks/sendSubscribe, and the remote agent sends a stream of TaskStatusUpdateEvent and TaskArtifactUpdateEvent objects as work progresses.
This enables real-time agentic workflows where a coordinator can watch a specialist agent's progress and react — much like how AI agent orchestration platforms manage parallel agent pipelines.
Communication Patterns in Multi-Agent Systems
Protocols define the wire format. Patterns define how agents use them architecturally. These are the four core patterns engineers reach for.
Request-Response (Synchronous Delegation)
The simplest pattern: one agent sends a task, waits for the result, continues. Suitable for fast, bounded tasks where the client agent's next step depends on the result.
Use it when: subtasks complete in under 30 seconds; the pipeline is strictly sequential. Avoid when: tasks can take minutes; failure blocks the entire pipeline.
Event-Driven (Async Delegation)
The client agent fires a task and moves on. The remote agent emits a completion event when done, which the client agent's event loop picks up. This is the A2A streaming model via SSE — and the dominant pattern for enterprise AI pipelines.
Use it when: subtasks are long-running; the client agent can make useful progress in the interim. Avoid when: task results must be processed in strict order.
Publish-Subscribe (Broadcast Coordination)
One agent publishes an event or artifact to a channel; multiple specialist agents subscribe and act on it independently. Common in agent swarm architectures where no single orchestrator should become a bottleneck.
Use it when: multiple agents need to react to the same event (e.g., a new document triggers summarization, classification, and indexing agents simultaneously).
Hierarchical Orchestration
A supervisor agent delegates to sub-agents, which may themselves delegate further. This is the pattern behind most enterprise multi-agent deployments. The supervisor maintains the task graph; sub-agents are specialists with narrow scopes.
For a deep dive into how this works in practice, see our multi-agent collaboration guide.
Protocol Comparison: Which One to Use When
| MCP | A2A | ACP | ANP | |
|---|---|---|---|---|
| Connection type | Vertical (agent → tool) | Horizontal (agent ↔ agent) | Horizontal (async) | Horizontal (P2P) |
| Discovery | Server manifest | Agent Card (JSON) | Service registry | Decentralized ID (DID) |
| Transport | JSON-RPC 2.0 | JSON-RPC + HTTPS + SSE | REST/HTTP | DID + JSON-LD |
| Auth | API keys / OAuth | OAuth 2.0 + HTTPS | OAuth / API keys | Cryptographic (DID) |
| Streaming | Partial | Full (SSE) | Limited | Not native |
| Trust model | Centralized | Centralized/federated | Centralized | Decentralized |
| Maturity | GA, 97M+ downloads | GA, 50+ partners | Growing (IBM/BeeAI) | Early stage |
| Best for | Tools, APIs, files | Cross-agent delegation | Async workflows | Open internet agents |
Most production multi-agent systems use MCP + A2A together. MCP handles each agent's tool access (web search, code execution, databases). A2A handles delegation between agents. You almost never have to choose between them — they solve different halves of the same problem.
Real-World Use Cases by Industry
The statistics are striking: early A2A adopters report 57% cost savings and 54% improved customer experience (OneReach.ai data). Here is where agent-to-agent communication is creating real leverage.
Enterprise Software (HR / ERP)
A hiring coordinator agent receives a job description and delegates to specialists: a resume-screening agent, a salary-benchmarking agent, and a scheduling agent. Each operates independently, returning structured artifacts. The coordinator synthesizes the results. Without A2A, this requires custom API wiring between every pair of agents.
Customer Support
Tier-1 support agents handle common queries autonomously. When they detect complexity (billing disputes, technical escalations), they delegate via A2A to specialist agents with deeper system access. The customer sees one continuous experience; the backend is a dynamic agent network.
Software Engineering
A code review orchestrator on cowork.ink delegates to specialist agents: a security scanner, a style checker, and a test-coverage analyzer. Each returns structured findings. The orchestrator aggregates them into a single review comment. This is a canonical use case for the AI agent architecture pattern where agents are scoped narrowly and composed freely.
Supply Chain and Finance
Financial reconciliation agents delegate currency conversion, regulatory compliance checks, and ledger updates to specialist agents across multiple systems. A2A enables this across organizational boundaries — a supply chain agent at Company A can delegate to a logistics agent at Company B, provided both implement the A2A protocol.
Security Risks in Agent-to-Agent Communication
Agent-to-agent communication significantly expands the attack surface compared to single-agent systems. Only 29% of organizations say they are prepared to secure agentic deployments (Help Net Security, 2026). These are the threats that matter most.
Agent Card Spoofing
A malicious endpoint serves a fraudulent Agent Card claiming capabilities and authorization scopes it does not have. A client agent trusts the card and delegates sensitive tasks. Mitigation: verify Agent Cards against a trusted registry; use signed cards with cryptographic provenance.
Task Injection
A crafted input payload contains instructions that hijack the remote agent's behavior — similar to prompt injection but at the agent protocol level. Multi-turn injection attacks achieve 92% success in testing (security research data). Mitigation: validate all input artifacts against declared schemas; treat remote agent responses as untrusted data.
Session Token Theft
OAuth bearer tokens used in A2A transport can be intercepted if TLS is not enforced end-to-end, or if tokens are logged in agent memory. Mitigation: short-lived tokens, token rotation, and audit logging for every agent-to-agent exchange.
Capability Drift
An agent gradually takes on tasks beyond its declared scope across a long session. No single step looks wrong; the cumulative drift exposes data or systems it should not touch. Mitigation: session-scoped capability declarations; periodic re-validation against the Agent Card.
For a comprehensive treatment of the full threat model, see our AI agent security guide.
In multi-agent systems, no agent should be implicitly trusted — not even one deployed by your own team. Every cross-agent call should be authenticated, authorized, and logged. The same Zero Trust principles that apply to microservices apply here.
When Agent Communication Fails
This is the section almost no one writes — but it is where production systems live or die. 35% of AI projects fail due to integration complexity (Gartner 2024), and coordination faults in multi-agent systems average 4–6 hours to detect in legacy setups.
Common Failure Modes
- Timeout during long-running tasks — the client agent loses its SSE connection mid-stream
- Capability mismatch — the client agent sends a task in a format the remote agent does not accept
- Authentication expiry — OAuth token expires mid-session, causing silent failures downstream
- Cascading delegation failures — a sub-agent in a deep hierarchy fails, and the error propagates upward unchecked
- Duplicate task execution — retries cause the same task to execute twice (idempotency violations)
Design Principles for Resilience
- Idempotency keys — include a stable task ID in every
tasks/sendcall; remote agents can deduplicate - Exponential backoff with jitter — for retries on transient failures, not on logic errors
- Dead-letter artifacts — tasks that fail after N retries should be preserved with full context for human review
- Partial result handling — design artifact schemas so partial results are valid; do not block on 100% completion
- Health checks via Agent Cards — poll the remote agent's card endpoint periodically; a 4xx response is an early signal of capability change
How to Get Started: A Phased Approach
The research literature (including the arXiv survey on MCP, ACP, A2A, and ANP) recommends a four-phase adoption path for teams building multi-agent systems. For a complete mapping of how these protocols layer together, see our AI agent protocol stack guide.
-
Phase 1 — MCP for tool access. Instrument your agents with MCP servers for every external resource they need (files, APIs, databases). This gives you a clean separation between agent reasoning and tool execution. See our guide on how to build an MCP server to get started.
-
Phase 2 — A2A for internal agent delegation. Once your agents are MCP-enabled, introduce A2A for cross-agent task delegation within your own system. Start with one coordinator → one specialist flow before expanding.
-
Phase 3 — ACP for async workflows. When your pipelines grow long-running and the synchronous model breaks down, layer in ACP-based async patterns for tasks that can tolerate queue-based delivery.
-
Phase 4 — ANP for external networks. When you need your agents to discover and interact with agents outside your organization (or in decentralized environments), explore ANP — but treat it as experimental infrastructure for now.
Most teams building in 2026 are operating at Phase 1–2. Phase 3–4 is the frontier.
Protocol Design Patterns for Engineering Teams
Whether you are building from scratch or orchestrating agents on a platform like cowork.ink, these patterns accelerate clean system design.
Pattern 1: Thin Coordinator, Fat Specialists
The coordinator agent holds the task graph and routes work. It has minimal business logic. Specialist agents are deep and narrow. This is easier to test, easier to swap, and easier to observe. It mirrors how AI agent orchestration frameworks like LangGraph think about agent topology.
Pattern 2: Schema-First Communication
Define the input and output schemas for every agent-to-agent exchange before writing any agent logic. Schemas are your contract. Publish them in Agent Cards. Test against them before deploying. This catches capability mismatches before production.
Pattern 3: Observability at Every Hop
Log every agent-to-agent call: who called whom, what task was submitted, what artifacts were returned, and how long it took. Without this, debugging multi-agent failures is nearly impossible. The average 4–6 hour coordination fault detection time in unobserved systems drops dramatically with structured per-hop logging.
Pattern 4: Graceful Degradation
Design every coordinator to have a fallback when a specialist agent is unavailable. Either a simpler in-process fallback, or a "pending human review" state. Never let a missing specialist silently block the entire pipeline.
Get Started with Multi-Agent Orchestration
Agent-to-agent communication is moving from research paper to production infrastructure faster than any prior wave in AI tooling. The protocols are live, the tooling is maturing, and the teams that learn to wire agents together cleanly now will compound that advantage for years.
cowork.ink gives engineering teams a shared workspace where AI agents collaborate on code review, planning, and documentation — built on the same multi-agent orchestration principles this article describes. Set up your team's first coordinated agent workflow in minutes, no prompt gymnastics required.
Frequently Asked Questions
What is agent-to-agent (A2A) communication?
Agent-to-agent communication is the ability for one AI agent to discover, invoke, and collaborate with another agent autonomously. The A2A protocol — published by Google in April 2025 — is the leading open standard, using Agent Cards for capability discovery and JSON-RPC over HTTPS for task exchange.
What is the difference between MCP and A2A?
MCP connects agents to tools and data (vertical). A2A connects agents to other agents (horizontal). They are complementary: MCP handles what an agent does, A2A handles who an agent delegates to. See our MCP vs A2A breakdown for a full comparison.
How do AI agents discover each other?
In A2A, agents publish an Agent Card at a well-known HTTPS endpoint (/.well-known/agent.json). The card declares capabilities, accepted input formats, and authentication requirements. A client agent reads this card before initiating any task — similar in concept to an OpenAPI spec.
Is A2A the same as multi-agent systems?
No. Multi-agent systems is the broader concept — multiple agents working together. A2A is one protocol for wiring them together. You can build multi-agent systems using LangGraph's internal graph, CrewAI's role system, or custom APIs without A2A. A2A becomes essential when you need agents from different platforms or organizations to communicate.
What companies support the A2A protocol?
Google leads the A2A specification, with 50+ initial technology partners including Salesforce, SAP, Workday, ServiceNow, Accenture, and Deloitte. The protocol is open-source (GitHub: a2aproject/A2A) and vendor-neutral.