The A2A Protocol Explained: How AI Agents Will Discover Each Other

Right now, most AI agents operate in isolation. Your customer support agent can't talk to your vendor's logistics agent. Your sales automation tool has no idea that a research agent three floors up could feed it competitive intelligence. Each one is powerful on its own — but they're all stuck behind proprietary walls.

The Agent2Agent (A2A) protocol is Google's answer to that problem. It's an open standard that gives AI agents a shared language for discovering each other, advertising their capabilities, and collaborating on tasks — regardless of which vendor built them or what framework they run on.

This guide breaks down how A2A works, what Agent Cards are, how discovery actually functions today, and where the critical gaps remain. If you're building, buying, or evaluating AI agents, this protocol will shape the next chapter of the agent economy.

What Is the A2A Protocol?

The Agent2Agent (A2A) protocol is an open specification for enabling communication and interoperability between AI agents. Originally released by Google and now governed by the Linux Foundation, it defines how agents announce their capabilities, negotiate interaction patterns, and exchange messages — all over standard HTTPS using JSON-RPC.

A few key design principles make A2A different from earlier integration approaches:

• Opaque by design — Agents don't share their internal state, prompt chains, or tool configurations. They only expose what they choose to through a structured metadata document called an Agent Card.
• Framework-agnostic — Whether your agent is built on LangChain, CrewAI, AutoGen, or a custom stack, A2A doesn't care. It operates at the communication layer, not the framework layer.
• Task-oriented — A2A models interactions as tasks with defined lifecycles: submitted, working, completed, or failed. This makes it natural for multi-step, long-running workflows where one agent delegates work to another.
• Built on existing web standards — HTTPS, JSON-RPC 2.0, Server-Sent Events for streaming, and webhooks for push notifications. No new transport protocols to learn.

The protocol defines three roles: a User (the human or system initiating a request), an A2A Client (the agent that delegates work), and an A2A Server (the agent that receives and executes the task). Importantly, any agent can be both a client and a server — an agent that receives a task can turn around and delegate subtasks to other agents downstream.

The Problem It Solves: Agents Are Siloed

Today's AI agent ecosystem has a fragmentation problem. Every major vendor — Salesforce, Microsoft, ServiceNow, Intercom, and hundreds of startups — has built their own agent framework. Each one works great within its own walled garden. But the moment you need agents from different vendors to cooperate, you're writing custom integration code.

Consider a common business scenario: a customer emails asking to change their shipping address on an order that's already been dispatched. To resolve this, you'd need your customer support agent (maybe Sierra or Intercom Fin) to understand the request, your logistics agent (built on your shipping provider's system) to check whether rerouting is possible, and your CRM agent to update the customer record. Today, that coordination happens through brittle, point-to-point integrations — or it doesn't happen at all, and a human steps in.

A2A addresses this by providing a universal contract for agent-to-agent interaction. Instead of building custom integrations for every agent pair, you give each agent an Agent Card that describes what it can do, and any A2A-compliant agent can read that card, understand the capabilities, and initiate collaboration.

Agent Cards Explained: The "Business Card" for AI Agents

The most important concept in A2A is the Agent Card. Think of it as a machine-readable business card that an AI agent publishes to tell the world: here's who I am, here's what I can do, here's how to authenticate, and here's the endpoint where you can reach me.

An Agent Card is a JSON document that every A2A-compliant server must publish. It contains several key sections:

• Identity — The agent's name, description, version, and provider organization.
• Service endpoint — The HTTPS URL where other agents can send requests.
• Capabilities — Protocol-level features the agent supports, such as streaming responses (via Server-Sent Events), push notifications (via webhooks), and state transition history.
• Skills — The specific things the agent can do, each with its own ID, description, tags, example prompts, and supported input/output formats.
• Security — Authentication schemes (OAuth2, API keys, OpenID Connect) and required scopes, so client agents know how to authenticate before they send a request.
• Input/Output modes — The MIME types the agent accepts and produces (text, JSON, images, files), both as defaults and per-skill overrides.

Here's what a real Agent Card looks like, based on the structure defined in the A2A specification:

{
  "name": "Acme Expense Processor",
  "description": "Processes expense reports, validates receipts, and routes approvals according to company policy.",
  "url": "https://agents.acme.com/a2a/v1",
  "provider": {
    "organization": "Acme Corp",
    "url": "https://www.acme.com"
  },
  "version": "2.0.1",
  "documentationUrl": "https://docs.acme.com/expense-agent",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": false
  },
  "securitySchemes": {
    "corporate_oidc": {
      "type": "openIdConnect",
      "openIdConnectUrl": "https://auth.acme.com/.well-known/openid-configuration"
    }
  },
  "security": [{ "corporate_oidc": ["expense.submit", "expense.approve"] }],
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json", "text/plain"],
  "skills": [
    {
      "id": "process-expense-report",
      "name": "Process Expense Report",
      "description": "Validates line items, matches receipts, checks policy compliance, and routes for approval.",
      "tags": ["finance", "expenses", "approval", "compliance"],
      "examples": [
        "Process the Q1 travel expense report for Jamie Chen",
        "Validate and submit expense report EXP-2026-0412"
      ]
    },
    {
      "id": "check-expense-status",
      "name": "Check Expense Status",
      "description": "Returns the current approval status and any pending actions for a submitted expense report.",
      "tags": ["finance", "status", "tracking"],
      "examples": [
        "What's the status of expense report EXP-2026-0412?"
      ]
    }
  ],
  "supportsAuthenticatedExtendedCard": true
}

