A2A v1.0 Is Here: How Google's Agent Protocol Complements MCP

Three days ago, the Agent-to-Agent (A2A) protocol shipped its v1.0 release under the Linux Foundation. With a Technical Steering Committee that includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow, this is not a research project anymore. It is an industry standard with enterprise backing, production-ready SDKs in five languages, and 22,500 GitHub stars.

The timing matters. The Model Context Protocol has become the de facto standard for agent-to-tool communication, but MCP deliberately does not address how agents talk to each other. A2A fills that gap. Understanding where each protocol operates — and how they compose — is essential for anyone building multi-agent systems in 2026.

The Two-Layer Protocol Stack

The cleanest way to understand A2A and MCP is as two layers of the same architecture:

MCP operates at the agent-to-tool layer. When an agent needs to query a database, call an API, read a file, or invoke any external capability, MCP provides the discovery and execution protocol. The agent connects to an MCP server, discovers available tools via their schemas, and invokes them. MCP handles capability negotiation, authentication, and structured I/O between the agent and its tools.

A2A operates at the agent-to-agent layer. When an agent needs to delegate a task to another agent — one that may be built on a different framework, hosted by a different organization, or running a completely different model — A2A provides the communication protocol. The requesting agent discovers the target agent’s capabilities via its Agent Card, sends a task request, and receives results through polling, streaming, or webhooks.

This separation is intentional and reflects a design principle that both protocol teams have explicitly endorsed: agents should be opaque to each other. When Agent A delegates a task to Agent B via A2A, Agent A does not know or care which tools Agent B uses internally. Agent B might use MCP to connect to databases, APIs, and file systems — but from Agent A’s perspective, it sent a task and received a result. The internal implementation is hidden behind the A2A boundary.

This is a meaningful architectural choice. It means that organizations can expose agent capabilities to partners without revealing their internal tool chains, model configurations, or data access patterns. The A2A protocol preserves intellectual property and security boundaries while enabling collaboration.

What A2A v1.0 Actually Ships

The v1.0 release focuses on production readiness over new features. Having tracked the protocol since its v0.1 days, the maturation from experimental draft to stable specification is significant. Here is what the release includes:

Signed Agent Cards

Agent Cards are JSON metadata documents that describe an agent’s identity, capabilities, skills, service endpoints, and authentication requirements. They serve the same function as OpenAPI specs serve for REST APIs — they are the discovery mechanism that lets clients understand what an agent can do before sending any requests.

The v1.0 spec adds cryptographic signatures to Agent Cards via the AgentCardSignature field. This enables verification that an Agent Card was published by its claimed provider and has not been tampered with in transit. For anyone who has followed the MCP security discussion around tool schema verification, this is a familiar pattern — but A2A is shipping it as a first-class protocol feature from the start.

An Agent Card declares:

• Identity: Name, description, version, and provider information
• Skills: Discrete functional capabilities the agent can perform, each with its own description and tags
• Interfaces: Supported protocol bindings — JSON-RPC 2.0, gRPC, or HTTP/REST
• Security Schemes: Authentication requirements — API Key, OAuth2, HTTP Bearer, Mutual TLS, or OpenID Connect
• Capabilities: Boolean flags for optional features like streaming, pushNotifications, and extendedAgentCard

Discovery works through well-known URLs, similar to how /.well-known/openid-configuration works for OIDC. Clients fetch the Agent Card, validate its signature, inspect the declared interfaces and security schemes, and then authenticate using one of the declared mechanisms. Authenticated clients can call GetExtendedAgentCard to access additional capabilities that are not publicly advertised.

Task Lifecycle

A2A models interactions as tasks that progress through a defined state machine. This is more structured than a simple request/response pattern and supports the kind of long-running, multi-turn interactions that real agent workflows require.

The core task states are:

• PENDING — Task created, awaiting processing
• WORKING — Active processing underway
• INPUT_REQUIRED — Agent needs additional information from the client
• AUTH_REQUIRED — Agent needs authorization to proceed
• COMPLETED — Successfully finished
• FAILED — Encountered an error
• CANCELED — Client-initiated cancellation
• REJECTED — Agent declined the task

The INPUT_REQUIRED and AUTH_REQUIRED states are particularly interesting. They enable multi-turn interactions where an agent can pause mid-execution, request clarification or credentials, and then resume. This models how human delegation actually works — you ask someone to do something, they come back with questions, you answer, and they continue.

Tasks are grouped by contextId, so multiple related tasks share conversational context. Clients can poll for status, subscribe to streaming updates via Server-Sent Events, or register webhook endpoints for fully asynchronous notification.

