April 9, 2026 · 15 min read

Agent-to-Agent Protocol (A2A): The Agent Internet Explained

Google's open standard lets AI agents discover each other, delegate tasks, and collaborate across any vendor or framework. Here's what A2A means for operators — and how to build with it before the rest of the market catches on.

50+
Launch partners including Salesforce, SAP, and Deloitte
88%
Of executives piloting or scaling autonomous agents
$106B
Projected AI agent market by 2034 (38.5% CAGR)

Your Agents Can't Talk to Each Other. That's About to Change.

Here's a problem every operator hits eventually: you've got a customer service agent built with LangGraph, a data analysis agent running on Google ADK, and a content agent powered by Claude. They're all excellent at their individual jobs. But they can't collaborate.

When the customer service agent needs data analysis, someone has to manually wire the integration. When the content agent needs customer context, someone builds another custom API bridge. Every new agent-to-agent connection requires bespoke glue code. It doesn't scale.

This is the exact problem Google built the Agent-to-Agent (A2A) protocol to solve.

Announced in April 2025 and now backed by over 50 companies — including Salesforce, SAP, Deloitte, Accenture, McKinsey, and Nokia — A2A is an open standard that gives AI agents a universal language to discover, communicate, and collaborate with each other. Regardless of who built them, what framework they use, or where they run.

Think of it as HTTP for AI agents. Before HTTP, connecting different computer networks was a nightmare. A2A does the same thing for the fragmented world of AI agents.

How A2A Actually Works (Without the Jargon)

A2A's architecture is refreshingly simple. It uses HTTP, JSON-RPC, and Server-Sent Events — all proven web standards. No new transport layer to learn. No proprietary SDK to lock into. If you can build a web API, you can implement A2A.

The protocol operates on a client-server model with four core concepts:

1. Agent Cards — The AI Business Card

Every A2A-compatible agent publishes an Agent Card — a JSON file hosted at a well-known URL (typically /.well-known/agent.json). This card describes:

Agent Cards enable dynamic discovery. A client agent doesn't need a hardcoded list of collaborators — it can scan Agent Cards to find the best agent for any given task at runtime.

{
  "name": "Invoice Processing Agent",
  "description": "Extracts, validates, and routes invoice data from PDFs and emails",
  "url": "https://agents.example.com/invoice",
  "version": "1.2.0",
  "capabilities": ["invoice_extraction", "data_validation", "erp_routing"],
  "authentication": {
    "schemes": ["bearer"]
  },
  "inputModes": ["application/pdf", "message/rfc822", "text/plain"],
  "outputModes": ["application/json"]
}
💡 Operator Insight:

Agent Cards are the new API documentation. The quality and completeness of your Agent Card directly determines whether other agents can find and use your services. Invest the same care in your Agent Card as you would in an OpenAPI spec.

2. Tasks — The Unit of Work

When a client agent finds a suitable remote agent, it creates a Task. Each task has a unique ID and progresses through a defined lifecycle:

This lifecycle is critical for real-world scenarios. Not every task finishes in milliseconds. Some — like a research agent analyzing 200 documents or a compliance agent reviewing a contract — take minutes or hours. A2A's task model supports both immediate responses and long-running operations (LROs) with streaming updates via Server-Sent Events.

3. Messages — The Conversation Layer

During task execution, agents exchange Messages. Each message contains one or more Parts — structured content blocks that can include text, images, JSON data, or file references. This multi-modal support means agents can negotiate the right format based on what the receiving agent (or the end user) can handle.

Messages flow in both directions. The client agent can provide additional context, clarify requirements, or pass along user instructions. The remote agent can ask for clarification, provide progress updates, or deliver partial results.

4. Artifacts — The Deliverables

When a task completes, the output is delivered as an Artifact — a structured result that can contain any type of content. An invoice processing agent might return extracted line items as JSON. A report agent might return a PDF. A translation agent might return localized text in three languages.

Artifacts are immutable once delivered, creating a clear audit trail for every agent collaboration.