Every field in the Agent Card serves a purpose. The skills array is particularly important: it tells other agents exactly which tasks this agent can handle, with tags for matching and example prompts showing how to invoke each skill. The securitySchemes section lets client agents negotiate authentication before they ever send a request — no trial-and-error.

How Agent Discovery Works Today

Having a great Agent Card is only useful if other agents can find it. A2A defines a primary discovery mechanism — and acknowledges that it has limits.

The well-known URL pattern

The A2A spec recommends that every agent server publish its Agent Card at a standardized path following RFC 8615 (the "Well-Known URIs" standard):

GET https://{agent-server-domain}/.well-known/agent.json

This is exactly how it sounds: if you know the domain where an agent lives, you can fetch its Agent Card by hitting that URL. It's analogous to how robots.txt works for web crawlers or how /.well-known/openid-configuration works for identity providers.

Three discovery methods

The specification acknowledges three ways agents can discover each other:

1. Well-Known URI — The standard path described above. Works well when a client agent already knows which server to query, but requires prior knowledge of the domain.
2. Registries and catalogs — Third-party directories that aggregate Agent Cards from multiple providers. The spec mentions this method but doesn't define a registry standard.
3. Direct configuration — A human or system manually provides an Agent Card URL to a client agent. This is the most common approach today and the least scalable.

Authenticated extended cards

A2A also supports the concept of an authenticated extended Agent Card. The public Agent Card at the well-known URL might expose a limited view of an agent's capabilities. If the supportsAuthenticatedExtendedCard field is set to true, authenticated clients can request a more detailed version — revealing additional skills, more specific descriptions, or capabilities that are only available to authorized users.

This is a smart design choice for enterprise environments where agents might offer different service tiers or restrict sensitive operations to verified partners.

The Registry Gap: Discovery's Unsolved Problem

Here's the critical gap in the A2A architecture: the protocol defines the card, but not the phone book.

The well-known URL mechanism only works if a client agent already knows the domain of the agent it wants to talk to. That's fine for pre-configured, point-to-point integrations. But what about the scenarios that would make agent interoperability truly transformative?

• A procurement agent needs to find all available vendor agents that can supply a specific component — without knowing which vendors even have agents.
• A customer support agent needs to discover the best logistics agent to handle a shipping inquiry — across multiple providers it has never interacted with before.
• A developer wants to browse available agents by category, skill, pricing model, or protocol support to find the right one for their project.

None of these scenarios work with well-known URLs alone. They all require a registry — a centralized or federated directory where agents can publish their cards and other agents (or humans) can search, filter, and discover them.

The A2A project on GitHub acknowledges that registries are a valid discovery mechanism but deliberately leaves the registry layer undefined. This is intentional — the protocol focuses on the wire format and lets the ecosystem build the infrastructure. But it means the most valuable form of discovery — open-ended search — still has no standard implementation.

Why This Matters for Businesses

If you're a business owner or technical leader evaluating AI agents, A2A has direct implications for your strategy — even if you never read a line of the spec.

Interoperability without custom integration

A2A-compliant agents can work together out of the box. Instead of paying for custom middleware every time you add a new agent to your stack, you get plug-and-play collaboration. Your HR agent can delegate benefits questions to an insurance provider's agent. Your sales agent can hand off qualified leads to your onboarding agent. The Agent Card is the contract that makes it work.

Avoiding vendor lock-in

When agents communicate through an open protocol, switching vendors becomes dramatically easier. If your current customer support agent isn't performing, you can swap it for a competing product that publishes the same A2A-compliant card — and every other agent in your stack keeps working without reconfiguration.

Future-proofing your investment

The agent ecosystem is still early. Vendors will rise and fall. Frameworks will evolve. But the need for agents to communicate with each other will only increase. Choosing A2A-aware agents today means you're building on a foundation that's designed for the multi-agent future, rather than betting on a single vendor's proprietary ecosystem.

Security and trust at the protocol level

A2A embeds security into the discovery process itself. Agent Cards declare their authentication requirements upfront — OAuth2 scopes, API key schemes, OpenID Connect configurations — so client agents know exactly what credentials are needed before initiating contact. This is a significant improvement over ad-hoc API integrations where authentication requirements are discovered through documentation or (worse) trial and error.

Where Agentry Fits: Building the Registry Layer

The A2A protocol gives agents the ability to describe themselves. Agentry gives them a place to be found.

We're building the registry layer that A2A's architecture needs but doesn't provide. The Agentry Directory is a protocol-aware catalog where AI agents are indexed by their capabilities, skills, categories, authentication methods, and compliance certifications. Every listing includes structured data that maps directly to the A2A Agent Card schema — so programmatic discovery is possible, not just human browsing.

Here's what that means in practice:

• For businesses — Instead of hunting for agents across dozens of vendor websites, you can search the Agentry directory by use case ("customer support agents that handle refunds"), by protocol support ("A2A-compliant with OAuth2"), or by category. Our Get Matched service adds human curation on top of programmatic search.
• For developers — Register your A2A-compliant agent in the directory and it becomes discoverable by every client agent that queries our registry. We're building toward a future where a client agent can query Agentry's API, receive a list of matching Agent Cards, and initiate collaboration — all without human intervention.
• For the ecosystem — A2A defines the grammar. Agentry provides the dictionary. Together, they make open-ended agent discovery a reality rather than a specification footnote.

The A2A protocol is still evolving — with active development on GitHub and growing adoption across the industry. Whether you're building agents, buying agents, or planning your AI strategy, understanding how discovery works (and where it falls short) will help you make better decisions today and position yourself for what's coming next.