Multi-Tenancy and Enterprise Features

The v1.0 release adds formal multi-tenancy support, allowing a single endpoint to host multiple agents. Combined with the security scheme flexibility (OAuth2, mTLS, OIDC), this aligns A2A with enterprise deployment patterns where agents run behind API gateways, load balancers, and identity providers.

The protocol explicitly embraces web-aligned principles: stateless design, layered architecture, standard protocol bindings, and infrastructure-friendly communication patterns. This means organizations can apply their existing load balancing, gateway security, and observability tooling to A2A traffic without specialized infrastructure.

Composing A2A and MCP in Practice

The theoretical separation of concerns is clean, but how does this work in a real system? The most common pattern emerging from early adopters is decoupled orchestration and execution.

Consider a practical example: an MLOps pipeline that validates a model and conditionally deploys it.

1. A user sends a request to an orchestrator agent: “Validate the churn model; if bias is below 0.04, deploy to the EU region.”

2. The orchestrator agent breaks this into subtasks. It uses A2A to discover a validation agent (via its Agent Card) and delegates the validation task.

3. The validation agent receives the A2A task, then uses MCP to connect to its internal tools — a model registry, a bias testing framework, and a metrics dashboard. It executes the validation and streams results back to the orchestrator via A2A.

4. The orchestrator evaluates the results. If the bias threshold is met, it uses A2A to discover and delegate to a deployment agent.

5. The deployment agent uses MCP to access deployment tools — infrastructure provisioning, canary configuration, health check endpoints — and streams deployment status back via A2A.

The key property of this architecture is that the orchestrator never touches MCP directly. It does not know or care which tools the specialist agents use. It communicates entirely through A2A. Meanwhile, each specialist agent uses MCP internally for tool access but presents a clean A2A interface to the outside world.

This pattern has concrete benefits:

Independent scaling. Specialist agents can be deployed, updated, and scaled independently. Adding a new tool to the validation agent’s MCP server does not affect the orchestrator or the deployment agent.

Vendor interoperability. The orchestrator might be built with LangGraph, the validation agent with CrewAI, and the deployment agent with Semantic Kernel. A2A provides the interoperability layer.

Security boundaries. Each agent’s MCP connections are internal. The deployment agent’s infrastructure credentials never cross the A2A boundary. The orchestrator cannot even discover what tools the specialist agents have access to.

The Competitive Landscape

A2A is not the only approach to agent-to-agent coordination. Several alternative protocols and frameworks have emerged, each with different design philosophies. Understanding these alternatives helps clarify what A2A optimizes for and what tradeoffs it makes.

MACP (Multi-Agent Cognition Protocol)

MACP targets a different problem than A2A. While A2A handles inter-agent communication and delegation, MACP focuses on cognitive coordination during active execution — keeping agents aligned while they are simultaneously working on related tasks.

MACP enables agents to claim work assignments, publish findings, send priority-ranked updates, and poll for new information during active work. The current implementation is SQLite-backed and intentionally lightweight, deployable without additional infrastructure.

The positioning is complementary: MCP handles tool access, A2A handles communication, and MACP handles real-time coordination. Whether the ecosystem needs a third protocol layer or whether A2A’s task lifecycle (with INPUT_REQUIRED states and streaming) can absorb this functionality remains an open question.

SBP (Stigmergic Blackboard Protocol)

SBP takes a radically different approach inspired by ant colony behavior. Instead of direct agent-to-agent messaging, agents coordinate through environmental signals on a shared blackboard. Agents post signals with varying intensities, signals decay over time, and other agents sense the blackboard independently and respond based on internal logic.

This creates extremely loose coupling — adding new agents does not require updating existing agent logic, and there is no single point of orchestration failure. SBP positions itself as addressing orchestration bottlenecks that emerge when direct messaging scales poorly.

The tradeoff is precision. A2A’s explicit task delegation model gives you deterministic control over which agent handles which task. SBP’s emergent coordination model is better suited for scenarios where you want self-organizing behavior — think swarm intelligence rather than structured delegation.

Pressure-Field Coordination

A recent paper (arXiv 2601.08129) proposes an approach where agents operate locally on a shared artifact, guided by pressure gradients derived from measurable quality signals, with temporal decay preventing premature convergence. On meeting room scheduling benchmarks across 1,350 trials, this approach achieved a 48.5% aggregate solve rate compared to 12.6% for conversation-based coordination and 1.5% for hierarchical control.

These numbers challenge the assumption that hierarchical orchestration — the pattern A2A is primarily designed for — is always optimal. For certain problem classes, decentralized coordination mechanisms outperform explicit delegation significantly.

Framework-Level Solutions

