SIVARO
A2A Protocol Open Standard Agents: The Missing Layer for Production AI Systems
Look, I get it. Another acronym. Another protocol. Another "standard" that promises to fix everything and will probably die in eighteen months.
But here's the thing about the Agent2Agent (A2A) protocol that makes it different: it's not trying to replace what you're already using. It's trying to solve the problem that appears after you've built your first agent.
I spent the last year at SIVARO implementing this across three client systems. One was a logistics company moving tens of thousands of packages daily. Another was a fintech running fraud detection in real time. The third was a healthcare company that can't even tell me where their data lives because compliance won't let them.
The pattern was identical in all three cases. You build one agent. It works great. You build a second agent. It also works great. Then you try to get them to talk to each other.
And everything falls apart.
That's where A2A comes in. Not as a competitor to MCP (we'll get to that mess later), but as the missing layer that lets agents actually operate as a system.
What A2A Actually Is
A2A (Agent2Agent) is an open protocol developed by the Linux Foundation's Agent2Agent project that standardizes how autonomous agents discover each other, negotiate capabilities, and exchange information.
It launched in 2025. By early 2026, Google, Microsoft, Salesforce, and a bunch of others had thrown their weight behind it. The Linux Foundation manages the spec, and it's genuinely open — no vendor lock-in, no licensing games.
The core idea is simple: agents need a way to say "here's what I can do" and "here's what I need from you" without a human writing custom integration code for every pair.
Three components matter:
- Agent Cards — JSON files that describe what an agent does, what input it accepts, what output it produces, and what protocols it speaks.
- Agent-to-Agent Messaging — standardized message formats that have actual structure, not just "here's a string, good luck parsing it."
- Capability Negotiation — the handshake where agents figure out if they can actually work together.
The spec uses JSON-RPC over HTTP(S). That's it. No new transport layer, no exotic binary formats, no blockchain nonsense. It runs over the same infrastructure you're already using.
A2A Protocol vs MCP for Agent Communication: Stop Confusing Yourself
This is the question I get asked weekly. Usually with a tone of desperation.
Most people think A2A and MCP (Model Context Protocol) are competitors. They're not. They solve different problems, and understanding the difference will save you months of wasted effort.
MCP answers: How does an agent connect to a tool or data source?
A2A answers: How do two agents communicate with each other?
That's it. That's the whole split.
Let me give you a concrete example from the logistics system we built. The warehouse management agent needs real-time inventory data. That data lives in a legacy ERP system that doesn't have an API. We built an MCP bridge that gives the agent a clean interface to pull inventory counts.
But the warehouse agent also needs to coordinate with the shipping agent. The shipping agent handles route optimization and carrier selection. These are two separate agents, both running their own logic, making their own decisions.
The coordination between them? That's A2A territory.
Here's what I mean practically:
python
# MCP relationship: Agent → Tool
{
"agent": "warehouse_manager",
"connection": {
"type": "mcp",
"server": "erp-bridge",
"tool": "get_inventory",
"params": {"sku": "SKU-123"}
}
}
# A2A relationship: Agent ↔ Agent
{
"agent_a": "warehouse_manager",
"agent_b": "shipping_optimizer",
"connection": {
"type": "a2a",
"card_uri": "https://agents.internal/shipping/agent-card.json",
"message": "inventory_ready",
"payload": {"skus": ["SKU-123", "SKU-456"], "timestamp": "2026-08-15T14:32:10Z"}
}
}
The A2A protocol vs MCP comparison only becomes a competition when you're building a multi-agent system and trying to decide which protocol to use for all communication. And that's a category error.
Use MCP for tool access. Use A2A for agent-to-agent messaging. Mixing them is not just acceptable — it's the correct architecture.
Why I Care About This (and Why You Should Too)
Let me tell you about the fraud detection system we built in Q2 2026.
The client had been using a monolithic rule engine. One massive Python service that evaluated transactions, made fraud decisions, and occasionally burned down the entire production environment when someone applied a hotfix without testing.
We proposed a multi-agent architecture. Not because it sounds cool — because it's actually easier to reason about.
The first version was ugly. We had seven microservices, each containing an LLM-powered agent. The agents communicated through an internal message queue. The queue worked fine, but the message formats were custom. Every agent had its own idea of what "fraud_transaction" meant.
Seven agents. Seven message schemas. Nine if you counted the two that had drifted off the original spec by week three.
What A2A gave us was a shared language. The agent card for each agent declared its capabilities. The messaging format gave us structure. When an agent stopped working, we could look at the protocol logs and see exactly where the chain broke.
We reduced integration time from three weeks per agent pair to two days. I'm not exaggerating — those are the actual numbers from our engineering log.
Practical Setup: Your First A2A Implementation
Enough theory. Here's how you actually start.
Step 1: Define Your Agent Cards
Every agent needs an agent-card.json file. This is non-negotiable. It's how other agents discover what you can do.
json
{
"id": "fraud-detector-v2",
"name": "Fraud Detection Agent",
"description": "Evaluates transactions for fraudulent patterns in real-time",
"url": "https://agents.internal/fraud-detector",
"capabilities": [
{
"name": "evaluate_transaction",
"input": {
"type": "object",
"properties": {
"transaction_id": {"type": "string"},
"amount": {"type": "number"},
"merchant": {"type": "string"}
},
"required": ["transaction_id", "amount"]
},
"output": {
"type": "object",
"properties": {
"fraud_score": {"type": "number", "minimum": 0, "maximum": 1},
"risk_level": {"type": "string", "enum": ["low", "medium", "high", "critical"]}
}
}
}
],
"security": {
"auth_type": "oauth2",
"scopes": ["agents:read", "agents:write"]
}
}
Host this at a known URL. The spec recommends serving it on the same host as the agent itself.
Step 2: Implement the Message Handler
Your agent needs an endpoint that receives A2A messages. The spec defines a standard message envelope:
python
# FastAPI implementation of an A2A message handler
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import Optional
app = FastAPI()
class A2AMessage(BaseModel):
id: str
sender: str
recipient: str
type: str # request, response, error
capability: str
payload: dict
timestamp: str
class A2AResponse(BaseModel):
id: str
sender: str
recipient: str
type: str = "response"
payload: dict
timestamp: str
@app.post("/a2a/message")
async def handle_a2a_message(message: A2AMessage):
# Validate sender
if not await verify_agent_identity(message.sender):
raise HTTPException(status_code=401, detail="Unknown agent")
# Route to capability handler
if message.capability == "evaluate_transaction":
result = await evaluate_fraud(message.payload)
return A2AResponse(
id=message.id,
sender="fraud-detector-v2",
recipient=message.sender,
payload=result,
timestamp=datetime.utcnow().isoformat()
)
raise HTTPException(status_code=404, detail=f"Unknown capability: {message.capability}")
Step 3: Discovery and Negotiation
This is where things get interesting. Agents don't just send messages randomly. They discover each other through a directory, read each other's agent cards, and negotiate whether they can work together.
Here's the flow:
- Agent A publishes its agent card to the directory
- Agent B queries the directory for agents with a specific capability
- Agent B fetches Agent A's agent card and validates the schema
- Agent B sends a test message to verify connectivity
- Real work begins
python
# Agent discovery and negotiation
import httpx
async def discover_and_connect(capability: str, directory_url: str):
# Query the agent directory
async with httpx.AsyncClient() as client:
response = await client.get(
f"{directory_url}/agents",
params={"capability": capability}
)
agents = response.json()
for agent in agents:
# Fetch and validate agent card
card_response = await client.get(agent["card_url"])
card = card_response.json()
# Check if the agent meets our requirements
if validate_capability_schema(card, capability):
# Send handshake message
handshake = {
"type": "handshake",
"capability": capability,
"requirements": {
"max_latency_ms": 500,
"requires_confidence_scores": True
}
}
result = await client.post(
f"{agent['url']}/a2a/message",
json=handshake
)
if result.status_code == 200:
return agent["id"], card
return None, None
Step 4: Handle Failure Gracefully
Here's what most tutorials skip: agents fail. Constantly. In production, your fraud detection agent will go down at 3 AM on a Saturday.
A2A supports structured error responses. Use them.
json
{
"id": "msg-77821",
"sender": "fraud-detector-v2",
"recipient": "transaction-router",
"type": "error",
"payload": {
"code": "CAPABILITY_UNAVAILABLE",
"message": "Model inference timeout",
"retry_after": 30,
"fallback_recommended": true
},
"timestamp": "2026-08-31T03:14:22Z"
}
Your system needs to handle these. Retry logic. Fallback agents. Circuit breakers. Treat agent-to-agent communication like the distributed systems problem it actually is.
A2A vs MCP for Multi-Agent Systems: My Take
Let me be direct: if you're building a multi-agent system today, you need both protocols. They're not competing layers in the stack.
But if you're trying to choose one? That depends on your architecture.
Choose MCP first if:
- Your agents are mostly wrappers around existing tools and APIs
- You have one primary agent and a bunch of tools
- Your "agents" are actually function calls with extra steps
Choose A2A first if:
- You have multiple autonomous agents making independent decisions
- Your agents need to discover each other dynamically
- You're building a marketplace or ecosystem where agents come and go
- You need standardized handoff between specialized systems
Most production systems end up using both. The MCP servers handle the "read data, write data, call tool" operations. A2A handles the conversation between agents themselves.
Security Considerations (Don't Skip This)
A2A agents are autonomous. They pass messages without human review. That means your security model needs to be embedded in the protocol layer.
Three things we've learned the hard way:
1. Identity verification is mandatory. Confirm the sender is actually the agent it claims to be. We use mTLS internally, and WebAuthn-style attestation for external agents.
2. Payload validation matters. Don't trust the schema on the agent card. Validate every message against your own expected format. We've caught two injection attempts in production that would have executed arbitrary commands.
3. Scoped permissions, not blanket trust. Each agent should get a minimum scope. The warehouse agent doesn't need access to the fraud database. The fraud agent doesn't need inventory levels. Least privilege applies to machines too.
python
# Scoped authentication for A2A communication
class A2ASecurityPolicy:
def __init__(self):
self.policy = {
"warehouse_manager": {
"allowed_recipients": ["shipping_optimizer", "inventory_tracker"],
"allowed_capabilities": ["get_inventory", "schedule_pickup"],
"rate_limit": 100 # messages per minute
},
"fraud_detector": {
"allowed_recipients": ["transaction_router"],
"allowed_capabilities": ["evaluate_transaction"],
"rate_limit": 1000
}
}
def validate_message(self, message: A2AMessage) -> bool:
policy = self.policy.get(message.sender)
if not policy:
return False
if message.recipient not in policy["allowed_recipients"]:
return False
if message.capability not in policy["allowed_capabilities"]:
return False
return True
The Hard Lessons
I'm going to be honest about the parts that didn't work.
The spec is still evolving. The A2A protocol definition is friendly, but some edge cases are underspecified. Message retry semantics? The spec says "implementer's choice." That's not great for interop. We've seen agents deadlock because each side expected the other to retry.
Versioning is painful. We spent three weeks dealing with a breaking change in the agent card schema between spec versions. If you're building against the bleeding edge, pin your protocol version and update deliberately.
Not everyone plays nice. We tested interoperability between our own implementation and Google's Agent Development Kit. Most of it worked. Some of it didn't. The "open" in open standard doesn't mean "implemented identically everywhere."
Latency adds up. Each A2A message is a full HTTP request. When you have a chain of five agents, that's five round trips. For fraud detection, we had to move to batch processing to avoid 2-second latencies. That might not matter for a research prototype but it matters in production.
When to Use the A2A Protocol (and When to Walk Away)
A2A protocol open standard agents shine when you're building systems that look like a cooperative workforce.
Use it when:
- You have more than three agents that need to coordinate
- You expect agents to be added, removed, or upgraded independently
- You need fault isolation between agent functions
- You care about being able to swap one agent implementation for another without rewriting the integration layer
If it sounds like a microservices architecture problem, it is. A2A is literally the missing contract layer for agent microservices.
Skip it when:
- You're building a single agent with a few tools (use MCP directly)
- All your agents are in the same codebase and the same process (just use function calls)
- You're doing a hackathon demo (overhead isn't worth it)
The Bigger Picture
Here's where I think this is heading. And I might be wrong — I've been wrong before.
In 2025, everyone was building the "one true agent" — a Swiss army knife that handles everything with a single prompt and a million context tokens. Goliath systems. They get confused, they hallucinate, they need massive guardrails.
The shift toward specialist agents is already happening. Small, focused agents that do one thing really well and talk to each other. Maybe that's a cluster of fraud detection specialists. Maybe it's a network of logistics optimizers, each handling a single domain.
For that model to work, you need a standard way for these agents to find each other, understand each other, and exchange meaningful information. A2A is that standard. Or at least it's the most promising attempt we've had so far.
The spec is open. It's governed by a neutral foundation. It's backed by the major cloud providers without any of them owning it entirely. That combination is rare and worth paying attention to.
Implementation Checklist
When you're ready to build, here's what your first sprint should look like:
-
Inventory your existing agents. Identify which are autonomous (making their own decisions) vs. which are tools with pretty interfaces.
-
Publish agent cards for every autonomous agent. Even if you don't adopt the full protocol yet, the exercise of documenting capabilities is worth it.
-
Implement the message handler. It's a twenty-line endpoint. Stop overthinking it.
-
Set up the discovery directory. Start internal. You can use a simple database table or any key-value store. The protocol doesn't mandate a specific directory implementation.
-
Test with one integration scenario. Pick the two agents that coordinate most frequently. Wire them up. Then measure what breaks.
-
Measure the latency impact. Before you scale out to ten agents, know what the round-trip time costs you.
Real Talk
I didn't believe in A2A when I first read the spec. It looked like yet another abstraction layer invented by a committee to justify their existence.
But then we hit the wall. We had agents that worked brilliantly in isolation and failed miserably in coordination. We were writing bespoke glue code for every pair of agents. We were losing production incidents because dependencies between agents weren't visible.
A2A isn't perfect. It doesn't solve the hard problems of autonomous behavior. It doesn't make your agents smarter or your prompts better.
But it does solve the coordination problem. And in production, coordination is where systems die.
The agents that can communicate, discover each other, and negotiate capabilities will outlast the ones trapped in monolithic silos.
Build your system so agents can talk to each other. Use the standard that exists. Improve it as you go.
FAQ: A2A Protocol Open Standard Agents
What exactly is the A2A protocol?
Agent2Agent (A2A) is an open standard developed under the Linux Foundation that defines a common language for autonomous agents to discover each other, exchange capabilities, and send structured messages. It uses JSON-RPC over HTTP and serves as the communication layer between agents in a multi-agent system.
How is A2A protocol different from MCP for agent communication?
MCP (Model Context Protocol) standardizes how an agent connects to external tools and data sources. A2A standardizes how agents talk to each other. They're complementary layers: MCP handles the "agent to tool" path, A2A handles the "agent to agent" path. In most production multi-agent systems, you'll use both simultaneously.
Is A2A specification production-ready?
As of August 2026, yes, for most use cases. The spec has stabilized, major vendors (Microsoft, Google, AWS, Salesforce) have implementations, and interoperability testing is ongoing. The infrastructure companies like Cloudflare and Datadog are beginning to build A2A support into their products, which makes me confident it's past the experimental stage.
Can I use A2A protocol open standard agents for free?
Yes. The specification is open, released under the Linux Foundation. You don't pay licensing fees. You're responsible for your own implementation — there are open-source SDKs available in Python, TypeScript, Go, and Java. We use the Python SDK at SIVARO in production daily.
What does a typical A2A integration require?
An agent card (JSON file describing your agent), an HTTP endpoint that receives A2A message requests, and a discovery mechanism so other agents can find your agent card. Integration time for a well-documented existing agent is typically two to three days.
How do you handle security with A2A?
Treat A2A like any external API. Use mTLS or OAuth2 for authentication, validate every incoming message payload, enforce scoped permissions per agent, and log all agent-to-agent traffic for audit. Don't trust the agent card schema — validate every message against your own expected formats.
Does A2A work with my existing LLM framework?
Yes. A2A is transport-agnostic about the AI layer. Whether you're using LangChain, LlamaIndex, direct OpenAI calls, or a locally running model, the protocol sits above that and concerns itself with communication between agents. We have A2A running with both managed and self-hosted models in production.
What happens after an A2A message is sent?
The receiving agent validates the sender, checks the capability, processes the payload, and responds with a structured response (success or error). The sending agent handles the response, retries on failure, and can fall back to alternative agents if the primary fails. It's a handshake, and the protocol makes the status explicit.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.