Agent-to-Agent Protocol (A2A) + MCP combined

The Agent-to-Agent Protocol (A2A), developed by Google and adopted as an open standard, defines how autonomous agents communicate with each other: how one agent delegates a task to another, how the receiving agent reports progress and results, and how agents negotiate capabilities. Where MCP defines how agents connect to tools and data sources, A2A defines how agents connect to each other. Together, MCP and A2A provide the full infrastructure layer for multi-agent systems: MCP is the tool access protocol; A2A is the inter-agent coordination protocol.

In a combined A2A + MCP architecture, a planner agent receives a high-level task (say, "implement the authentication feature from ticket PROJ-567 and prepare it for review"). The planner uses A2A to delegate subtasks to specialist agents: a requirements agent (reads the ticket via Jira MCP, interprets acceptance criteria), a coding agent (writes the implementation using filesystem MCP tools, runs tests via CI MCP tools), and a review preparation agent (generates a PR summary, checks against architecture ADRs via Architecture MCP). Each specialist agent uses MCP for tool access and A2A for communication back to the planner. The planner synthesizes the results and produces the final output.

A2A handles the operational mechanics of inter-agent coordination that are distinct from tool access. A2A defines: how an agent publishes its capabilities (what tasks it can handle), how it accepts and acknowledges task assignments, how it streams progress updates back to the orchestrator, how it handles task cancellation, and how it reports errors that require the orchestrator to retry or reroute. These coordination primitives are not part of the MCP protocol, which focuses on the tool/resource access layer. Together, the two protocols cover the full surface area of multi-agent infrastructure.

The complementary nature of the two protocols is by design. Anthropic's MCP and Google's A2A are both open standards with overlapping communities of adopters, and they are deliberately non-overlapping in scope. An agent that supports both protocols can participate in a multi-agent network (A2A) while simultaneously accessing any tool in the organization's Toolshed (MCP). This combination is what enables L5 agent architectures to operate at scale.

• Enables genuine specialization at scale - MCP-only architectures run one agent with access to many tools; A2A + MCP architectures run many specialized agents, each optimized for their domain, coordinating via A2A and accessing their domain-specific tools via MCP
• Removes the context window bottleneck - a single agent trying to do everything hits context window limits on complex, long-running tasks; A2A allows tasks to be distributed across multiple agents, each maintaining context for their specific subtask
• Supports heterogeneous agent ecosystems - A2A is model-agnostic; a Claude-based planning agent can delegate via A2A to a specialized agent built on a different model, each using its strengths for the task type it handles best
• Creates composable organizational capabilities - agents built as A2A services can be combined in different ways for different workflows; the same code review agent can participate in a development pipeline, an automated security audit, and a documentation verification workflow
• Aligns with emerging industry standards - both MCP and A2A are being adopted broadly; organizations that implement both are building on interoperable standards rather than proprietary agent communication mechanisms

1. Understand the A2A protocol structure - A2A agents publish an "Agent Card" - a JSON document describing their capabilities, supported input types, and connection endpoint. An orchestrator discovers available agents by fetching their Agent Cards. This discovery mechanism is analogous to MCP's tools/list but at the agent level.
2. Identify the natural decomposition points in your agent workflows - look at your current agent workflows and find where task handoffs naturally occur. A workflow that currently runs sequentially in one agent (research, then plan, then implement, then test) is a candidate for decomposition into specialist agents connected via A2A.
3. Build one specialist agent as an A2A service - pick the subtask that would benefit most from specialization (typically: the subtask that takes the most time, or the one that benefits most from a highly tuned system prompt). Build it as an A2A-compliant service with a published Agent Card and implement the A2A task acceptance and reporting protocol.
4. Build the orchestrator that delegates via A2A - the orchestrator agent receives high-level tasks, discovers available specialist agents via their Agent Cards, and delegates subtasks using the A2A task assignment protocol. The orchestrator tracks subtask status via A2A progress updates and synthesizes results when subtasks complete.
5. Connect each specialist to its MCP tools - each specialist agent connects to the MCP tools relevant to its domain. The coding specialist connects to filesystem and CI MCP tools; the research specialist connects to docs and web search MCP tools; the deployment specialist connects to CD MCP tools. Tool access is per-specialist, not shared via the orchestrator.
6. Design for fault tolerance across the protocol boundaries - in a multi-protocol system, failures can occur at the MCP layer (tool unavailable), the A2A layer (specialist agent unreachable), or within an agent (reasoning failure). Design the orchestrator to handle each failure type: retry transient MCP failures, reroute to backup specialist agents via A2A, and escalate reasoning failures to humans.

Over-decomposing into too many specialist agents. It's tempting to create a specialist agent for every subtask, but coordination overhead grows with the number of agents. A task that requires 10 A2A round-trips to complete will often be slower than a single agent doing all 10 steps sequentially. Decompose where there is genuine specialization benefit or where context windows are a constraint; don't decompose for its own sake.

Not defining agent capability boundaries clearly. When two specialist agents have overlapping capabilities (both can write code; one specializes in Python, one in TypeScript), the orchestrator needs clear rules for which to use when. Vague capability descriptions produce inconsistent routing. Write Agent Cards with explicit capability boundaries and unambiguous task type descriptions.

Building A2A communication without persistence. A2A task state is ephemeral by default. If the orchestrator or specialist agent crashes mid-task, the task state is lost. For long-running multi-agent workflows, implement task state persistence: store the current state of each active task so the workflow can resume after a failure rather than starting over.

Ignoring the security implications of inter-agent communication. In a multi-agent system, a compromised or confused agent can send malicious task assignments to other agents via A2A. Each agent should validate that incoming A2A task assignments are within its expected task scope and from an authorized orchestrator. A2A communication requires the same authorization thinking as MCP tool access.