A2A vs MCP: Not a Competition, an Architecture

The biggest misconception in the agent ecosystem right now is that A2A and MCP are competing standards. They're not. They solve different problems at different layers of the stack.

Cisco's networking analogy puts it best: MCP is Layer 2 (local tools), A2A is Layer 3 (agent routing).

Dimension MCP (Anthropic) A2A (Google)
What it connects An agent to tools, data sources, and context An agent to other agents
Direction Vertical (agent ↔ tool) Horizontal (agent ↔ agent)
Discovery Tool manifests (list of functions) Agent Cards (high-level capabilities)
State Shares context, memory, tool state Opaque — agents don't share internal state
Scalability Limited by context window (tool descriptions consume tokens) Scales horizontally (Agent Cards are lightweight summaries)
Security model Trust-based (agent sees tool internals) Zero-trust compatible (agents are opaque to each other)
Best for Single agent + many tools Multi-agent orchestration across teams/vendors
Adoption 10,000+ MCP servers, rapid adoption 50+ partners, slower but accelerating (DeepLearning.AI course launched Feb 2026)

The real answer? Use both.

A supervisor agent uses A2A to discover and delegate tasks to specialized agents across your organization. Each specialized agent uses MCP to access its own tools, databases, and APIs. A2A handles the routing; MCP handles the execution.

Architecture Example

Enterprise Support System

A customer emails about a billing issue. The triage agent (built with LangGraph) uses A2A to discover a billing agent (built with Google ADK) and a customer history agent (built with CrewAI). The billing agent uses MCP to query the payment database and Stripe API. The customer history agent uses MCP to access the CRM. Both agents return artifacts to the triage agent, which composes a response. Three vendors, three frameworks, zero custom integrations.

The A2A Partner Ecosystem

A2A launched with an impressive coalition. Here's who's building with it:

Category Partners
Enterprise Software Salesforce, SAP, ServiceNow, Workday, Atlassian, Box
Consulting Accenture, BCG, Capgemini, Deloitte, KPMG, McKinsey, PwC, Infosys, TCS, Wipro
Infrastructure MongoDB, Neo4j, Elastic, Cisco, Nokia
AI Platforms LangChain, CrewAI, Weights & Biases, Cohere
Security CrowdStrike, Palo Alto Networks, Ping Identity

Google positioned A2A explicitly as complementary to MCP, not competitive. The protocol is open-source on GitHub, aligned with the Linux Foundation, and designed so anyone can implement it — not just Google Cloud customers.

💡 Why This Matters for Operators:

When Deloitte, McKinsey, and Accenture are all building A2A integrations for their enterprise clients, the consulting demand will flow downstream. Smaller operators who already understand A2A will be well-positioned for subcontracting and direct client work.

5 Real-World A2A Use Cases

Use Case 1

Cross-Vendor IT Operations

A network monitoring agent (Cisco) detects anomalous traffic. Via A2A, it delegates threat analysis to a security agent (CrowdStrike) and incident documentation to a ticketing agent (ServiceNow). No human needed for initial triage. The security agent returns its assessment as an artifact; the ticketing agent creates and assigns the incident — all within seconds.

Use Case 2

Multi-Department HR Workflows

A new employee onboarding agent uses A2A to coordinate with: an IT provisioning agent (create accounts, assign hardware), a compliance agent (background check, policy acknowledgments), a payroll agent (tax forms, benefits enrollment), and a training agent (schedule orientation, assign courses). Four departments, four specialized agents, one seamless onboarding experience.

Use Case 3

Supply Chain Orchestration

A demand forecasting agent detects a spike in orders. Via A2A, it notifies an inventory agent to check stock levels, a procurement agent to initiate supplier orders, and a logistics agent to schedule additional shipping capacity. Each agent operates independently, reports back through artifacts, and the orchestrator presents a unified plan to the operations team.

Use Case 4

Financial Services Compliance

