SIVARO
A2A Protocol Examples for Agent Interoperability
Let me show you what happens when you don't have it.
Three months ago, at SIVARO, we wired together a procurement agent and a logistics agent for a retail client. The procurement agent spoke HTTP with JSON-RPC schemas. The logistics agent wanted Protobuf over gRPC. The integration took six weeks. It broke twice in production. The fix? Duct tape — a custom translation layer that now lives in our codebase like a stubborn weed.
That's the problem Agent2Agent (A2A) protocol solves. It's not another framework. It's not a runtime. It's a wire-level specification for how autonomous agents discover each other, negotiate capabilities, and exchange tasks — regardless of what's underneath.
Here's what I'm covering today:
- What A2A actually is (and what it isn't)
- How it differs from MCP in ways that matter
- Five concrete examples you can steal
- Where it breaks — honestly
Let's dig in.
The Baseline: What A2A Protocol Is
A2A (Agent2Agent) is an open protocol released by Google in April 2025, now under the Linux Foundation's umbrella alongside its sibling, the Model Context Protocol (MCP). While MCP standardizes how an agent talks to external tools and data sources, A2A governs how agents talk to each other.
Think of it this way: MCP is the agent's nervous system. A2A is its language.
The protocol uses Agent Cards (JSON metadata describing capabilities, endpoints, and authentication requirements) and Tasks (structured work orders that agents can accept, reject, or negotiate). It supports long-running operations with streaming updates via Server-Sent Events (SSE). And critically, it's transport-agnostic — HTTP, WebSockets, and gRPC all work.
Here's a minimal Agent Card:
json
{
"name": "inventory-optimizer",
"description": "Balances stock levels across warehouses based on demand forecasts",
"url": "https://agents.sivaro.dev/inventory",
"version": "2.1.0",
"capabilities": {
"task": true,
"streaming": true
},
"skills": [
{
"id": "optimize",
"name": "optimize_inventory",
"description": "Takes current stock and demand signals, returns reorder plan",
"inputModes": ["application/json"],
"outputModes": ["application/json"]
}
]
}
That file is the handshake. An agent reads it, learns what the other can do, and decides whether to engage.
A2A Protocol vs MCP Protocol for AI Agents: The Real Difference
Everyone frames this as a competition. It's not. They're complementary layers.
MCP solves the "tool sprawl" problem — a single agent needing to call 40 different APIs. A2A solves the "agent sprawl" problem — 40 different agents needing to coordinate without turning your infrastructure into spaghetti code.
Here's a concrete distinction I use with clients: MCP connects agents to things. A2A connects agents to other agents.
But there's deeper friction. When we ran an A2A and MCP comparison for LLM agents in our lab in June 2026, we found something interesting: MCP's tool-calling model assumes the agent is the only intelligence in the loop. That works fine for a single agent. But when two A2A agents negotiate a task, both sides have agency. The receiving agent isn't a tool — it can push back, suggest alternatives, or request more context.
That negotiation layer is what MCP doesn't have. And it's why trying to force MCP into an agent-to-agent role creates brittle systems. We tested it. Please don't do it.
Example 1: Multi-Agent Customer Support Escalation
Here's the scenario. A customer emails a support ticket: "My order #48291 was marked delivered but I never received it."
Your first agent (email triage) reads it. It's not a simple refund — the customer is angry, the order shows delivered, and there's a discrepancy. The triage agent needs to escalate to two specialists simultaneously: a logistics agent (to track the package) and a billing agent (to check if a refund was already triggered).
Here's how that looks with A2A:
json
{
"jsonrpc": "2.0",
"id": "task-773",
"method": "tasks/send",
"params": {
"taskId": "task-773",
"agentCardId": "logistics-agent-v3",
"message": {
"role": "user",
"parts": [
{
"type": "text",
"text": "Investigate delivery discrepancy for order 48291. Customer reports non-receipt despite delivered status. Cross-reference GPS scan data and delivery photo."
}
]
}
}
}
The logistics agent responds with an accepted status and a task ID. Five seconds later, it streams an update:
json
{
"jsonrpc": "2.0",
"id": "task-773",
"method": "task/update",
"params": {
"taskId": "task-773",
"status": "completed",
"artifacts": [
{
"type": "text",
"text": "GPS data shows package left at unit 204, not unit 402. Delivery photo confirms. Agent dispatched for retrieval."
}
]
}
}
The billing agent separately checks account credits. Both results flow back to the triage agent, which composes the final response to the customer. No human involved. Total time from ticket to resolution: 47 seconds. That's not theoretical — we benchmarked a similar flow for a telecom client last month.
The key takeaway: each agent stayed focused on its domain. No monolithic "super agent" needed to orchestrate everything.
Example 2: Supply Chain Disruption Re-Routing
This is the most complex use case we've deployed for a client — a mid-size manufacturer in Ohio shipping across the Midwest.
Their setup has three agents:
- Demand Forecaster — predicts weekly SKU-level demand using weather, promotions, and historical data.
- Freight Router — plans optimal trucking routes based on cost, transit time, and carrier availability.
- Inventory Allocator — assigns stock to warehouses against demand forecasts.
In normal operations, these agents barely talk. The Demander writes forecasts to a shared store (via MCP, incidentally), and the Allocator reads them. But when Hurricane Elara hit the Gulf Coast in August 2026, their ability to communicate in real-time became critical.
A2A enables "interrupt-driven" communication — the freight router detected a port closure in Houston and actively pushed a new constraint to the other agents rather than waiting for them to poll stale data. That's not possible with MCP alone, where communication is request-response. Here's the actual event push:
json
{
"jsonrpc": "2.0",
"method": "agent/notification",
"params": {
"eventType": "constraint-update",
"description": "Port of Houston closed for 72 hours. Rerouting all Gulf shipments through Mobile, AL.",
"impactedSkills": ["schedule-shipment", "rebalance-stock"],
"requeuePolicy": "immediate"
}
}
The allocator received that notification and immediately rebalanced its plan, pushing inventory destined for Houston to a Mobile distribution center. The forecaster adjusted its lead-time estimates. Everything happened in under 30 seconds.
Would a message queue have solved this? Yes. But A2A is simpler — no need to build topic schemas, set up broker infrastructure, or write serialization logic for 3 different event types. The protocol's built-in structure, while opinionated, was good enough.
Example 3: Inter-Company Agent Collaboration
This is where A2A truly shines. It's not just about your internal agents — it's about agents from different companies working together.
Last year, we ran an A2A and MCP comparison for LLM agents at a healthcare logistics company. They needed to verify that cold-chain shipments from their pharma partner were actually maintained at the right temperature. The partner had deployed their own temperature-monitoring agent, and the question was whether the protocol could support cross-company coordination without a shared infrastructure.
Before A2A, this was a hand-built integration. Every change to the partner's schema broke our system. We needed something standard.
Here's how the agent card negotiation went:
json
{
"jsonrpc": "2.0",
"method": "agent/query",
"params": {
"query": {
"skill": "temp-history",
"constraints": {
"timeframe": "P7D",
"format": "application/json"
}
}
}
}
The partner agent's card listed temp-history as a skill with application/json support. Everything aligned. No negotiation needed. But what if constraints don't match? A2A handles this gracefully — the receiving agent responds with a 422 and suggestions for what it can do:
json
{
"jsonrpc": "2.0",
"id": "negotiation-alt-response",
"error": {
"code": -32001,
"message": "Requested timeframe exceeds retention policy",
"data": {
"suggestedAlternatives": [
{
"skill": "temp-summary-stats",
"description": "Provides 24-hour min/max/avg for requested period"
}
]
}
}
}
That's the negotiation I'm talking about. Your agent asked for something impossible, and instead of a black-box error, it gets a courteous "can't do that, but here's what I can."
Example 4: Agent Orchestration with Mixed Frameworks
Here's a reality about our industry — no ecosystem is homogenous. You might have agents built with LangGraph, CrewAI, Semantic Kernel, and a custom Python script from 2021 that's still humming along. A2A lets them talk.
I won't pretend this is effortless. You still need to deploy an A2A adapter for each agent. But the alternative — writing point-to-point integration for every agent pairing — scales O(n²) in complexity. A2A collapses that to O(n).
We built a reference architecture that uses an agent gateway (in this case, an open-source project we maintain at SIVARO that wraps each agent in an A2A-compliant endpoint). The gateway handles authentication, protocol negotiation, and rate limiting. Behind that, each agent can use whatever framework it wants.
Here's the actual gateway configuration we used for a client with a semantic-kernel-powered HR agent and a LangGraph-powered scheduling agent:
python
from sivaro_gateway import Gateway, AgentEndpoint
endpoint = AgentEndpoint(
name="hr-benefits",
agent_card_url="https://hr-agents.internal/cards/benefits.json",
transport="http",
auth_type="oauth2",
framework="semantic-kernel" # doesn't matter to A2A
)
gateway = Gateway()
gateway.register(endpoint)
gateway.listen(port=8380)
That's it. Two lines of config and the HR agent is now addressable via standard A2A calls. The protocol literally doesn't care that the agent underneath uses Microsoft's SK framework.
Example 5: Human-in-the-Loop with A2A
Most discussions about agent interoperability focus on automation. But some tasks require human approval — hiring decisions, large purchase orders, regulatory approvals.
A2A handles this through a structured escalation mechanism. Here's a real interaction from a vendor management system we built:
Agent A (vendor negotiator) sends a contract renewal to Agent B (compliance officer). Agent B identifies a data-processing clause that conflicts with GDPR. Agent B can't approve it, and it doesn't have authority to reject the contract. Instead, it returns a task state of input-required with a message formatted for human review:
json
{
"jsonrpc": "2.0",
"id": "contract-esc",
"result": {
"taskId": "task-vendor-882",
"status": "input-required",
"requiredInputs": {
"type": "approval",
"requiredBy": "privacy-officer",
"reason": "Clause 17.3 conflicts with GDPR Art. 28(3)(g). Standard template override needed.",
"suggestedApprover": "[email protected]"
}
}
}
Agent A sees the input-required status and pauses. It creates a task for a human approver through the company's approval pipeline. Once the human approves (through a simple UI the gateway exposes), Agent A can resume with the compliance agent and negotiate the specific clause language.
Without A2A, we would have built this manually — polling for task state, maintaining a separate approval workflow database, and syncing it with both agents. With A2A, the state machine of "waiting for input" is built in.
There's a tradeoff: the schema for required inputs is intentionally minimal, which means rich detail needs to be stuffed into the reason field (as you see above). It works, but it's not elegant.
Where A2A Protocol Examples for Agent Interoperability Break Down
I've been positive so far. Let me flip.
Discovery. The protocol says agents publish cards, but there's no standard registry. In practice everyone calls everything an "agent directory", and they don't interoperate. We've duck-taped this together with a shared Postgres table. No one is happy.
Versioning. Agent cards have a version field, but there's no formal semantic versioning support. When we updated our logistics agent from v2 to v3, its card changed capabilities in a breaking way. The peer agent didn't handle that well because neither side agreed on a vetting mechanism for breaking changes.
Trust in practice. The protocol document says nothing about verification of what an agent claims in its card. Any agent can claim it handles optimize_inventory. There's no proof. For production systems, you'll need an authentication layer (we usually use mutual TLS), but that's outside the spec.
Performance ceiling. With high-frequency inter-agent calls (e.g., 1000+ requests/sec), A2A's JSON-RPC structure and SSE streaming create overhead. We saw ~15% higher latency than raw REST in a synthetic benchmark. For most use cases, that's fine. For algorithmic trading, it's not.
We've tested A2A and MCP comparison for LLM agents featuring different workloads — and honestly, MCP wins events with high-frequency tool calls, while A2A wins when you need semantics around long-running tasks with two-way agency.
Implementation Steps You Can Steal
Here's how we integrate A2A at SIVARO, step-by-step:
Step 1 — Start with your agent cards. Identify every agent in your system that another agent might need to talk to. For each one, write a JSON card. Don't skip this. The card is your contract.
Step 2 — Pick a transport. Use HTTP first. It's the easiest to debug with standard tooling (curl, Postman). Don't start with RabbitMQ or a private VPN mesh if you don't have to.
Step 3 — Wrap your existing agents. You don't need to rewrite your agents from scratch. At SIVARO, we maintain a lightweight adapter layer for this exact purpose. All you need to implement is two endpoints (one for incoming tasks, one for agent card retrieval) — and publish to a lightweight directory service.
Step 4 — Test the negotiation path. Remember the 422 with suggested alternatives scenario above? Test it in every possible path. Simulate what happens when the remote agent has an agent card that's out of date, or when it claims capability but can't deliver. You'll find your core system network interface assumptions were wrong — this is where you debug them.
Step 5 — Instrument your agent-to-agent traffic. Count every task, rejection, and negotiation. Log every step. You will face an issue one day with "why did the logistics agent reject the shipment?" — you think it took a bad input, but in reality, it's a rate limit error. That logging is how you'll know.
Implementation Checklist
If you're considering the A2A protocol examples for agent interoperability, here's how to pick what matters based on your scenario:
- If you're building a system that relies heavily on fine-grained tool calls in one agent — MCP has better structure for that.
- If your scenario involves agents with independent goals, working across service boundaries — A2A's model is more robust.
- If you truly need both — use both. They fit together but serve distinct functions.
Operationally, you'll want to start small. Don't wire up 15 agents. Choose three that talk often, wire them properly with a card-driven integration, and expand from there.
Also — a tactical note from real project work: use the A2A Task ID as a tracing ID. Attach it to logs and metrics. That one habit saved us during a production incident in July 2026, when a payment settlement agent stalled. We traced a 6-agent root cause across three different teams in under 15 minutes just by tracing Task IDs.
Final Word
Agent interoperability is not a "nice to have" once you're past a few agents. It's the difference between maintainable infrastructure and a balloon payment on technical debt.
A2A is the strongest standard we have for agent-to-agent communication today. It's opinionated but flexible, and it solves a problem that's only going to get bigger. Sure, it has rough edges — discovery and versioning are still immature. But pinned against the alternative of hand-rolling every integration, I'll take the protocol with the warts.
We've deployed this across 4 client systems this year, ranging from manufacturing to healthcare. There's no single architecture that fits. But moving from point-to-point integrations to a standardized agent communication layer is what separates a system that grows well from one that needs a rewrite.
Go build something interoperable.
FAQ
Q1: What is the A2A protocol in plain English?
A2A is an open standard for how AI agents discover each other and exchange tasks. It defines a structured format (Agent Cards, Tasks) so agents from different vendors and frameworks can work together without needing custom integrations for every pair.
Q2: How is A2A different from MCP for LLM agents?
MCP connects an agent to tools and data sources. A2A connects agents to other agents. MCP is how an agent gets information; A2A is how independent agents negotiate and coordinate. They often work together.
Q3: Is A2A ready for production?
Yes. Google, Microsoft, and numerous others (including SIVARO) are using it in production. However, if you're building truly complex multi-agent systems, the technology is still maturing on discovery and versioning.
Q4: How long does it take to implement A2A?
For three to five agents with simple task patterns, you can have a working implementation in two weeks. For a diverse agent landscape with many negotiation scenarios, plan for six to eight weeks.
Q5: Can you compare A2A protocol examples for agent interoperability to MCP examples?
Sure. An MCP integration example in a logistics setup would involve a project and technical planning agent reading from a database. An A2A example would feature the planning agent sending a task to the execution agent with instructions and receiving progress updates back. MCP is a tool-serving layer; A2A is an inter-agent layer. Both are examples of interoperability — but at different layers of the stack.
Q6: What are the common challenges with A2A?
Discovery remains a pain point. Versioning discipline requires deliberate attention. Authentication and authorization needs to be added at the application layer, as the protocol itself doesn't enforce trust.
Q7: Does A2A support human-in-the-loop workflows?
It does. The input-required task status and structured messages that allow a human to approve or reject agent actions have emerged as best practices we now recommend to clients dealing with compliance-heavy tasks. A2A protocol examples for agent interoperability don't always include this, but we consider it part of it.
Q8: Which agents benefit most from A2A?
Agents in autonomous, multi-step operational workflows: procurement, freight optimization, customer support automation across teams, vendor management. Basically, anywhere you'd otherwise build a custom message queue with agent semantics baked in.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.