Google announced the Agent-to-Agent protocol, A2A, as a standard for how AI agents communicate with each other. This sits alongside the Model Context Protocol, MCP, which standardizes how agents access tools. The two protocols address different parts of the agent interaction model: MCP handles agent-to-tool communication, and A2A handles agent-to-agent communication. Understanding where each protocol fits and where they overlap is important for teams building multi-agent systems.

The instinct is to treat A2A as a competitor to MCP. They are not competitors. They are complementary layers in the agent stack. An agent uses MCP to call a database tool. It uses A2A to delegate a subtask to another agent. Both are needed in a system where agents both use tools and collaborate with other agents.

But the relationship between the two is not cleanly separated. There are gray areas — interactions that could use either protocol, agents that are somewhere between tools and autonomous entities, and control layer implications that compound when both protocols are in use. This post works through each of these, with concrete scenarios and decision rules for your architecture.

The Scenario That Forces the Distinction

A company builds an AI-powered procurement system. The system has three agents: a sourcing agent that finds suppliers, a negotiation agent that handles pricing discussions, and a compliance agent that checks regulatory requirements. The sourcing agent needs to search a supplier database (a tool). It also needs to ask the compliance agent whether a specific supplier meets regulatory requirements (another agent).

The database search is clearly a tool interaction. The sourcing agent sends a query, the database returns results. There is no autonomy on the database side. The database does not decide whether to answer. It does not negotiate the query scope. It executes the query and returns results. This is an MCP interaction.

The compliance check is different. The compliance agent has its own context about regulatory requirements, its own logic for evaluating suppliers, and its own judgment about edge cases. It may respond with “this supplier is compliant,” “this supplier is not compliant,” or “this supplier is conditionally compliant pending verification of their ISO certification.” The response requires judgment, not just data retrieval. This is an A2A interaction.

The distinction matters because the controls are different. The database tool has a defined set of queries it supports. The compliance agent can be asked anything, and its response depends on its reasoning. The risk surface is different, and the control mechanisms must be different.

What A2A Solves

MCP standardizes how an agent discovers and invokes tools. The tool is a passive endpoint that receives requests and returns responses. The tool does not have its own goals, its own context, or its own decision-making capability. It executes a function and returns a result.

Agent-to-agent communication is different. When agent A sends a task to agent B, agent B has its own context, its own goals, and its own decision-making process. Agent B may accept the task, reject it, negotiate the scope, or delegate part of it to agent C. The communication is between two autonomous entities, not between an autonomous entity and a passive tool.

A2A standardizes this communication. It defines how agents discover each other, how they negotiate tasks, how they exchange context, and how they report results. Without a standard, each multi-agent system implements its own ad-hoc communication protocol, which limits interoperability.

The Specific Problems

Agent discovery. How does agent A find agent B? In a two-agent system, this is trivial: agent A has agent B’s endpoint hardcoded. In a system with dozens of agents, discovery needs a registry. A2A defines a discovery mechanism where agents publish their capabilities and other agents can find them based on the capabilities they need.

Task delegation. How does agent A describe a task for agent B? The task description needs to include the objective, any constraints, relevant context, and the expected output format. A2A standardizes this description format so that agents from different teams or systems can understand each other’s task requests.

Context sharing. How does agent A pass relevant context to agent B? The context might include conversation history, retrieved documents, previous decisions, or user preferences. A2A defines a context exchange format that allows agents to share structured context without exposing their internal state.

Result reporting. How does agent B return results to agent A? The result might be a simple answer, a structured output, a request for clarification, or a delegation to agent C. A2A standardizes the result format so that agent A can process responses from any agent, not just agents it was specifically designed to work with.

Status tracking. How does agent A check whether agent B has completed the task? For synchronous interactions, this is simple: agent A waits for the response. For asynchronous interactions (long-running tasks), A2A defines a status polling or notification mechanism.

Where MCP and A2A Overlap

Both protocols involve one entity making a request to another entity and receiving a response. The request-response pattern is the same. The difference is in what happens on the receiving end. MCP tools execute a function. A2A agents exercise judgment.

