The a2a Agent Discovery Protocol: What I Learned Building Multi-Agent Systems in Production

Free Technical Audit

Expert Review

I spent most of 2025 debugging agent handshakes.

Not the protocol kind. The human kind. Watching two AI agents from different vendors refuse to acknowledge each other's existence — like senior engineers in a code review who've decided the other guy's PR is beneath them.

Then Google dropped the Agent2Agent (A2A) protocol in April 2025, and suddenly the conversation shifted. Not because A2A was magic. Because it finally gave us a common language for agents to introduce themselves.

Here's what the a2a agent discovery protocol actually is, how it works, and why I'm now using it alongside MCP in every SIVARO engagement.

What Is the a2a Agent Discovery Protocol?

The a2a agent discovery protocol is the "Agent Card" system that lets AI agents advertise their capabilities, endpoints, and authentication requirements to other agents — and lets those agents query and find each other without hardcoded integrations.

Think of it as DNS for agents.

If MCP (Model Context Protocol) is about giving an agent tools to act on the world, A2A is about letting agents find each other and negotiate how to work together. The discovery mechanism lives in a /.well-known/agent.json endpoint, similar to how /.well-known/ works for OpenID and other web standards.

The flow is deceptively simple:

Agent A requests Agent B's Agent Card
Agent B responds with JSON describing its skills, capabilities, and endpoint URL
Agent A reads the card, determines if Agent B can help, and establishes a connection
Both agents exchange a task lifecycle over HTTP — using either JSON-RPC or raw HTTP POST

That's it. No heavy SDK, no shared runtime. HTTP and JSON.

Why Discovery Matters More Than You Think

Most people think the hard part of multi-agent orchestration is the communication protocol. They're wrong.

The hard part is knowing what agents exist, what they can do, and how to reach them. I've seen two teams at the same company build overlapping agents because neither knew the other existed. The a2a agent discovery protocol solves this by making capability discovery a first-class citizen.

We tested this at SIVARO with a client in the insurance space. They had three separate agent fleets — one for claims triage, one for policy lookup, one for fraud scoring — each built by different teams in different years. Before A2A, integrating these meant writing custom connectors for each pair. After implementing Agent Cards, the claims agent could discover the policy agent's endpoint, read its skillset, and route requests without a single hardcoded integration.

The discovery layer changed how we think about agent architecture. It's no longer "point A to point B." It's "make capabilities queryable and let the orchestration layer figure it out."

The Agent Card: Your Agent's Resume

The core artifact of the a2a agent discovery protocol is the Agent Card. It's a JSON document served from a standard path. Here's what a real one looks like:

