What Is an Example of A2A? A Practitioner's Guide to Agent-to-Agent Communication
You're staring at a dashboard. Two AI agents are supposed to be talking to each other. One is supposed to query a database. The other is supposed to format a response. Instead, they're both stuck in a loop, each waiting for the other to "confirm intent." Sound familiar?
I've been there. More times than I want to admit.
Let me cut through the noise. A2A stands for Agent-to-Agent communication. It's the protocol—or set of protocols—that lets one AI agent talk to another, share context, delegate tasks, and coordinate. You've probably heard the hype. "Autonomous agent swarms." "Multi-agent orchestration." Most of it is vaporware. But the core problem is real: how do you get two agents to work together without breaking everything?
Here's the thing. Most people assume A2A is about APIs. It's not. APIs are for machines. A2A is for agents—systems that can reason, adapt, and change their behavior mid-task. That changes everything.
In this guide, I'll walk you through a concrete example of A2A. Not a toy demo. A real system we built at SIVARO for a logistics client in 2024. You'll see the code, the failures, and the hard trade-offs. By the end, you'll know exactly what an example of A2A looks like in production.
I'll cover:
- The actual architecture (with numbers, not metaphors)
- The protocol choices that worked and the ones that didn't
- Code examples you can adapt
- The gotchas that documentation never tells you
Let's start with the problem.
Why Most A2A Examples Are Lies
I spent three months in late 2023 reading papers on multi-agent systems. Every demo showed two agents flawlessly handing off data. Clean JSON schemas. Perfect error handling. Zero latency.
Then I tried to build one.
First problem: agents hallucinate their responses to each other. Agent A sends a query in JSON. Agent B parses it, adds a typo, and sends back garbage. No schema validation catches it because Agent B "thought" it was being helpful.
Second problem: agents argue. I watched two agents spend 47 seconds debating whether a timestamp should be in UTC or EST. They both had good reasons. Neither could resolve it because neither had a broader context.
Third problem: agents forget context mid-conversation. I saw an agent lose track of a 3-step workflow because it "thought" the other agent had completed step 2. It hadn't.
So when someone asks me "what is an example of a2a?", I don't point to a paper. I point to something that ran in production, handling real traffic, with actual error recovery.
Here's that example.
The Production Example: Logistics Route Optimization
In April 2024, a freight brokerage client came to us. They had 3,000 daily shipments needing real-time routing. Their existing system used a single monolithic agent that did everything: query routes, check weather, optimize costs, and notify drivers.
It was slow. Avg response time: 12 seconds. Error rate: 8%.
They needed to split the work across specialized agents. That's where A2A came in.
The Architecture
We built four agents:
- RoutePlanner — queries map APIs, generates candidate routes
- WeatherChecker — checks weather models, flags hazards
- CostOptimizer — calculates fuel, tolls, driver hours
- Dispatcher — coordinates the other three, handles driver notification
Key design decision: No agent talks to any other agent directly. All communication goes through a central message bus. Not because it's elegant—because it makes debugging possible.
Here's the actual protocol we used:
json
{
"protocol": "a2a-sivaro-v1",
"sender": "RoutePlanner",
"receiver": "Dispatcher",
"message_type": "route_proposal",
"payload": {
"route_id": "r-20240415-8842",
"waypoints": ["Chicago, IL", "Denver, CO", "Salt Lake City, UT"],
"estimated_hours": 28.5,
"confidence_score": 0.87
},
"context_id": "shipment-sh-4412",
"timestamp": "2024-04-15T14:32:10Z"
}
Notice the context_id. That's the glue. Every agent must include it. If any agent drops it, the message gets rejected. We learned this the hard way after losing 12 shipments because an agent forgot to propagate the context.
The A2A Flow (with Real Numbers)
Step 1: Dispatcher sends a request_routes message to RoutePlanner.
Step 2: RoutePlanner takes 1.2 seconds average to query Google Maps and OpenStreetMap. It returns 3 candidate routes.
Step 3: Dispatcher forwards each route to WeatherChecker AND CostOptimizer in parallel. Not sequentially. That cut total time from 11 seconds to 3.4 seconds.
Step 4: WeatherChecker responds in 0.8 seconds. CostOptimizer takes 2.1 seconds (because it's querying three different fuel price APIs).
Step 5: Dispatcher aggregates results. Selects the route with the best score (cost * 0.6 + safety * 0.4). Sends final route to the driver.
Total end-to-end time: 4.2 seconds. Error rate dropped to 1.2%.
That's the example. But the example isn't the code. It's the decisions.
The Protocol Decision: Why We Didn't Use A2A "Standards"
There are emerging A2A protocols. Google's Agent-to-Agent protocol (A2A, confusingly). Microsoft's multi-agent framework. LangGraph's agent communication layer.
We tested three of them. Here's what happened:
Google's A2A (March 2024 draft): Elegant for simple request-response. Fell apart when we needed to send partial results mid-task. An agent that's still computing can't send a "status update" without violating the request-response contract.
Microsoft's protocol: Over-engineered. Required 47 lines of boilerplate just to send a string. Error handling was good, but the latency overhead was 300ms per message. For high-frequency updates, that's killer.
LangGraph: Best of the bunch. Worked well for linear pipelines. But our system needed a star topology (all agents through a dispatcher), not a chain. We had to fork it.
In the end, we built our own. Simple JSON with three mandatory fields: sender, receiver, context_id. Everything else is optional. We added a protocol_version field for future-proofing but don't enforce it.
The contrarian take: Don't use a standard A2A protocol. Not yet. They're changing too fast. Build your own with the minimum viable schema. You'll rewrite it in 6 months anyway. The standards will stabilize by 2026. Until then, you're prototyping.
Code Example: The Dispatcher Agent
Here's the core of our Dispatcher agent. This is the hardest part to get right.
python
import json
import asyncio
from datetime import datetime
from typing import Dict, Any
class A2ADispatcher:
def __init__(self, agents: Dict[str, 'BaseAgent']):
self.agents = agents
self.active_contexts = {}
self.timeout_seconds = 30.0
async def dispatch(self, message: Dict[str, Any]) -> Dict[str, Any]:
context_id = message.get("context_id")
if not context_id:
raise ValueError("Missing context_id. Rejecting.")
receiver = message.get("receiver")
sender = message.get("sender")
if receiver not in self.agents:
# Fallback: log and reroute to human
self._alert_human_operator(message)
return {"status": "rerouted", "recipient": "human"}
# Validate schema
if not self._validate_message(message):
return {"status": "rejected", "reason": "schema_validation_failed"}
try:
# Timeout handling is critical
result = await asyncio.wait_for(
self.agents[receiver].process(message),
timeout=self.timeout_seconds
)
# Propagate context_id
result["context_id"] = context_id
return result
except asyncio.TimeoutError:
# Agent is stuck. Kill and restart.
self._restart_agent(receiver)
return {"status": "timeout", "agent": receiver, "context_id": context_id}
The timeout handling isn't optional. We saw agents get stuck in infinite loops when they received ambiguous data. Without this, the entire pipeline halts.
Code Example: The WeatherChecker Agent (Specialized)
Each agent is specialized but must follow the same communication contract.
python
import requests
class WeatherChecker(BaseAgent):
def __init__(self, api_key: str):
self.api_key = api_key
self.api_endpoint = "https://api.weather.gov/points"
async def process(self, message: Dict[str, Any]) -> Dict[str, Any]:
if message["message_type"] != "check_weather":
# Wrong message type. Reject explicitly.
return {
"status": "rejected",
"reason": f"Expected check_weather, got {message['message_type']}"
}
waypoints = message["payload"]["waypoints"]
hazards = []
for point in waypoints:
# Real API call with retry logic
try:
response = requests.get(
f"{self.api_endpoint}/{point}/forecast",
headers={"User-Agent": "sivaro-a2a-agent/1.0"}
)
response.raise_for_status()
forecast = response.json()
if self._is_hazardous(forecast):
hazards.append({
"location": point,
"hazard_type": forecast["properties"]["name"],
"severity": "high" if "winter" in forecast["properties"]["detailedForecast"].lower() else "medium"
})
except requests.exceptions.RequestException as e:
# Don't fail the entire workflow for one API failure
hazards.append({
"location": point,
"hazard_type": "unknown",
"severity": "low"
})
return {
"status": "completed",
"payload": {
"route_id": message["payload"]["route_id"],
"hazards": hazards,
"checked_at": datetime.now().isoformat()
}
}
Notice: the WeatherChecker doesn't know anything about CostOptimizer. It doesn't need to. The Dispatcher handles routing. This keeps agents simple—each does one thing well.
The Failure Modes Nobody Talks About
We ran this system for 6 months. Here's what broke:
1. Context drift. Two agents would start arguing about a detail (is a 15-minute delay "significant" or "critical"?). Neither could resolve it because neither had the business rules. We added a "tiebreaker" config in the Dispatcher that overrides agent disagreements. Works 90% of the time.
2. Deadlocks. Agent A waits for Agent B. Agent B waits for Agent A. Neither sends first. We added a heartbeat timeout. If an agent doesn't send a message within 15 seconds, the Dispatcher pings it. No response within 5 more seconds? Force restart.
3. Message flooding. One agent sent 4,000 messages in 3 seconds (it had a bug that kept retrying). We added rate limiting per agent: max 10 messages/second. Beyond that, messages queue and the agent gets throttled.
4. Protocol poisoning. A malicious agent could inject fake messages because we had no authentication. We added a simple HMAC signature per message. It adds 2ms overhead per message—worth it.
The 3 Rules of A2A Communication
After building three different A2A systems, here's what I've landed on:
Rule 1: Every message must carry its own context
Don't rely on session state. Don't rely on the other agent remembering. Each message contains everything needed to process it. Yes, it duplicates data. Yes, it's wasteful. But it prevents context loss when an agent crashes and restarts.
We measured: context duplication adds 12% to message size. Eliminates 90% of context-loss bugs. Worth it.
Rule 2: Agents must be replaceable
Your RoutePlanner agent gets hit by a bus (metaphorically). What happens? If your protocol ties agents to specific implementations, you're stuck. Instead, define interfaces.
python
class RoutePlannerInterface:
async def propose_routes(self, waypoints: List[str]) -> List[Route]:
pass
Any implementation that matches the interface works. We swapped out Google Maps for OpenStreetMap in 2 hours during an outage. The agents didn't care.
Rule 3: Always include a human fallback
Your agents will fail. Not "might fail." Will fail. The question is how gracefully.
We built a "human-in-the-loop" channel. When confidence drops below 0.6 in any agent, the Dispatcher sends a Slack notification. Human reviews it. Human approves or rejects. Then the flow resumes.
In 6 months of production, the human was needed 7 times. That's 7 times the system could have made a wrong decision. Each time, the human caught it.
What Is an Example of A2A? (The Short Answer)
If you want a single, concrete example of A2A:
A freight dispatcher agent asks a weather agent to check conditions along a route. The weather agent responds with hazards. The dispatcher agent uses that info to reroute the delivery. All communication happens via structured messages with context IDs, timeouts, and error recovery.
That's it. No magic. No swarms. Just two programs with enough smarts to coordinate without breaking.
But here's what makes it "A2A" and not just "two APIs talking": the agents can handle ambiguity. If the weather agent can't reach its API, it returns a "low confidence" result instead of crashing. The dispatcher can decide to trust it or wait. That's agency—the ability to adapt to unexpected conditions.
The Future: What I'm Building Next
I'm working on a version where agents can negotiate. Right now, the Dispatcher dictates. But in complex scenarios, agents should be able to propose alternatives.
Example: WeatherChecker says "Route A has snow." RoutePlanner says "Route B is 30 minutes longer but clear." Instead of the Dispatcher deciding based on fixed rules, I want the agents to negotiate: "If I reroute through Route B, can you check weather again in 2 hours when it might clear?"
That's the next frontier. Not just A2A communication, but A2A negotiation. We're testing it now. Early results show 15% better routing decisions. More in a few months.
FAQ: What Is an Example of A2A?
Q: What is the most common example of A2A in production?
Customer support triage. An intake agent classifies a ticket, passes it to a specialized agent (billing, technical, account management), which then coordinates with a knowledge base agent to generate a response. Shopify uses a version of this for their merchant support system.
Q: How is A2A different from API calls?
APIs are synchronous, stateless, and deterministic. A2A is asynchronous, stateful, and probabilistic. An API returns the same result every time. An agent might return different results based on context, confidence, or even a random seed.
Q: What happens when two agents disagree?
Depends on the system. In our implementation, the Dispatcher acts as arbiter with a priority list. If RoutePlanner says "Route A is best" and CostOptimizer says "Route B is cheapest," the Dispatcher applies business rules (cost * 0.6 + time * 0.4). If still tied, it falls back to the human.
Q: Can A2A work across organizations?
Technically yes, practically no (yet). The security model is the blocker. If your agent talks to a vendor's agent, how do you trust it? We're seeing work on signed agent identities (like Verifiable Credentials) but it's early. Most A2A today is within the same trust boundary.
Q: What is the latency budget for A2A?
We target under 500ms per agent hop. That includes parsing, reasoning, and response generation. Beyond that, real-time workflows break. For batch workflows (reports, analytics), you can stretch to 5 seconds per hop.
Q: What's the biggest mistake teams make with A2A?
Treating agents like microservices. Microservices are stateless and deterministic. Agents are neither. You can't just throw an API gateway in front of agents and expect it to work. You need message-level context, fault tolerance, and human oversight.
Q: Do I need large language models for A2A?
No. You can have rule-based agents that communicate via A2A. The "agent" part comes from autonomy—the ability to make decisions and adapt—not from using an LLM. That said, most production systems use LLMs for the reasoning layer.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.