The overlap creates a design decision: should a given interaction use MCP or A2A? The answer depends on the autonomy of the receiving entity. If the receiving entity is a tool that executes a defined function, use MCP. If the receiving entity is an agent that makes decisions, use A2A.

The Gray Area

The boundary is not always clear. Consider three examples:

A “research agent” that retrieves documents and summarizes them. It has some decision-making capability — it decides which documents are relevant — but it does not have independent goals. It is essentially a retrieval tool with a built-in summarizer. This could be MCP: the calling agent sends a query, the “research agent” returns a summary. The autonomy is limited enough that the interaction pattern is tool-like.

A “code review agent” that analyzes a pull request and returns findings. It makes judgment calls about code quality, but its output is structured and predictable. The calling agent does not need to negotiate with it. It sends the PR diff, it gets back findings. This is MCP territory.

A “planning agent” that takes a high-level objective and creates a multi-step execution plan. It decides what steps are needed, what resources each step requires, and in what order they should be executed. The calling agent may need to negotiate scope (“can you do this in under 5 steps?”) or constraints (“only use tools from this list”). This is A2A territory.

The Practical Test

Use this test: can the receiving entity’s behavior be fully described by a function signature (inputs → outputs)? If yes, use MCP. If the receiving entity’s behavior requires negotiation, context exchange, or judgment that cannot be captured in a function signature, use A2A.

Another test: does the calling agent need to know the receiving entity’s internal state? MCP tools are stateless from the caller’s perspective. A2A agents may maintain state that affects their responses. If the interaction requires state awareness, use A2A.

Control Layer Implications

The Seven Control Layers framework applies to both MCP and A2A interactions, but the controls are different for each. This is where the distinction matters most: the wrong control model for the wrong protocol creates either security gaps or unnecessary friction.

Layer 1: Model Control

Applies to both. The agent doing the delegating runs on a model. The agent receiving the delegation runs on a model. Both need model routing, cost tracking, and failover. The difference is that A2A interactions involve multiple model inferences (one per agent in the delegation chain), so cost tracking compounds.

Layer 2: Prompt Operations

Applies to both. Each agent has prompts that define its behavior. These prompts need versioning, testing, and deployment controls just like application prompts. With A2A, the prompt surface area is larger: each agent in the delegation chain has its own prompts, and a prompt change in any agent can affect the overall system behavior.

Layer 3: Guardrails

More complex for A2A than MCP. MCP guardrails check whether a tool call is safe: is the tool allowed, are the parameters valid, is the call within rate limits? A2A guardrails must check whether the delegated task is appropriate, whether the receiving agent is authorized to perform it, and whether the result is trustworthy.

Consider the procurement example. The sourcing agent asks the compliance agent to check a supplier. The A2A guardrail must verify that the sourcing agent is allowed to ask the compliance agent (authorization), that the supplier data being shared is appropriate (data classification), and that the compliance agent’s response is trustworthy (response validation). This is a three-dimensional check versus the one-dimensional check for MCP tool calls.

Layer 4: Budget Governance

Applies to both but compounds with A2A. Each agent in a delegation chain consumes tokens. Agent A delegates to agent B, which delegates to agent C. The total cost is the sum of all three agents’ token consumption plus the inter-agent communication overhead. Budget governance must track and limit the cumulative cost across the delegation chain, not just individual agent costs.

The budget enforcement point is the entry of the delegation chain. Agent A initiates the delegation. The budget system charges Agent A’s tenant for the full cost of the chain. This prevents cost attribution gaps where Agent B’s costs are not attributed to any tenant.

Layer 5: Tool Governance

Applies primarily to MCP. A2A agents may themselves use tools through MCP, so tool governance is inherited by the delegation chain. If agent B has access to a database tool through MCP, agent A’s delegation to agent B implicitly grants indirect access to that database.

This transitive access is a security concern. The tool governance system must account for it. When evaluating whether agent A can access a resource through agent B, the system should check agent A’s permissions, not just agent B’s. If agent A does not have database access, agent A should not be able to get database access by delegating to agent B who does.

The implementation: each A2A delegation request includes the delegating agent’s permission context. The receiving agent’s tool calls are evaluated against the delegating agent’s permissions, not its own. This prevents privilege escalation through delegation.

Layer 6: Observability

