The A2A Protocol: Why This Could Be HTTP for AI Agents

How 150+ companies are building the infrastructure for agents that can actually work together

Deep,

Here's a question that keeps coming up in infrastructure conversations: How do you make AI agents from different companies, built on different frameworks, actually collaborate?

Right now, connecting a LangChain agent to a CrewAI agent requires custom integration work. Every new agent framework means more glue code. It's the same fragmentation problem we had before HTTP standardized web communication.

Google's Agent2Agent (A2A) protocol, launched in April 2025 and now governed by the Linux Foundation with backing from AWS, Microsoft, Salesforce, SAP, and 150+ other organizations, aims to solve exactly this.

Let me break down what actually makes this interesting from an infrastructure perspective.

The Real Problem A2A Solves

When you hear "agent communication protocol," you might think this is just another API standard. It's not. The key insight is treating agents as opaque peers rather than tools to be invoked.

This distinction matters: MCP (Anthropic's Model Context Protocol) standardizes how agents connect to tools and data sources. A2A standardizes how agents communicate with each other as autonomous entities.

The official documentation puts it this way: MCP is like giving agents their toolbox. A2A is how they have a conversation while using those tools together.

Why this matters for production systems: An agent can delegate tasks to another agent without knowing its internal implementation, what LLM it uses, or what tools it has access to. The agents remain "black boxes" to each other while still collaborating effectively.

The Architecture (Technical Deep Dive)

A2A is built on standards you already know: HTTP(S), JSON-RPC 2.0, and Server-Sent Events. Version 0.3 added gRPC support. This isn't accidental—it means A2A plugs into existing enterprise infrastructure without requiring new networking paradigms.

Three core concepts:

1. Agent Cards — JSON documents (typically at /.well-known/agent.json) that describe an agent's capabilities, authentication requirements, supported modalities, and service endpoints. Think of it as a machine-readable resume that other agents can discover and parse.

2. Tasks — The fundamental unit of work. A task has a defined lifecycle with seven states: submitted, working, input-required, auth-required, completed, failed, and canceled. Once a task reaches a terminal state, it's immutable—any follow-up work becomes a new task.

3. Artifacts — The tangible outputs of completed tasks. Unlike general messages, artifacts are the actual deliverables: documents, images, structured data, or any file type the agents agree to exchange.

What Most People Miss: Long-Running Task Support

Here's a detail that doesn't get enough attention: A2A was designed from the ground up for tasks that take hours or even days, with humans potentially in the loop.

The protocol supports three interaction patterns:

Synchronous (blocking) — Client waits for task completion. Good for quick operations.

Streaming (SSE) — Real-time updates via Server-Sent Events. The client maintains an open connection and receives status updates, partial artifacts, and state transitions as they happen.

Push Notifications (Webhooks) — For mobile apps, serverless functions, or any scenario where maintaining a persistent connection isn't practical. The agent POSTs updates to a client-provided webhook URL.

This is where A2A differs from typical request-response APIs. Imagine a research agent that takes 6 hours to compile a comprehensive market analysis. The client agent can fire off the request, disconnect, and receive a webhook notification when results are ready—or get streaming updates about progress along the way.

Production Deployments Already Happening

This isn't theoretical. Companies are already building with A2A:

Tyson Foods and Gordon Food Service are building collaborative A2A systems to share product data and leads across the food supply chain in real-time.

Twilio extended A2A for latency-aware agent selection—individual agents broadcast their response times, and the system routes tasks to the most responsive agent available.

Adobe is using A2A to make their distributed content creation agents interoperable with external agent ecosystems.

ServiceNow's AI Agent Fabric implements A2A as their multi-agent communication layer, connecting ServiceNow agents with customer and partner-built agents.

S&P Global adopted A2A as their standard for inter-agent communication across their market intelligence organization.

The Linux Foundation Move (Why It Matters)

In June 2025, Google donated A2A to the Linux Foundation. This is significant for adoption.

When a protocol is owned by one company (even with an open license), enterprises hesitate. They worry about direction changes, preferential treatment, or eventual monetization. The Linux Foundation governance removes these concerns—it's the same model that made Kubernetes, Linux itself, and PyTorch trusted enterprise standards.

Jim Zemlin, Linux Foundation Executive Director: "By joining the Linux Foundation, A2A is ensuring the long-term neutrality, collaboration, and governance that will unlock the next era of agent-to-agent powered productivity."

AWS, Microsoft, Salesforce, SAP, Cisco, and others joined as foundational members. When competitors agree to collaborate on infrastructure, it usually signals the protocol has legs.

Security Model: What DevOps Teams Need to Know

A2A delegates security to existing enterprise standards rather than inventing new ones:

Transport — HTTPS mandatory in production, TLS 1.3+ recommended

Authentication — Declared in Agent Cards using OpenAPI-compatible schemes (Bearer/OAuth 2.0, API keys, Basic auth)

Authorization — Server-side responsibility, can be skill-based (certain OAuth scopes grant access to certain capabilities)

Observability — Built-in support for OpenTelemetry trace propagation via W3C Trace Context headers

Version 0.3 introduced signed security cards—agents can now cryptographically sign their Agent Cards, adding another verification layer.

The protocol also explicitly addresses GDPR/CCPA/HIPAA compliance, requiring implementations to practice data minimization in message exchanges.

A2A + MCP: The Emerging Stack

A pattern is emerging in production agent architectures:

The A2A documentation includes a car repair shop analogy: MCP handles the tools ("raise platform by 2 meters," "turn wrench 4mm to the right"), while A2A handles the human-like coordination ("my car is making a rattling noise" → "send me a picture of the left wheel" → "I notice fluid leaking").

Getting Started

If you want to experiment:

Official SDKs: Python and TypeScript are available via the GitHub repo

Sample Agents: The repo includes working examples—currency converter (LangGraph), image generator (CrewAI + Gemini), expense report processor (Google ADK)

A2A Inspector: Community-built debugging tool for testing agent interactions

Technology Compatibility Kit: For verifying your implementation matches the spec

The spec is at version 0.3. A production-ready 1.0 is expected by end of 2025. If you're building multi-agent systems now, it's worth following the roadmap.

The Bottom Line

A2A solves a real infrastructure problem: agent interoperability. It's built on boring, proven standards (HTTP, JSON-RPC). It has genuine enterprise backing across competing cloud providers. And it's now under neutral governance.

Will it become the universal standard? Too early to tell. But when 150+ companies including AWS, Microsoft, Google, Salesforce, and SAP all commit to the same protocol, that's not just hype—that's infrastructure convergence.

For DevOps engineers building agent systems, A2A is worth understanding now. Not because you need to implement it today, but because the patterns it establishes (Agent Cards, task lifecycle management, opaque execution) are likely to influence how multi-agent architectures evolve regardless of which specific protocol wins.

Keep shipping,
Deep