json
{
  "name": "SIVARO Claims Processor",
  "description": "Processes insurance claims and extracts structured data",
  "version": "2.4.1",
  "skills": [
    {
      "id": "claim_triage",
      "name": "Claim Triage",
      "description": "Assess claim complexity and route appropriately",
      "tags": ["insurance", "claims", "triage"],
      "examples": ["File has 3 documents and X-ray images"]
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": false,
    "stateTransitionHistory": true
  },
  "security": {
    "auth": "Bearer JWT",
    "context": "https://auth.sivaro.dev/issuer"
  },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["application/json"],
  "url": "https://claims.sivaro.dev/a2a"
}

The skills array is where discovery gets powerful. Each skill has an ID, a description, tags, and examples. Other agents can query this card and match against it semantically.

The security field matters more than people realize. In production, the discovery protocol is where you communicate authentication requirements. Without this, agents will try to connect and fail silently — which I've seen waste hours of debugging time.

Discovery Patterns That Actually Work

There are three patterns I've tested in production. They have very different characteristics.

Direct Discovery

The simplest: agent A hardcodes agent B's Agent Card URL. Works when agents are long-lived and the topology is static. We use this for internal agents at SIVARO that we know will exist for years.

Trade-off: You're still hardcoding endpoints. You just standardize the handshake. It beats raw REST by eliminating "what format do you want?" questions.

Registry-Based Discovery

You run a central service that stores Agent Cards for all your agents. New agents register on boot, and queries filter by skill tags.

This is what I recommend for most organizations with more than 10 agents. We built one for a retail client using Redis + a thin Go service. It handles about 50 agents without breaking a sweat. The query pattern looks like this:

json
POST /v1/query
{
  "query": {
    "skills": {
      "tags": ["fraud", "scoring"]
    },
    "version": ">=2.0.0"
  }
}

The response returns matching Agent Cards, and the querying agent can then decide which to connect to. This is where the a2a agent discovery protocol shines — you're searching by capability, not by endpoint.

Peer-to-Peer Gossip Discovery

For decentralized setups, agents share knowledge of other agents they've discovered. This is clever but hard to debug. I've seen it work at a fintech with geographically distributed agents that can't always reach a central registry.

Honestly? Unless you have a specific reason, skip this. Registry-based is simpler to audit, and security teams like knowing where the cards live.

a2a and MCP for Multi-Agent Orchestration: How They Fit

This is where most people get confused. I was confused. It took building three production systems before the relationship clicked.

MCP solves the "how does an agent use tools" problem. It standardizes tool exposure so any MCP-compatible agent can call functions exposed by an MCP server. You define tools, the agent calls them, results come back as structured data.

A2A solves the "how do agents talk to each other" problem. It standardizes agent-to-agent communication — including discovery, task delegation, and state tracking. It's not about tools. It's about collaboration.

For a2a and MCP for multi-agent orchestration, the practical pattern is:

Use MCP for the agent's interaction with tools and data sources
Use A2A for the agent's interaction with other agents
Implement an "agent gateway" that exposes your agent's tools via MCP to other agents

I think of MCP as the agent's hands and A2A as the agent's phone book and contract negotiator. You need both.

The a2a mcp Comparison for AI Agents: When to Choose What

Let me give you the a2a mcp comparison for ai agents that I wish someone had given me 18 months ago.

Concern	Use MCP	Use A2A
Tool discovery (files, APIs, DBs)	Yes	No
Agent capability discovery	No	Yes
Single agent using tools	Yes	No
Multi-agent task delegation	No	Yes
Streaming results to users	Yes	Yes
Authentication between systems	Partial	Yes

The killer test: if your agents are just wrappers around tools, MCP is enough. If you're orchestrating multiple agents that need to collaborate on tasks, you need A2A's discovery layer.

Implementing the Agent Card: A Walkthrough

Let me walk you through deploying an Agent Card for a production service. I'll use a FastAPI service as an example — it's what I reach for when I need something quick but solid.

First, serve the card at the standard path:

python
# main.py
from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI()

AGENT_CARD = {
    "name": "SIVARO Data Enrichment Agent",
    "description": "Enriches raw event data with reference lookups",
    "version": "1.0.0",
    "skills": [
        {
            "id": "enrich_event",
            "name": "Event Enrichment",
            "description": "Takes raw JSON event, returns enriched version",
            "tags": ["data", "enrichment", "events"],
            "examples": ["Event missing customer tier -> returns tier"]
        }
    ],
    "capabilities": {
        "streaming": False,
        "pushNotifications": False,
        "stateTransitionHistory": False
    },
    "security": {
        "auth": "Bearer JWT",
        "context": "https://auth.sivaro.dev/issuer"
    },
    "url": "https://enrich.sivaro.dev/a2a"
}

@app.get("/.well-known/agent.json")
async def agent_card():
    return JSONResponse(content=AGENT_CARD)

Second, implement the task endpoint that the discovery protocol points to:

python
# agent_endpoint.py
from pydantic import BaseModel
from typing import Dict, Any

class TaskRequest(BaseModel):
    id: str
    skillId: str
    input: Dict[str, Any]

class TaskResponse(BaseModel):
    id: str
    status: str  # "completed" | "failed" | "working"
    artifacts: Dict[str, Any]
    error: str | None = None

@app.post("/a2a/process")
async def process_task(request: TaskRequest):
    if request.skillId != "enrich_event":
        return TaskResponse(
            id=request.id,
            status="failed",
            artifacts={},
            error=f"Unknown skill: {request.skillId}"
        )
    
    # Your actual enrichment logic here
    result = enrich(request.input)
    
    return TaskResponse(
        id=request.id,
        status="completed",
        artifacts={"enriched": result}
    )

Third — and this is the step everyone forgets — test discovery before you write any orchestration logic:

bash
curl https://enrich.sivaro.dev/.well-known/agent.json | jq '.skills'

That one command tells you if your agent is findable. I can't tell you how many times I've seen "agent discovery" fail because someone hosted the card at a non-standard path or forgot to set the url field. The a2a agent discovery protocol is strict about /.well-known/agent.json. Don't fight it.

What Actually Breaks in Production

Discovery is easy in a demo. Production is where it gets ugly.

Auth mismatch. The Agent Card says "Bearer JWT", but the actual endpoint accepts API keys. Agents discover the card and connect — only to get 401s. I've seen this cost a fintech an entire release cycle. Standardize on JWT if you're in a security-sensitive industry, or standardize on mTLS if your agents live in the same cluster. Just be consistent.

Version drift. Card says version 1.2.0, actual agent behavior changed in 1.3.0 and the skill semantics shifted. Other agents discover the stale card and misbehave. Our fix: the card endpoint reads from the deployed artifact's metadata, not from a manually-maintained config.

The "skill too broad" trap. Agents advertise skills like "process_data" — technically true, practically useless. When discovery returns 30 agents that can "process data", you haven't solved discovery, you've just moved the problem. Be specific with skills. "process_insurance_claim" beats "process_data" every time because semantic matching becomes possible.

Security Considerations I Learned the Hard Way

In April 2026, we found a vulnerability in a client's agent registration process. Anyone could POST to the registry and register a malicious agent card, pointing the URL to an attacker-controlled server. The main agent system happily delegated tasks to this fake agent and leaked customer PII in the requests.

The lesson? Discovery must be authenticated. At minimum:

json
// registry requires service-to-service auth
Authorization: Bearer <service_token>
Scope: agent:register

Lock down registration. Treat the registry as a security boundary. Discovery data is metadata, but it's metadata about your internal capabilities — don't expose it publicly unless you want the world to know exactly what your agent landscape looks like.

The Current State: A2A in 2026

By August 2026, A2A has stabilized significantly. The spec went through multiple revisions during 2025, and the ecosystem has matured. Google, Microsoft, and AWS have shipped production implementations. I've seen startups adopt it as the default.

But let's be honest about the trade-offs. A2A is HTTP-based, which means it inherits all the latency and reliability issues of distributed HTTP systems. If your agents need sub-100ms turnarounds and you're running 3+ agents in a chain, the network overhead becomes a real bottleneck. We've resorted to running agents in the same pod with local HTTP to keep the round-trips sane.

The a2a agent discovery protocol isn't groundbreaking on its own. It's the boring-but-necessary plumbing that makes agent ecosystems possible. And in a world where LLM providers keep pushing "agents as a service", owning your discovery layer is how you stay portable across vendors. Don't let a single AI provider lock you into their agent orchestration stack. A2A gives you the escape hatch.

FAQ

Is A2A a replacement for MCP?

No. They solve different problems. MCP standardizes tool access for a single agent; A2A standardizes agent-to-agent communication and discovery. You'll likely use both.

How do I secure an Agent Card endpoint?

Serve it over HTTPS, sign it if you're in a high-assurance environment, and only expose it within your network unless you want external agents discovering your capabilities. For cross-organization discovery, use signed cards so agents can verify authenticity.

Is the a2a agent discovery protocol only for large enterprises?

It's most valuable when you have multiple agents that need to find each other. If you're running 2-3 agents that stay static, the overhead might outweigh the benefit. Start with direct discovery, adopt registries as your agent count grows.

Where does the agent card live?

At /.well-known/agent.json relative to your agent's base URL. This is a convention borrowed from other web standards, and the path is mandatory for compliance.

What happens if two agents disagree on version support?

Implement negotiation in your orchestration layer. The Agent Card exposes both version and a capabilities object — use that for capability negotiation before you create a task. If an agent doesn't support what you need, find another or degrade gracefully.

Where This Is Headed

The next 12 months will determine whether A2A becomes the TCP/IP of agent communication or just another protocol in a graveyard of also-rans. I'm betting on it — we've built SIVARO's internal multi-agent system entirely on A2A + MCP, and I haven't regretted that decision once.

Will there be competitors? Always. But A2A has momentum, and in standards, momentum is everything.

This article reflects my views as a practitioner building production AI systems. I've been running agents in production since early 2024, and I've made every mistake described above including the auth one.

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.