|7 min read

Google A2A Plus MCP: Two Protocols, One Ecosystem

Google's Agent-to-Agent protocol and Anthropic's Model Context Protocol are complementary, not competing, and together they define the agent infrastructure stack

Google released the Agent-to-Agent (A2A) protocol this month, and the immediate reaction from parts of the AI community was predictable: "Is this a competitor to MCP?" The answer is no, and understanding why requires looking at what each protocol actually does.

MCP and A2A solve different problems at different layers of the agent infrastructure stack. They are not competing standards. They are complementary protocols that, together, provide a more complete foundation for building agent systems than either one alone.

What Each Protocol Does

MCP (Model Context Protocol) connects AI agents to tools and data sources. When an agent needs to create a GitHub issue, query a database, send a Slack message, or read a file, MCP is the protocol that makes that connection. MCP servers expose capabilities. MCP clients (agents) consume them. The protocol handles discovery, invocation, and response formatting.

Think of MCP as the protocol between an agent and the world. It is how agents access external services and data.

A2A (Agent-to-Agent) connects AI agents to each other. When one agent needs to delegate a task to another agent, request information from a specialist agent, or coordinate a multi-step workflow across multiple agents, A2A is the protocol that enables that communication.

Think of A2A as the protocol between agents. It is how agents collaborate, delegate, and coordinate.

Why the Distinction Matters

This distinction is fundamental, and it maps directly to how I think about multi-agent systems.

In Loki Mode, agents interact with external services through MCP. The Code Generator agent creates pull requests through a GitHub MCP server. The Monitor Agent checks dashboards through a monitoring MCP server. These are agent-to-tool interactions, and MCP handles them well.

But agents in Loki Mode also interact with each other. The Planning Swarm produces a plan that the Implementation Swarm executes. The Review Swarm evaluates what the Implementation Swarm produced. The Debug Swarm investigates failures that the Testing Swarm discovered. These are agent-to-agent interactions.

Currently, Loki Mode handles agent-to-agent coordination through its own orchestration layer: shell scripts that manage state, pass context between agents, and coordinate execution. It works, but it is a custom solution to a general problem.

A2A provides a standardized approach to this coordination. Instead of every multi-agent system inventing its own inter-agent communication protocol, A2A offers a shared specification that agents from different systems can use to communicate.

The Stack

When you layer MCP and A2A together, you get a complete agent infrastructure stack:

Layer 3: Agent Systems (Loki Mode, AutoGPT, CrewAI, etc.)
Layer 2: Agent-to-Agent Protocol (A2A)
Layer 1: Agent-to-Tool Protocol (MCP)
Layer 0: Foundation Models (Claude, GPT, Gemini, etc.)

Each layer has a clear responsibility:

  • Layer 0 provides intelligence: reasoning, language understanding, code generation.
  • Layer 1 provides tool access: connecting agents to external services and data.
  • Layer 2 provides coordination: enabling agents to work together on complex tasks.
  • Layer 3 provides orchestration: defining workflows, quality gates, and domain-specific logic.

This layered architecture is clean and extensible. You can swap foundation models at Layer 0 (which Loki Mode already does with provider-agnostic design). You can add new tools at Layer 1 by building MCP servers. You can introduce new agents at Layer 2 through A2A. And you can build specialized systems at Layer 3 that compose all of these layers.

A2A's Design

Looking at the A2A specification, several design decisions stand out.

Agent Cards. Each A2A-compatible agent publishes an "Agent Card" that describes its capabilities, input/output formats, and interaction patterns. This is analogous to MCP's server capability declarations but for agents instead of tools. Discovery is important: if agents cannot find and understand each other, they cannot collaborate.

Task lifecycle. A2A defines a structured lifecycle for tasks delegated between agents: submitted, working, completed, failed. This lifecycle management is something I built custom in Loki Mode's orchestration layer. Having it standardized means less custom code and more interoperability.

Streaming support. A2A supports streaming responses, which matters for long-running agent tasks. A research agent investigating a complex question should be able to stream intermediate findings rather than blocking until the entire investigation is complete.

Authentication and authorization. A2A includes provisions for authenticating agents and authorizing task delegation. In a multi-agent system, not every agent should be able to delegate to every other agent. Access control at the agent communication layer is essential for production systems.

Implications for Loki Mode

A2A opens up possibilities for Loki Mode that would be difficult to achieve with custom inter-agent communication.

External agent integration. Today, Loki Mode's 41 agents all live within the Loki Mode system. With A2A, agents from other systems could participate in the RARV cycle. A specialized security analysis agent from a third-party system could serve as one of the three parallel reviewers in the Reflect phase, bringing capabilities that Loki Mode's built-in security auditor does not have.

Distributed execution. Currently, all Loki Mode agents run on the same machine. A2A could enable distributed agent execution, where agents run on different machines, in different environments, potentially using different providers, while coordinating through the A2A protocol.

Agent marketplaces. Just as MCP marketplaces are emerging for tools, A2A could enable agent marketplaces where specialized agents are published, discovered, and integrated into workflows. A company could publish a "compliance review agent" that other organizations integrate into their development pipelines.

The Interoperability Question

The real test for both MCP and A2A will be interoperability. Standards are only valuable if multiple implementations exist and they actually work together.

MCP has a head start here. Anthropic published the specification, built reference implementations, and a community has formed around building MCP servers. The protocol is being tested in production by thousands of developers. Interoperability bugs are being found and fixed.

A2A is newer and needs to go through the same maturation process. Google's backing gives it credibility, but credibility is not the same as proven interoperability. The protocol needs multiple independent implementations, real-world usage, and the inevitable edge cases and specification clarifications that come from actual deployment.

I am optimistic about both protocols because they are solving real problems. The need for standardized agent-to-tool communication is proven by MCP's adoption. The need for standardized agent-to-agent communication is proven by the fact that every multi-agent framework has built its own proprietary solution to the same problem.

What Builders Should Do

If you are building agent systems, here is my practical advice.

Adopt MCP now. The protocol is mature enough for production use. Building your tool integrations as MCP servers makes them reusable across agent frameworks and future-proofs them against changes in the agent layer.

Watch A2A closely. It is early, but the design is sound. If you are building multi-agent systems, start thinking about how your inter-agent communication could be expressed in A2A's terms. Even if you do not adopt A2A immediately, designing with its concepts in mind will make future adoption smoother.

Do not pick sides. The "MCP vs A2A" framing is wrong. These are different protocols for different purposes. The winning approach is to use both: MCP for tool access, A2A for agent coordination. Rejecting either one limits what you can build.

Contribute to both ecosystems. Both protocols benefit from community involvement. Build MCP servers. Experiment with A2A implementations. Report bugs, suggest improvements, and share what you learn. The standards that get the most real-world testing become the most robust.

The agent infrastructure stack is taking shape. MCP handles the vertical connections between agents and the world. A2A handles the horizontal connections between agents and each other. Together, they provide the foundation that the next generation of AI systems will be built on.

This is infrastructure work, and infrastructure work matters more than it gets credit for.

Share: