infrastructureL5 AutonomousMCP & Tool Integration

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

·MCP operates as a bidirectional nervous system: production data flows to agents, agent actions flow to production
·Full production loop: Production -> MCP -> Agent -> Code -> Deploy -> Production
·Agent-to-Agent Protocol (A2A) and MCP are combined for multi-agent coordination

·MCP latency for context delivery is under 500ms P95
·A2A protocol enables agents to discover and delegate to other agents without human configuration

Evidence

·MCP configuration showing bidirectional data flow (production to agent, agent to production)
·End-to-end production loop traces (anomaly detected, agent invoked, fix deployed)
·A2A protocol configuration showing agent-to-agent communication channels

What It Is

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.

Why It Matters

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

Getting Started

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.
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.
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.
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.
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.
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.

Tip

Implement idempotency for all A2A task assignments. If the orchestrator retries a task assignment because it didn't receive an acknowledgment, the specialist should detect the duplicate and not execute the task twice. Task idempotency is a requirement for reliable multi-agent systems, not an optional optimization.

6 steps to get from here to the next level

Common Pitfalls

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.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's team is running complex agent workflows for feature implementation: a single agent that does research, planning, implementation, testing, and PR preparation. The workflows work but are fragile - if the agent gets confused at any step, the entire workflow fails. Bob wants to increase reliability and throughput.

What Bob should do: Bob should sponsor a multi-agent architecture pilot for the most common complex workflow: feature implementation from a ticket. The pilot decomposes the workflow into three specialist agents: a requirements interpreter (A2A + Jira MCP), a coding agent (A2A + filesystem/CI MCP), and a PR preparation agent (A2A + GitHub MCP). The orchestrator coordinates via A2A. The expected outcome: each specialist agent is simpler, more reliable, and easier to maintain than the monolithic single agent. Bob should measure: workflow completion rate before and after (specialist agents should fail at lower rates because each handles a narrower, better-defined task), and end-to-end workflow time. If the pilot shows 20%+ improvement in completion rate, it justifies expanding the multi-agent architecture to other workflow types.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah is trying to scale the organization's agent capacity to handle the full volume of development work without proportionally scaling human oversight. She needs an architecture where more complex work can be done autonomously without requiring more human review time.

What Sarah should do: Sarah should define the quality gates that determine when a multi-agent workflow requires human review versus when it can complete autonomously. The A2A architecture enables this: the orchestrator can be configured with quality thresholds for each specialist's output - if the coding agent's tests pass at 100% and the review agent finds no architectural violations, the workflow completes autonomously; if either threshold fails, the workflow escalates with the specialist's structured output as context. Sarah should define these thresholds, implement them in the orchestrator, and measure the escalation rate over time. As the specialist agents improve, the escalation rate should decrease - meaning more work completes autonomously with the same quality. This is the metric that demonstrates AI maturity is improving: same quality bar, decreasing human intervention rate.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has been building increasingly complex agent workflows and hitting the limits of single-agent architecture. He wants to build a multi-agent system where a planner agent coordinates specialist agents for different parts of the development pipeline, but he's not sure how to implement the inter-agent communication layer reliably.

What Victor should do: Victor should implement A2A starting with the simplest possible multi-agent case: one orchestrator, one specialist. Pick his most common single-agent workflow (probably: read a ticket and implement the code). Split it into two agents: a planning agent that reads the ticket and produces a structured implementation spec, and a coding agent that takes the spec and produces code. Connect them with A2A. This simplest case teaches the A2A coordination mechanics (task assignment, progress updates, result delivery) without the complexity of managing multiple specialists. Once this two-agent workflow is reliable, Victor can add a third specialist (testing agent), then a fourth (PR preparation agent), building the multi-agent architecture incrementally. Each addition is a small, testable step rather than a large architectural leap.

What Victor should do - role-specific action plan