agent to agent protocol explained

agent to agent protocol explained

It started with two LLMs that couldn't stop arguing. Not about philosophy or politics. About a schema mismatch.

I'm in October 2025, sitting in a client's office in Pune. They've built a fraud detection agent that needs to pull transaction data from a risk scoring agent. Both are "production grade." Both cost real money to run. Neither can talk to the other without a custom adapter that breaks every time someone updates their internal API.

That's the problem agent to agent protocol explained really is about. It's not about making agents chat. It's about making them interoperable without a Frankenstein of glue code.

So let me define it clearly.

An agent-to-agent protocol is a standardized contract that defines how autonomous software agents discover each other, negotiate capabilities, share context, and execute tasks across organizational boundaries. It's the difference between two people shouting in a crowded room and two people exchanging business cards before having a meeting.

The A2A protocol (Agent2Agent) from the Linux Foundation is the current frontrunner. Google donated it in June 2025, and it's already at version 0.3 as of last month. It's not a toy. It's not vaporware. It's in production at companies like SAP and Salesforce.

But here's the contrarian take most people won't say out loud: the protocol wars are over before they started. MCP won for agent-to-tool communication. A2A is winning for agent-to-agent communication. They're not competitors. They're layers.

Let me show you what I mean.

---

What A2A actually does (and doesn't do)

A2A is not a data format. It's not an API framework. It's a pattern for how agents expose themselves as "cards" that other agents can read and trust.

The core components:

• Agent Card - A JSON document that describes what an agent can do, its authentication requirements, and its endpoints
• Capability negotiation - Agents declare what tasks they can handle, not how they handle them
• Structured task execution - Tasks have states (submitted, working, input-required, completed, failed) that both sides track
• Context management - A shared thread of conversation that maintains state across multi-turn interactions

Here's what an Agent Card looks like in practice:

json
{
  "name": "risk-scorer-v2",
  "description": "Scores transaction risk on a 0-100 scale",
  "url": "https://risk.internal.sivaro.in/a2a",
  "capabilities": {
    "tasks": {
      "streaming": true,
      "pushNotifications": true,
      "stateTransitionHistory": true
    }
  },
  "security": {
    "authentication": "oauth2",
    "scopes": ["risk:read", "transactions:write"]
  },
  "skills": [
    {
      "id": "score_transaction",
      "name": "Score Transaction",
      "description": "Accepts transaction JSON, returns risk score",
      "inputModes": ["application/json"],
      "outputModes": ["application/json"],
      "maxRequestsPerMinute": 100
    }
  ]
}

That's it. That's the discovery layer. An agent fetches this, understands what the other agent can do, and starts a task.

The actual task execution uses JSON-RPC. Simple, boring, reliable. You POST a task, you get task status back, you poll or receive notifications. The protocol handles the lifecycle so you don't have to build your own state machine.

---

A2A vs MCP for enterprise AI agents

I keep seeing LinkedIn posts that frame this as an either/or. It's not. Stop treating it like a cage match.

MCP (Model Context Protocol) solves the problem of agents talking to tools. Your agent needs to query a database, call a REST API, read a file. MCP standardizes that.

A2A solves the problem of agents talking to other agents. Your agent needs to delegate a task to a specialized system that has its own data, its own models, its own governance.

They operate at different layers of the stack.

MCP is like USB. It standardizes how you plug a device into a computer. A2A is like the network protocol that lets two computers talk to each other over the internet. You need both.

Concern	MCP (Agent-to-Tool)	A2A (Agent-to-Agent)
Discovery	Tools have schemas	Agents have Agent Cards
Authentication	Per-tool credentials	Per-agent OAuth scopes
State management	Stateless calls	Task lifecycle tracking
Governance	What the tool allows	Negotiated between agents
Use case	Single AI worker	Multi-agent orchestration

I've tested this in production. We built a procurement system in Q2 2026 that uses MCP for the internal tools (inventory DB, supplier APIs, invoice processor) and A2A for the external agents (credit check, regulatory compliance, logistics optimization).

The MCP layer handles 200K+ tool calls per day. The A2A layer handles about 4,000 agent-to-agent task negotiations. Different volumes, different failure modes, different performance profiles. You can't swap one for the other.

Most people think you choose one. You don't. You architect both.

---

How to implement A2A in your system

Let me walk you through what I'd do tomorrow if you're building a multi-agent system today. This isn't theory. This is what we've shipped at SIVARO.

Step 1: Define your agent boundaries

Don't start with protocol. Start with architecture.

Draw a diagram of your agents. Ask yourself: which of these are truly independent (different ownership, different data, different failure domains) and which are just functions masquerading as agents?

If agent B can't function without agent A, they're not agents. They're one system split into two for code clarity. Don't put A2A between them.

A2A protocol for agent communication matters only when you have genuinely autonomous systems that need to collaborate without tight coupling.

Step 2: Expose an A2A endpoint

Here's a minimal FastAPI implementation that exposes an A2A-compatible endpoint:

python
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import Dict, Any, Optional

app = FastAPI()

AGENT_CARD = {
    "name": "risk-scorer-v2",
    "description": "Scores transaction risk on a 0-100 scale",
    "url": "https://risk.internal.sivaro.in/a2a",
    "capabilities": {
        "tasks": {
            "streaming": True,
            "pushNotifications": False,
            "stateTransitionHistory": True
        }
    },
    "security": {
        "authentication": "oauth2",
        "scopes": ["risk:read"]
    },
    "skills": [
        {
            "id": "score_transaction",
            "name": "Score Transaction",
            "description": "Accepts transaction JSON, returns risk score",
            "inputModes": ["application/json"],
            "outputModes": ["application/json"]
        }
    ]
}

class TaskMessage(BaseModel):
    task_id: str
    message: Dict[str, Any]

class Task(BaseModel):
    id: str
    status: str
    skill_id: Optional[str] = None
    input: Optional[Dict[str, Any]] = None
    artifacts: list = []
    
@app.get("/.well-known/agent-card")
async def get_agent_card():
    return AGENT_CARD

@app.post("/a2a/tasks")
async def create_task(task: Task):
    # Validate the task against your skill definitions
    return {"task_id": "task_" + str(uuid.uuid4()), "status": "working"}

@app.get("/a2a/tasks/{task_id}")
async def get_task_status(task_id: str):
    # Return task state
    return {"task_id": task_id, "status": "completed", "artifacts": [...]}

That's the skeleton. The protocol doesn't care about your internal implementation. It cares about the contract you expose.

Step 3: Handle the authentication properly

This is where most implementations fail. They treat A2A as if it's HTTP with a shared secret.

It's not. You need real OAuth 2.0 with scopes. Let me explain why with a story.

In March 2026, I consulted for a fintech in Bengaluru. They had 14 agents running. Every single one shared a single API key that was hardcoded in a config file. When one agent got compromised through a prompt injection vulnerability, all 14 were exposed.

A2A without per-agent OAuth scopes is just a fancier version of that disaster.

python
# Proper OAuth flow for A2A
# 1. Agent A requests an access token from the authorization server
# 2. Token includes scopes: ["risk:read", "transaction:score"]
# 3. Agent B validates the token against its resource server
# 4. Token expiry, refresh, and revocation handled via standard OAuth

# Example token exchange (simplified)
POST https://auth.sivaro.in/oauth/token
{
    "grant_type": "client_credentials",
    "client_id": "agent-risk-v2",
    "client_secret": "s3cret",
    "scope": "risk:read transaction:score"
}

Don't skip this. Every agent gets its own identity. No shared keys. You'll thank me when an audit happens.

Step 4: Think about failure modes

Here's the thing nobody tells you about agent-to-agent communication: it's distributed systems. All the hard problems of distributed systems apply.

• What happens when agent B is down?
• What happens when agent B responds but the response is malformed?
• What happens when agent B is slow?
• What happens when the network between them drops mid-task?

A2A defines the protocol, but it doesn't solve these. You need your own timeout policies, retry logic, and circuit breakers.

We use the circuit breaker pattern with these settings: after 3 consecutive failures, open the circuit. Wait 10 seconds. Half-open. If the probe fails, keep it open. This prevents cascading failures across 200 agents.

Step 5: Monitor everything

You can't debug what you can't observe.

We ship every agent with structured logging that includes:

• Task ID (from the A2A protocol)
• Agent ID (the caller)
• Skill ID (what was requested)
• State transitions (submitted → working → completed)
• Latency metrics per transition
• Token usage (if LLMs are involved)

Without this, when something breaks, you're blind. And in production, something always breaks.

---

The practical patterns that work

Fan-out pattern

You have one orchestrator agent that delegates to multiple specialized agents. This works well for tasks like "research this market" where different agents handle different aspects.

python
# Fan-out with A2A
async def orchestrate_research(market: str):
    tasks = []
    agents = ["market-size-agent", "competitor-agent", "regulatory-agent"]
    
    for agent in agents:
        task = await client.submit_task(
            agent_url=f"https://{agent}.sivaro.in/a2a",
            skill_id="research_aspect",
            payload={"market": market, "aspect": agent.split("-")[0]}
        )
        tasks.append(task)
    
    # Wait for all to complete
    results = await asyncio.gather(*[await_completion(t) for t in tasks])
    return synthesize(results)

# In production, use asyncio.gather with timeout and partial failure handling
# Don't just fail everything because one agent timed out

Pipeline pattern

Agent A completes a task, passes its output to Agent B, which feeds Agent C. This is how we built a document processing system that classifies, extracts, and validates in sequence.

The key insight: you need proper backpressure. If Agent C is slower than Agent A, you'll run out of memory. Use bounded queues and apply flow control.

Mediator pattern

A central mediator routes tasks between agents. This works for small systems (under 10 agents). Beyond that, the mediator becomes a bottleneck and a single point of failure.

In our experience, the meditator pattern breaks down beyond 15 agents. The routing logic becomes more complex than the agent logic. The topology becomes unmanageable.

Go with a hybrid: small groups of related agents share a mediator; groups communicate via A2A directly with each other.

---

Security and governance in A2A

The A2A protocol includes a security spec, but it's a framework, not a solution. You still have to decide things yourself.

When we deployed A2A at a government services agency in 2026, we learned some hard lessons:

1. Agent identity is not human identity. An agent might have the right to request data, but you need to track which human initiative that agent is acting on behalf of. Every task should have a correlation ID back to a human decision.

2. Prompt injection via task payloads is a real attack. If Agent A sends data to Agent B that causes Agent B to take unwanted actions, you have a problem. We sanitize all incoming text against prompt injection patterns before it reaches an LLM.

3. Audit trails are non-negotiable. Every agent-to-agent interaction gets logged with a unique task ID, the exact payload, the response, and the state transitions. We retain 400 days minimum.

Here's the authentication flow we use with A2A in production:

json
// A2A task request with mutual TLS
POST https://agent-b.internal.sivaro.in/a2a/tasks
Authorization: Bearer <jwt-with-scopes>
X-Correlation-ID: 8f4e1c9a-2b10-4d65-9a3f-6c41942e7b01
Content-Type: application/json

{
  "id": "task-12345",
  "skillId": "score_transaction",
  "input": {
    "transactionId": "txn_889233",
    "amount": 45000.00,
    "currency": "INR",
    "timestamp": "2026-08-30T10:30:00Z"
  }
}

That correlation ID is crucial. When something goes wrong, you can trace every step backward to the root cause.

---

Performance characteristics you should expect

We've stress-tested A2A implementations across various environments. Here's what you should plan for:

• Agent Card fetch: 2-15ms after initial discovery. Cache aggressively.
• Task submission: 10-50ms depending on network latency and protocol overhead.
• Task completion (CPU-bound): dominated by actual work, not protocol overhead. Protocol adds < 5% overhead.
• Task completion (LLM-heavy): dominated by model inference, protocol negligible.
• Throughput: a single A2A endpoint can handle 50-100 task submissions per second without breaking a sweat.

At SIVARO, we run a multi-agent system processing about 500,000 agent-to-agent tasks daily across two data centers.

The protocol overhead is minimal. You're not going to hit performance issues because of A2A.

---

FAQ: agent to agent protocol explained

Q: Is A2A mature enough for production use?
A: Yes. It's at version 0.3, which might sound early, but the spec is stable and implementations exist from multiple vendors. We've been running it in production since March 2026. The spec team (which includes Google, Cisco, and others) is actively maintaining it through the Linux Foundation.

Q: Does A2A replace my existing API layer?
A: No. A2A is a layer on top of your existing systems. Your internal APIs still exist. A2A exposes them to other agents in a standardized way while hiding internal complexity. Think of it as a facade pattern.

Q: What's the difference between MCP and A2A?
A: MCP is for agents-to-tools. A2A is for agents-to-agents. They're different layers. MCP gives your agent access to databases and APIs. A2A lets two agents negotiate and execute tasks together. Google's announcement clarifies this distinction well.

Q: Can I use A2A for internal agents within my company?
A: Yes, and I recommend it. Even within a single organization, agents often have different teams, data, and deployment cycles. Standardizing communication prevents tight coupling.

Q: What about Claude or OpenAI agents? Do they support A2A?
A: As of today, none of the major model providers have native A2A support built into their API interfaces. But it doesn't matter. You wrap their capabilities in your own A2A adapter layer. That's the point of the standard.

Q: What security considerations should I account for?
A: Use OAuth 2.0 with scopes. Never share API keys. Always use correlation IDs. Log everything.

Where agent to agent protocol explained is heading

I've spent the last two years building systems on the assumption that multi-agent is the future. Here's what I believe comes next:

Skill-based marketplaces

When agents can advertise capabilities via Agent Cards, you'll see marketplaces where agents pay other agents for specialized services. Already, Google's Antigravity platform is making it easier to publish and consume agent capabilities.

Standardized reputation

We need a way to evaluate how reliable an agent is. The protocol doesn't define reputation, but it should. I expect to see third-party reputation services that track task completion rates, latency, and error rates. Like credit scores for agents.

Legal frameworks

When Agent A hires Agent B to do work based on Agent C's output, and something goes wrong, who's liable? This gets complicated fast. Some of this will be solved by regulation, but the technical community needs to build in auditability from the start.

---

The hard truth about A2A

Right now, the most common situation I see: AI agents that work beautifully in isolation but fail when they need to cooperate. Companies spend months building integrations that break every time an internal API changes.

That's exactly the problem NISHAANT DIXIT and teams like SIVARO solve with the A2A protocol. But here's the key: A2A doesn't make multi-agent systems easy. It just removes the connection overhead. The hard work of designing agents that can actually work together, handle failures, and respect security boundaries is still on you.

You still need to actually think.

The agent-to-agent protocol is the equivalent of laying down standard rails in the Wild West. It gives you the track. You still need to build the locomotive.

So start experimenting now. Get an Agent Card live, connect it to a test client, and see what breaks. Because the sooner you fail, the sooner you learn how to build the real thing.

---

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