A transaction monitoring agent flags suspicious activity. Through A2A, it delegates KYC verification to one agent, regulatory cross-referencing to another, and report generation to a third. The compliance officer receives a complete case file — assembled by three agents from three different vendors — in minutes instead of hours.

Use Case 5

Agentic Commerce (Buyer ↔ Seller)

A buyer's procurement agent sends structured requirements via A2A to multiple sellers' agents. Each seller agent evaluates against inventory, margin targets, and relationship history, then responds with a tailored offer. The buyer agent compares responses, negotiates terms, and presents the human buyer with a recommended winner. Agent-to-agent commerce at machine speed.

Building Your First A2A Agent

Ready to get hands-on? Here's a practical walkthrough of making an agent A2A-compatible.

Step 1: Define Your Agent Card

Start with the identity document. Your Agent Card should be specific about capabilities — vague descriptions lead to misrouted tasks.

{
  "name": "Content Repurpose Agent",
  "description": "Transforms long-form blog posts into social media content packages: LinkedIn posts, X threads, and newsletter snippets",
  "url": "https://agents.yourcompany.com/repurpose",
  "version": "1.0.0",
  "capabilities": [
    "blog_to_linkedin",
    "blog_to_x_thread",
    "blog_to_newsletter",
    "batch_repurpose"
  ],
  "authentication": {
    "schemes": ["bearer"],
    "instructions": "Obtain a token from https://auth.yourcompany.com/agents"
  },
  "inputModes": ["text/html", "text/markdown", "text/plain"],
  "outputModes": ["application/json"]
}

Step 2: Implement the Task Endpoint

Your agent needs to accept JSON-RPC requests and manage task lifecycles. The minimum endpoints are:

Step 3: Handle the Task Lifecycle