Must span both protocols. A trace that shows agent A calling agent B through A2A, which then calls a tool through MCP, must capture the full chain. The observability system needs to correlate A2A task delegations with MCP tool calls to provide end-to-end visibility.

The trace structure for a multi-agent interaction:

[Trace: procurement-check-abc123]
├── [Span] Sourcing Agent: find-suppliers(category="electronics")
│   ├── [Span] MCP: supplier-db.search(query="electronics")
│   ├── [Span] A2A: → Compliance Agent: check-supplier(supplier-id=42)
│   │   ├── [Span] MCP: regulatory-db.lookup(supplier-id=42)
│   │   ├── [Span] MCP: certification-store.verify(iso-9001)
│   │   └── [Span] ← Compliance Agent: result={status: "conditionally-compliant"}
│   └── [Span] Sourcing Agent: compile-results()
└── [Result] 3 suppliers found, 1 conditionally compliant

Without this correlated trace, debugging a multi-agent interaction is nearly impossible. You see the tool calls but not which agent made them. You see the results but not how they were composed.

Layer 7: Evals

Must test both agent-to-agent interactions and agent-to-tool interactions. Testing agent A’s tool calls through MCP is straightforward: define inputs, define expected outputs, compare. Testing agent A’s delegation to agent B through A2A is harder because the test must evaluate not just the final result but the delegation decision itself.

Did agent A choose the right agent for the task? Did agent A provide sufficient context? Did agent A handle the response correctly? These are questions about the delegation behavior, not just the output. The eval suite needs test scenarios that probe delegation decisions.

Practical Integration Pattern

The integration pattern for teams building multi-agent systems today is to use MCP for all tool interactions and A2A for agent interactions where the receiving agent has meaningful autonomy. Define clear boundaries: if the receiving entity is a function, use MCP. If the receiving entity is a decision-maker, use A2A.

Unified Gateway

When both protocols are in use, the gateway layer should handle both. The same gateway that routes MCP tool calls should route A2A task delegations. This centralizes authentication, authorization, and observability in one place rather than splitting them across two separate gateways.

The gateway needs to understand both protocols and apply appropriate controls to each. MCP calls get tool-level authorization (is this agent allowed to call this tool?). A2A delegations get agent-level authorization (is this agent allowed to delegate to that agent?). Both get logging, rate limiting, and budget tracking.

Agent Registry

Build an agent registry that supports both MCP tools and A2A agents. The registry stores capabilities, endpoints, authentication requirements, and permission models for each entity. When agent A needs to find a capability, it queries the registry. The registry returns matching entities — some may be tools (MCP), some may be agents (A2A). The calling agent decides which to use based on the interaction pattern.

Permission Inheritance

Define a permission model that handles transitive access through A2A delegation. When agent A delegates to agent B, agent B’s tool calls should be evaluated against agent A’s permissions. This prevents the security gap where agent A gains access to resources it does not have by delegating to agent B who does.

What Teams Should Do Now

If you are building a single-agent system that uses tools, MCP is sufficient. You do not need A2A until you have multiple agents that need to communicate. Do not add A2A complexity for a problem you do not have.

If you are building a multi-agent system with ad-hoc communication between agents, evaluate A2A as a standardization opportunity. Ad-hoc protocols work until you need interoperability with agents from other teams or systems. A2A provides the standardization that enables that interoperability.

If you are building both, start with MCP for tool access and add A2A for agent communication. Do not try to replace MCP with A2A for tool access. Tools are not agents. They should not have the autonomy that A2A implies.

If you are building the control layer, design it to handle both protocols from the start. The gateway, the authorization model, the observability system, and the budget tracker should all be protocol-aware. Retrofitting protocol awareness later is harder than building it in.

The protocol choice is driven by the autonomy of the receiving entity, not by which protocol is newer or more fashionable. Match the protocol to the interaction pattern. The stack will naturally have both, and that is the correct architecture for systems where agents use tools and collaborate with other agents.

Ship it safely

If you’re hardening agent-to-agent and MCP boundaries for real users, our Model Gateway + MCP Control Plane Build covers it end to end. For a fast baseline across the seven control layers, take the AI Production Scorecard.