What Is an Example of A2A? The Practical Guide You Need

Let me tell you a story. I was [building a data pipeline for a client in early 2023. They had two [systems — one processed customer orders, the other managed inventory. Both were written by different teams. Different languages. Different databases. And every time an order came in, they needed the inventory system to do something.

The first instinct? REST API. Maybe a message queue. But here's the thing — the teams didn't want to build custom integrations. They wanted a standard. Something that worked like HTTP works for web pages, but for machine-to-machine communication.

That's when I started digging into A2A. And the question I kept getting was simple: what is an example of a2a?

I'll answer that directly. But first — context.

A2A stands for "Agent-to-Agent" — a protocol or framework where [software agents communicate directly with each other to accomplish tasks. Not human-to-machine. Not machine-to-human. Pure machine-to-machine, but with a twist: the agents are autonomous. They make decisions. They negotiate. They don't just send data — they collaborate.

Think of it as API communication with agency.

In this guide, I'll walk you through what A2A looks like in practice, with real examples, code, and hard-won lessons from my team at SIVARO. You'll leave knowing exactly how to spot an A2A interaction and how to build one yourself.

The Short Answer: An Example of A2A

Let me give you the clean what is an example of a2a? answer before we get deep.

Example: A customer support agent AI (Agent A) detects a shipping delay. It doesn't just log the error. Instead, it negotiates with the logistics agent (Agent B) to re-route the package, then updates the CRM agent (Agent C) with the new ETA. All three agents share a common language — a protocol — and each can refuse, suggest alternatives, or escalate.

No human in the loop for the negotiation step. That's A2A.

Why Most People Get A2A Wrong

I see three common mistakes:

They think A2A is just another API. It's not. APIs are stateless, request-response, and rigid. A2A agents can negotiate — "I can't do that, but I can do this instead."
They confuse A2A with RPA (Robotic Process Automation). RPA automates UIs. A2A automates decisions between systems.
They assume A2A requires AI. Wrong again. A2A works fine with rule-based agents. But adding LLMs makes it more flexible.

The confusion is understandable. The term "agent" is overloaded. But once you've seen a working A2A system, the fog clears.

Anatomy of an A2A Interaction

Before the code, let me break down the parts of any A2A exchange:

Component	What It Does	Real Example
Agent A	Initiates a request with context	"I need a shipping reroute for order #4392"
Agent B	Evaluates request, returns capabilities	"I can reroute, but only within next-day zones"
Shared Protocol	Defines message format and negotiation rules	JSON-LD schema with action verbs
Trust Mechanism	Verifies agent identity and permissions	JWT tokens with scopes
State Manager	Tracks conversation across multiple turns	Database or distributed cache

The protocol is the invisible glue. Without it, you just have two programs talking garbage.

Code Example 1: Basic A2A Handshake in Python

Let's make this concrete. Here's a minimal A2A interaction between an order agent and a shipping agent.

python
# order_agent.py
import requests
import json

# Agent A: Order Manager
def request_shipping_reroute(order_id, new_zone):
    # A2A uses a shared payload structure
    message = {
        "agent_id": "order-master-v1",
        "action": "reroute_package",
        "parameters": {
            "order_id": order_id,
            "destination_zone": new_zone,
            "priority": "high"
        },
        "context": {
            "customer_tier": "premium",
            "delay_reason": "weather"
        }
    }
    
    response = requests.post(
        "http://shipping-agent.local/a2a/negotiate",
        json=message,
        headers={"Authorization": "Bearer a2a_token_123"}
    )
    
    return response.json()

# Agent B: Shipping Manager
def handle_reroute_request(request_data):
    # Agent B evaluates constraints
    zone_capacity = {"premium_zone": 0.85, "economy_zone": 0.95}
    
    if request_data["parameters"]["destination_zone"] == "premium":
        if zone_capacity["premium_zone"] < 0.90:
            return {
                "status": "accepted",
                "new_eta": "2024-03-15T14:00:00Z",
                "cost_delta": 0.00
            }
        else:
            # Counter-offer: Agent B suggests alternative
            return {
                "status": "counter_offer",
                "alternative_zone": "economy_zone",
                "new_eta": "2024-03-16T10:00:00Z",
                "penalty": "customer_credit_5"
            }
    
    return {"status": "rejected", "reason": "destination_unavailable"}

Notice something? Agent B didn't just say yes or no. It gave a counter-offer. That's the negotiation part of A2A. A REST API would just return 400 Bad Request.

The Protocol Matters More Than the Agents

Most people obsess over the AI model inside the agent. I've seen teams spend months fine-tuning a GPT-4 variant, only to realize their agents couldn't talk to each other because they used different JSON schemas.

Don't make that mistake.

At SIVARO, we standardized on a lightweight protocol inspired by the Agent Communication Language (ACL) from FIPA — but modernized for HTTP and JSON. Here's the core spec we use:

json
{
  "a2a_version": "1.0",
  "message_id": "a2a-msg-9856-abc",
  "sender_id": "order-master-v1",
  "receiver_id": "shipping-agent-v2",
  "conversation_id": "conv-ship-4392",
  "performative": "request",
  "content": {
    "action": "reroute_package",
    "parameters": { ... }
  },
  "timestamp": "2024-03-14T23:45:00Z"
}

The performative field is the key. It tells the receiving agent how to interpret the content. Standard values:

request — "I need you to do this"
inform — "Here's a fact you should know"
counter_offer — "I can't do that, but here's an alternative"
accept — "Agreed, proceeding"
reject — "Cannot do this"
query — "Tell me your current state"

Without performatives, agents can't negotiate. They just blindly execute.

Code Example 2: A Multi-Turn Negotiation

Real A2A isn't one message. It's a conversation. Here's a three-turn negotiation between a fulfillment agent and a warehouse agent:

python
# Turn 1: Fulfillment agent requests a rush order
request_msg = {
    "performative": "request",
    "content": {
        "action": "allocate_inventory",
        "product_sku": "TB-2024",
        "quantity": 500,
        "deadline": "2024-03-20T00:00:00Z"
    }
}

# Turn 2: Warehouse agent counter-offers
response_msg = {
    "performative": "counter_offer",
    "content": {
        "available_quantity": 300,
        "alternative_sku": "TB-2024-BULK",
        "lead_time": "2024-03-22T00:00:00Z",
        "price_delta": "+15%"
    }
}

# Turn 3: Fulfillment agent accepts with modified terms
accept_msg = {
    "performative": "accept",
    "content": {
        "quantity": 300,
        "sku": "TB-2024",
        "acknowledged_delay": True,
        "reject_upsell": True
    }
}

Each turn is a discrete HTTP request-response. But the agents maintain state using the conversation_id. No long-lived web sockets required (though you can use them for lower latency).

When to Use A2A (And When to Walk Away)

I've seen teams try to force A2A into every integration. It's a mistake. Here's my decision framework:

Use A2A when:

You have 3+ autonomous services that need to negotiate (not just exchange data)
The agents need to handle exceptions or fallbacks automatically
You want to avoid hardcoding business rules in every integration

Don't use A2A when:

You have two systems that just pass data (use a message queue)
Your "agents" are really just thin wrappers around CRUD APIs (just use REST)
You need real-time latency under 10ms (WebSocket or gRPC is better)

Sharpened that over three years at SIVARO. The most common failure we see: teams trying to make A2A solve a data pipeline problem. It doesn't. It solves a coordination problem.

Real-World Example: A2A in Production AI Systems

In late 2023, we built an A2A system for a logistics client handling 50,000 shipments daily. Here's how it worked:

Agents in the system:

Order Intake Agent — receives customer orders, validates, decides routing
Inventory Agent — checks stock, reserves items, triggers reorders
Shipping Agent — selects carrier, calculates cost, books pickup
Customer Comms Agent — sends notifications, handles complaints

The critical A2A flow (what is an example of a2a? in production):

Order Agent → Inventory Agent: "Can I reserve 200 units of SKU-001?"

Inventory Agent responds: "Only 150 available. Suggest backorder 50 units with a 3-day lead time."

Order Agent → Customer Comms Agent: "Inform the customer — partial shipment available, rest can ship in 3 days."

Customer Comms Agent: "Sent. Customer accepted partial shipment."

Order Agent → Shipping Agent: "Book a partial shipment. 150 units. Standard delivery."

No human touched this flow. The agents negotiated the constraints, updated the customer, and executed the new plan in under 3 seconds total.

That's A2A.

Code Example 3: An A2A Protocol with Error Handling

Here's where the rubber meets the road. A2A agents need to handle failures gracefully. Here's a robust version with retry logic and fallbacks:

python
import time
import json
import requests
from typing import Dict, Optional

class A2AAgent:
    def __init__(self, agent_id: str, protocol_endpoint: str):
        self.agent_id = agent_id
        self.endpoint = protocol_endpoint
        self.max_retries = 3
        self.backoff_seconds = 1
        
    def send_message(self, target_agent: str, message: Dict) -> Optional[Dict]:
        for attempt in range(self.max_retries):
            try:
                response = requests.post(
                    f"{self.endpoint}/a2a/message",
                    json={
                        "sender_id": self.agent_id,
                        "receiver_id": target_agent,
                        "performative": message.get("performative", "inform"),
                        "content": message["content"],
                        "conversation_id": message.get("conversation_id", "new"),
                        "version": "1.0"
                    },
                    timeout=5
                )
                response.raise_for_status()
                return response.json()
            except requests.Timeout:
                print(f"[WARN] Attempt {attempt+1} timed out")
                time.sleep(self.backoff_seconds * (attempt + 1))
            except requests.HTTPError as e:
                # Check if agent is overloaded
                if response.status_code == 503:
                    print("[INFO] Agent busy, retrying...")
                    time.sleep(2)
                else:
                    return {"performative": "error", "content": str(e)}
        return {"performative": "error", "content": "max_retries_exceeded"}

# Usage
fulfillment_agent = A2AAgent("fulfillment-v1", "http://a2a-broker.local")
result = fulfillment_agent.send_message("warehouse-v2", {
    "performative": "request",
    "content": {"action": "reserve", "quantity": 100}
})

Notice: the agent doesn't just crash on failure. It uses backoff, differentiates between transient errors (503) and hard errors (400), and returns structured errors that another agent can handle programmatically.

Here's something nobody talks about: A2A introduces new attack surfaces.

If agent A can negotiate with agent B, what stops agent A from negotiating with agent C to leak data? Or what if an attacker spoofs a valid agent?

We learned this the hard way. In an early prototype, a misconfigured inventory agent accepted a reroute request from a test agent that wasn't authorized. The result? 2000 units were routed to the wrong warehouse. Took two hours to undo.

The fix: Every A2A message must carry a capability token — not just an auth token. The token specifies:

Which actions the sender can request (e.g., "reroute" but not "cancel")
Which resources it can touch (e.g., zone A, not zone B)
Rate limits (max 10 requests per minute)

Here's the capability token format we use:

json
{
  "iss": "auth-service-v1",
  "sub": "order-master-v1",
  "capabilities": ["reroute_package", "query_status"],
  "scoped_resources": ["zone:premium", "zone:economy"],
  "ratelimit": "10/1m",
  "exp": 1710518400
}

Every A2A endpoint validates this token before processing. If it's missing or expired, the request is rejected with a clear error code.

The Future: A2A + LLMs

I saved this for last because it's the most controversial take.

Most people think A2A is dead — that LLMs will replace it with natural language. They're wrong.

We tested this at SIVARO. We built an LLM-based agent that could "talk" to another LLM agent using natural language strings instead of structured protocols. The results were terrible:

Hallucinations: agents agreed to things they couldn't do
Ambiguity: "ship it fast" means different things to different agents
No audit trail: you can't log "what was negotiated" in a structured way

The winning approach: structured protocol (A2A) for negotiation, LLMs for decision-making within the agent.

Example: The shipping agent uses an LLM to decide whether to offer a counter-route, but communicates that offer via the A2A protocol. The LLM handles the fuzzy logic; the protocol handles the deterministic handoff.

That's the future I'm betting SIVARO's stack on.

Frequently Asked Questions

What is an example of A2A in e-commerce?
A product recommendation agent negotiating with an inventory agent to offer a substitute when an item is out of stock — without human intervention.

Can A2A work without AI?
Yes. Rule-based agents (if-then logic) work fine. AI makes them smarter, but the protocol doesn't require intelligence.

Is A2A the same as MCP (Model Context Protocol)?
No. MCP is about giving an LLM access to tools. A2A is about agents talking to each other. They complement each other — MCP for tool use, A2A for inter-agent communication. See Anthropic's MCP spec for comparison.

What's the difference between A2A and RPC?
RPC is a point-to-point call. A2A is a conversation with negotiation, state, and the possibility of counter-offers. RPC assumes the receiver will do what it's told. A2A assumes the receiver might say no.

How do you handle A2A at scale?
We use a lightweight broker (similar to NATS or Redis) to route messages. Each agent has a queue. The broker handles retries and dead-letter queues. No need for a heavyweight message bus.

**What's the minimum viable A2A protocol?**
You need: sender/receiver IDs, a performative field, a content payload, and a conversation ID. That's it. Everything else is optional.

Do A2A agents need to be in the same network?
No. We've run A2A across AWS and GCP using HTTPS with mutual TLS. Latency is higher (50-200ms per turn) but it works.

The Bottom Line

A2A isn't a product you buy or a framework you download. It's a design pattern. A way of thinking about how autonomous systems should talk to each other.

The example I gave — order agent negotiating with inventory agent — is the simplest case. But I've seen it scale to 12 agents handling a single customer inquiry, each one negotiating, counter-offering, and resolving conflicts in real time.

What is an example of a2a? It's the invisible coordination layer that runs between your AI systems. The part nobody sees, but that makes everything work.

If you're building production AI systems — the kind that handle real money, real customers, real consequences — you need A2A. But start small. Two agents. One negotiation. Get that right, then scale.

That's what we did at SIVARO. And we're still learning.

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

What Is an Example of A2A? The Practical Guide You Need