Mar 2026 · Engineering · 8 min

The Agentic Web: How A2A Is Teaching Agents to Collaborate

MCP solved the tool problem: how a single agent connects to databases, APIs, and files. But it deliberately left a harder problem untouched: how do agents find and talk to each other? That is the domain of Google's Agent-to-Agent protocol, and as of early 2026, it is rapidly becoming the second pillar of the agentic protocol stack.

The missing layer

Consider a realistic enterprise scenario. A customer support agent receives a refund request. It needs to verify the purchase history (finance agent), check the return policy (legal agent), process the refund (payments agent), and update the CRM (sales agent). Each of these agents may be built by different teams, on different frameworks, running on different infrastructure. Without a shared communication protocol, you are back to point-to-point integrations, the same M×N problem MCP solved for tools, now replicated at the agent layer.

graph TB
  Customer((Customer)) -->|"Refund request"| Support["Support Agent"]
  Support -->|A2A| Finance["Finance Agent"]
  Support -->|A2A| Legal["Legal Agent"]
  Support -->|A2A| Payments["Payments Agent"]
  Support -->|A2A| Sales["Sales Agent"]

  Finance -->|MCP| DB[(Transaction DB)]
  Legal -->|MCP| Docs["Policy Docs"]
  Payments -->|MCP| Stripe["Stripe API"]
  Sales -->|MCP| CRM[(Salesforce)]

  style Support fill:#0a0a0a,color:#ededed,stroke:#555
  style Finance fill:none,stroke:#555
  style Legal fill:none,stroke:#555
  style Payments fill:none,stroke:#555
  style Sales fill:none,stroke:#555
          

Google launched the Agent-to-Agent protocol in April 2025 to address exactly this. A2A is not competing with MCP. MCP is vertical: agent to tool. A2A is horizontal: agent to agent. They occupy different layers of the same stack, and they were designed to be complementary from the start.

Agent Cards: the business card of the agentic web

The central concept in A2A is the Agent Card, a JSON metadata document that every A2A-capable agent publishes at a well-known URL: /.well-known/agent.json. The card declares the agent's identity, capabilities, skills, service endpoint, supported authentication flows, and interaction requirements. Think of it as a machine-readable LinkedIn profile that lets other agents decide, before any communication happens, whether this agent can help with a given task.

graph LR
  subgraph "Agent Card at /.well-known/agent.json"
    direction TB
    ID["Identity
name, description, provider, version"]
    CAP["Capabilities
streaming: true, pushNotifications: true"]
    SKILLS["Skills
refund-processing, order-lookup, ..."]
    AUTH["Security
OAuth 2.0, API Key, mTLS"]
    EP["Endpoint
url, protocol: HTTP | gRPC"]
  end

  Client["Client Agent"] -->|"GET /.well-known/agent.json"| ID
  Client -->|"Evaluate skills"| SKILLS
  Client -->|"Authenticate"| AUTH
  Client -->|"Send task"| EP
  style Client fill:#0a0a0a,color:#ededed,stroke:#555
          

Agent Cards can be digitally signed using JSON Web Signature (JWS) to ensure authenticity. This is critical in multi-tenant enterprise environments where a rogue card could redirect sensitive tasks to a malicious endpoint. Discovery is passive and standards-based: client agents fetch the card, evaluate the declared skills, authenticate using the advertised scheme (API key, OAuth 2.0, or OpenID Connect), and then initiate collaboration.

How agents collaborate

Communication in A2A happens over HTTPS with JSON-RPC 2.0 as the message format, the same foundation MCP uses, which makes protocol bridging straightforward. Once a client agent discovers a remote agent via its Agent Card, the interaction follows a structured task lifecycle:

stateDiagram-v2
  [*] --> submitted
  submitted --> working : Agent starts processing
  submitted --> rejected : Agent refuses task
  working --> completed : Success
  working --> failed : Error
  working --> input_required : Needs clarification
  input_required --> working : Input received
  working --> canceled : User cancels
  completed --> [*]
  failed --> [*]
  canceled --> [*]
  rejected --> [*]
          

This lifecycle is not a suggestion. It is the protocol. Every agent must implement these state transitions, which gives orchestrators a reliable contract for monitoring progress, handling timeouts, and recovering from failures. The protocol supports streaming via Server-Sent Events and, as of version 0.3, gRPC for high-throughput scenarios where HTTP overhead matters.

The ACP merger: consolidation wins

A2A was not the only agent interoperability protocol. IBM Research launched the Agent Communication Protocol (ACP) in March 2025 to power its open-source BeeAI platform. ACP took a similar approach (agents as opaque services, structured task management, framework-agnostic design) but the community immediately saw the fragmentation risk. Two protocols solving the same problem at the same layer is one too many.

graph LR
  subgraph "Mar 2025"
    ACP["ACP
(IBM / BeeAI)"]
    A2A1["A2A
(Google)"]
  end
  subgraph "Jun 2025"
    LF["Linux Foundation"]
    ACP -->|donated| LF
    A2A1 -->|donated| LF
  end
  subgraph "Aug 2025"
    A2A2["A2A (unified)
ACP features merged"]
    LF --> A2A2
  end
  subgraph "Dec 2025"
    AAIF["Agentic AI Foundation
MCP + A2A + Goose + AGENTS.md"]
    A2A2 --> AAIF
  end
  style AAIF fill:#0a0a0a,color:#ededed,stroke:#555
          

IBM donated ACP to the Linux Foundation. Google donated A2A to the Linux Foundation. The teams recognized their fundamental alignment and, by summer 2025, ACP officially merged into A2A. The BeeAI platform migrated to A2A as its communication layer. ACP-specific features, particularly around agent interpretability and federated orchestration, are being upstreamed as A2A extensions. The merger eliminated the most dangerous fragmentation risk in the agentic protocol space before it could take hold.

The Agentic AI Foundation

In December 2025, Anthropic, Google, Microsoft, OpenAI, and AWS created the Agentic AI Foundation under the Linux Foundation. Both MCP and A2A now live here, alongside tools like Goose, Agents.md, BeeAI, and Docling. This is the institutional structure that makes multi-vendor agent interoperability possible. No single company controls the protocol stack. Governance is open, contributions are public, and the specification evolves through community RFC processes.

The foundation's implicit thesis is that the agentic era will not be won by any single model or framework. It will be won by the network effects of interoperability. The more agents that speak A2A and MCP, the more valuable every agent in the network becomes. This is Metcalfe's Law applied to AI infrastructure.

The protocol stack crystallizes

What has emerged in early 2026 is a clear multi-layer protocol stack for agentic systems:

The parallels to early internet infrastructure are hard to ignore. MCP is HTTP: the transport for accessing resources. A2A is SMTP: the protocol for entities communicating with each other. The analogy is imperfect, but the structural pattern is identical: open protocols, vendor-neutral governance, layered architecture, network effects that compound with adoption.

What this means for builders

If you are building agents today, protocol support is no longer optional. Publish an Agent Card. Implement MCP for your tool integrations. Expose an A2A endpoint for inter-agent communication. These are the table stakes for participating in the agentic web. Agents that cannot be discovered, cannot be delegated to, will be invisible to the rest of the network.

The most interesting applications in 2026 will not be single agents doing impressive things. They will be networks of specialized agents, each independently developed, independently deployed, independently maintained, collaborating on tasks no single agent could handle alone. The protocols are ready. The infrastructure is ready. The interesting part starts now.