When a task arrives, your agent should:

  1. Validate the request and authentication
  2. Set task status to working
  3. Process the input (this is where your agent's actual logic lives)
  4. If you need more info, set status to input-required and send a message
  5. On completion, create an artifact and set status to completed
  6. On failure, set status to failed with an error message

Step 4: Host Your Agent Card

Deploy your Agent Card at /.well-known/agent.json on your agent's domain. This is the discovery mechanism — other agents will look for this file to understand what you can do.

⚠️ Common Mistake:

Don't host your Agent Card behind authentication. It needs to be publicly readable for discovery to work. Authentication happens when an agent actually tries to send a task — not when it's browsing capabilities.

Step 5: Test with an A2A Client

Google's Agent Development Kit (ADK) includes A2A client libraries. You can also use the open-source A2A reference implementation to test your agent. DeepLearning.AI's free A2A course walks through building compliant agents with LangGraph, Google ADK, and BeeAI.

A2A Security: What Operators Must Know

A2A was designed with enterprise security in mind, but "designed for security" and "secure by default" are different things. Here's what you need to implement:

Authentication

Agent Cards specify supported authentication schemes. A2A supports standard web auth: JWT tokens, OAuth 2.0, API keys, and OIDC. Every task request must be authenticated before processing. No exceptions.

Authorization

Authentication tells you who is calling. Authorization tells you what they're allowed to do. Implement capability-based access control: not every authenticated agent should access every skill your agent offers.

Opacity by Design

One of A2A's strongest security features is that agents are opaque to each other. A remote agent doesn't share its internal state, memory, tools, or reasoning with the client agent. It receives a task, processes it internally, and returns a result. This prevents data leakage between organizations and protects intellectual property.

Transport Security

A2A runs over HTTPS. All messages are encrypted in transit. For sensitive payloads, consider additional encryption at the application layer.

💡 Security Checklist for A2A Agents:

✅ HTTPS only (no HTTP fallback) · ✅ JWT/OAuth on every task endpoint · ✅ Rate limiting per client agent · ✅ Input validation on all messages · ✅ Audit logging for every task lifecycle event · ✅ Capability-based authorization (not just authentication) · ✅ Payload size limits to prevent abuse

The Challenges We Can't Ignore

A2A is promising, but it's early. Here are the real friction points:

1. Adoption Is a Slow Burn

MCP had 10,000+ servers within months. A2A adoption has been slower. As Cisco noted: "MCP has seen rapid adoption, while A2A's progress has been more of a slow burn." This makes sense — MCP solves an immediate pain point (connecting agents to tools), while A2A solves a next-stage problem (connecting agents to agents). You need working agents before you need agent interoperability.

2. Scalability at Enterprise Scale

A2A uses point-to-point HTTP communication. In small systems, this works fine. In enterprise environments with hundreds of agents, direct point-to-point connections can become a complex mesh. You may need additional orchestration layers, message queues, or service meshes to manage the complexity.

3. Cascading Failures

When Agent A delegates to Agent B, which delegates to Agent C — what happens when C fails? A2A's task lifecycle handles individual failures, but cascading failure recovery across agent chains requires careful engineering. Build circuit breakers and fallback logic into your orchestration layer.

4. Trust and Verification

When your agent discovers an Agent Card, how do you verify the remote agent is trustworthy? A2A doesn't yet include a reputation or trust-scoring system. In enterprise contexts, you'll likely maintain an allowlist of approved agent endpoints. In open ecosystems, this becomes a harder problem.

5. Debugging Multi-Agent Flows

When something goes wrong in a chain of five agents from three vendors, debugging is painful. A2A task IDs help with tracing, but you'll want to implement distributed tracing (OpenTelemetry) across your agent infrastructure from day one.

5-Day A2A Implementation Plan

Day 1 — Discovery

Map Your Agent Landscape

Inventory every AI agent in your organization (or your client's). Map the current integration points between them — which ones need to communicate? Which integrations are currently handled by custom code? Identify the top 3 agent-to-agent connections that would benefit most from standardization.

Day 2 — Agent Cards

Design Your Identity Layer

Write Agent Cards for your top 3 agents. Be specific about capabilities — the quality of your Agent Card determines how effectively other agents can discover and use yours. Host them at their well-known URLs. Test discovery by hitting each /.well-known/agent.json endpoint.

Day 3 — First Integration

Build Your First A2A Connection

Pick your simplest agent-to-agent integration. Implement the task endpoints on the remote agent. Build a client that discovers the Agent Card, authenticates, sends a task, and polls for completion. Use Google ADK or the A2A reference implementation as your starting point.

Day 4 — Security + Monitoring

Harden and Instrument

Add authentication (JWT/OAuth), rate limiting, and input validation. Implement logging for every task lifecycle transition. Add OpenTelemetry tracing so you can follow tasks across agents. Build a simple dashboard showing active tasks, completion rates, and error rates.

Day 5 — Long-Running Operations

Handle the Real World

Implement SSE streaming for long-running tasks. Add timeout handling, graceful cancellation, and retry logic. Test the failure scenarios: what happens when the remote agent goes down mid-task? What happens when authentication expires? Build the resilience that production demands.

What's Coming Next for A2A

A2A is evolving fast. Here's what the roadmap signals:

The Operator's Bottom Line

A2A is the missing piece in the multi-agent puzzle. MCP connects agents to tools. A2A connects agents to each other. Together, they form the foundation of what Cisco aptly calls "the agent internet."

The adoption curve mirrors the early internet. Right now, most organizations are building isolated agents (like early networks). A2A enables those agents to interconnect (like the internet connected those networks). The organizations that invest in interoperability now will have compounding advantages as the agent ecosystem grows.

If you're an operator building multi-agent systems, start with Agent Cards. Make your agents discoverable. Implement one A2A connection this week. The protocol is free, open-source, and built on web standards you already know.

If you're a business buyer, ask your vendors one question: "Is your AI agent A2A-compatible?" If the answer is no, you're buying into a silo. And silos are where agent investments go to die.

The agents that can't talk to each other are the agents that get replaced. Build for interoperability. Build with A2A.

🌐 Building Multi-Agent Systems?

The AI Employee Playbook covers agent architecture, orchestration patterns, and the protocols that matter in 2026 — including A2A and MCP.

Get the Playbook — €29

Sources