CrewAI, LangGraph, and AutoGen all provide their own multi-agent coordination mechanisms. These work well within a single framework but create vendor lock-in. A2A’s value proposition is cross-framework interoperability — the orchestrator agent and specialist agents do not need to share a framework.

The practical question is whether enterprises will standardize on A2A for cross-boundary agent communication while using framework-native coordination for internal agent clusters. Early signals suggest yes. The pattern is analogous to how microservices use HTTP/gRPC for inter-service communication while using in-process abstractions internally.

What This Means for the MCP Ecosystem

A2A’s v1.0 release has several implications for the MCP ecosystem specifically:

Agent identity is coming to MCP. The MCP specification discussion #2404 proposes adding agent identity and delegation to MCP tool calls using Ed25519 keypairs. A2A’s Signed Agent Cards provide a reference implementation for how cryptographic agent identity can work at the protocol level. Expect MCP to adopt similar patterns for tool-call attribution and delegation chains.

The “context explosion” problem gets a structural solution. One of MCP’s ongoing challenges is that connecting to many MCP servers overwhelms the agent’s context window with tool definitions. By pushing inter-agent communication to A2A, you reduce the number of MCP connections each individual agent needs. The orchestrator does not connect to any MCP servers at all — it only speaks A2A. Each specialist agent connects to a focused set of MCP servers relevant to its domain. This architectural separation naturally bounds context size.

Security boundaries become clearer. MCP’s trust model currently relies on the agent trusting the MCP server’s tool schemas. A2A adds a second trust boundary at the agent-to-agent level, with its own authentication and signature verification. A well-designed system uses A2A’s security mechanisms for inter-agent trust and MCP’s mechanisms (OAuth 2.1, schema validation) for agent-to-tool trust.

The proxy pattern gets richer. MCP proxies that aggregate and filter tool access — managing context size, quarantining schemas, enforcing policies — can now also serve as A2A gateways. An agent proxy that speaks both protocols can manage an agent’s entire external interface: A2A for peer communication and MCP for tool access.

Practical Adoption Guidance

If you are building multi-agent systems today, here is how to think about adopting A2A alongside MCP:

Start with MCP for tool integration. If your agents primarily need to access tools, APIs, and data sources, MCP is the right protocol. A2A adds value when you need agents from different teams, organizations, or frameworks to communicate.

Use A2A for cross-boundary communication. When Agent A (built by Team X on LangGraph) needs to delegate work to Agent B (built by Team Y on CrewAI), A2A provides the interoperability layer. Within a single team’s agent cluster, framework-native coordination may be simpler.

Publish Agent Cards for your agents. Even if you are not actively using A2A for communication, publishing Agent Cards makes your agents discoverable. Think of it as creating an OpenAPI spec — it documents capabilities and enables future integration.

Plan for signed identity. Both A2A (Signed Agent Cards) and MCP (proposed Ed25519 delegation) are moving toward cryptographic agent identity. Design your systems with agent identity as a first-class concept now, even if the full verification infrastructure is still maturing.

Watch the SDK ecosystem. A2A ships SDKs for Python, Go, JavaScript, Java, and .NET. MCP has mature SDKs across similar languages. The tooling for building systems that use both protocols is available today, and the DeepLearning.AI partnership with Google Cloud suggests educational resources are coming.

The Bigger Picture

The emergence of A2A v1.0 alongside MCP marks a maturation point for the agentic AI infrastructure stack. We now have two complementary, open-standard protocols with serious institutional backing:

• MCP (Anthropic, broad ecosystem): Agent-to-tool communication
• A2A (Google, Linux Foundation): Agent-to-agent communication

This mirrors how the web matured. HTTP handled client-server communication, but the ecosystem needed additional protocols for service discovery (DNS), security (TLS), authentication (OAuth), and inter-service communication (gRPC). The agentic AI ecosystem is following the same pattern, with specialized protocols for different layers of the stack.

The question is not whether you need A2A or MCP. The answer is increasingly both — with each protocol handling the communication layer it was designed for.

The alternative protocols — MACP for cognitive coordination, SBP for emergent swarm behavior, pressure-field methods for decentralized optimization — suggest that A2A and MCP may not be the final answer for every use case. But for the core pattern of structured agent delegation and tool access, the A2A+MCP stack is becoming the industry default.

With eight major enterprise vendors on the steering committee, Linux Foundation governance, and Apache 2.0 licensing, A2A v1.0 is a bet that the industry is ready to standardize. For MCP practitioners, it is the missing piece that extends your agent architectures from single-agent tool use to multi-agent collaboration — without requiring you to change anything about how your agents access tools.