What Is an Example of A2A? Real Agent-to-Agent Architecture in Production

I spent the first six months of 2024 telling people A2A — Agent-to-Agent architecture — was the next big thing. Most nodded politely and asked me to define it. So let me skip the theory and give you something concrete: an example of A2A in production that I built at SIVARO for a logistics client last fall.

Here's the short version before I unpack it:

A2A is when two or more autonomous AI agents talk to each other to complete a task that neither can finish alone. Not chaining API calls. Not human-in-the-loop approval gates. Two AI systems negotiating, handing off context, and executing independently.

What Is an Example of A2A? The Incident-Response Agent Pair

Let me walk you through the exact system we deployed in October 2024 for a European freight company — let's call them Euronav. They move 12,000 containers monthly across Rotterdam, Hamburg, and Antwerp.

The problem: When a container got stuck at customs (happens 17% of the time on certain routes), their operations team spent 45 minutes manually coordinating between customs databases, their internal ERP, and carrier APIs. Then another 30 minutes updating the customer.

The A2A solution: Two agents.

Agent Alpha: Customs clearing specialist. Monitors customs status APIs every 8 minutes. Knows 14 country-specific customs regulations.
Agent Beta: Customer communications specialist. Controls the customer portal, email system, and Slack integration.

They don't share a database. They don't have a shared brain. They talk to each other.

Here's the flow:

Agent Alpha detects: "Container NVIC-7823 flagged for phytosanitary inspection at Rotterdam. Estimated delay: 48 hours."
Agent Alpha sends structured message: {
  "agent_id": "alpha_customs_v2",
  "target": "beta_comm_v2",
  "type": "incident_escalation",
  "payload": {
    "container_id": "NVIC-7823",
    "incident_code": "PHYTO_INSPECT",
    "confidence": 0.94,
    "estimated_resolution": "2024-10-19T14:00Z",
    "context_blob": "base64_encoded_json_of_last_5_status_updates"
  }
}
Agent Beta receives that. Cross-references customer SLA for NVIC-7823. Fires off:
1. Email to customer transport manager: "Your container requires inspection. Estimated delay 2 days. We'll update at 14:00 UTC tomorrow."
2. Slack alert to Euronav ops team.
3. Updates the portal status.
4. Sends back to Alpha: "Acknowledged. Customer notified. SLA risk category: LOW (buffer remains)."

That's A2A. One agent detected a problem, communicated it in a structured format, and the second agent acted on it autonomously. No human touched it. No middleman orchestration layer.

Why This Isn't Just Fancy API Orchestration

Most people think A2A is just "calling APIs with extra steps." They're wrong.

At first I thought this was a branding problem — turns out it's a trust problem. When I started building A2A systems in early 2023, I made the same mistake. I built a central orchestrator that called different AI services. That's not A2A. That's a monolith with a nicer name.

Real A2A means:

Each agent has agency. Alpha doesn't ask permission to tell Beta about customs issues. It just does it.
Context is passed, not shared. Beta doesn't have access to Alpha's database. Alpha sends a self-contained context package.
Agents can refuse or negotiate. Beta in our system can reject a message if confidence is below 0.7. It sends back a REQUEST_CLARIFICATION type. Alpha then retrieves additional documentation and retries.

That last point is crucial. In February 2024, during testing, Beta rejected 11% of Alpha's initial messages because confidence was too low. We had to train Alpha to be more specific. That's not a bug — it's the whole point.

The Architecture We Actually Used

I'll show you the core message schema. We iterated on this 14 times before we got it right.

python
# SIVARO A2A Message Schema v2.3 - Used in production since Oct 2024
from dataclasses import dataclass, field
from typing import Any, Optional
from enum import Enum
from datetime import datetime

class MessageType(Enum):
    COMMAND = "CMD"  # Do something
    ESCALATION = "ESC"  # Problem detected, handoff
    REQUEST_INFO = "RIQ"  # Need more data
    RESPONSE = "RSP"  # Acknowledgment with result
    NEGOTIATE = "NEG"  # Counter-offer or rejection
    ACK = "ACK"  # Simple acknowledgment, no payload

class ConfidenceThreshold(float, Enum):
    HIGH = 0.90
    STANDARD = 0.75
    LOW = 0.60

@dataclass
class AgentMessage:
    message_id: str = field(default_factory=lambda: f"msg_{datetime.utcnow().timestamp()}")
    source_agent_id: str
    target_agent_id: str
    message_type: MessageType
    confidence: float
    payload: dict[str, Any]
    context_token: Optional[str] = None  # Short-lived auth token, expires in 300s
    ttl_seconds: int = 120  # If not acted on in 2 minutes, auto-expire
    priority: int = 3  # 1 (critical) to 5 (low)

The context_token was the hardest part. Each agent operates in its own Kubernetes namespace. They don't share service accounts. The token gives Beta access to exactly one blob in S3 for exactly 5 minutes. No more, no less.

We tested 4 different serialization formats. Protocol Buffers won — 40% smaller payloads than JSON, and we were pushing 8,000 messages per hour during peak.

What Broke at First (And How We Fixed It)

I'm not going to pretend this was clean. The first two weeks of live deployment were brutal.

Problem 1: Agent hallucination cascades.
On day 3, Alpha sent a false positive — flagged a container that wasn't actually stuck. Beta took that message, notified the customer, and Alpha double-downed by sending supporting "documentation" (it generated fake PDFs). The customer called to complain. I got a 2 AM phone call.

Fix: We added a validation step before any message with type ESCALATION gets sent. Alpha now runs a secondary model (a smaller, cheaper classifier) that independently checks the original status. If the two models disagree, the message drops to confidence: 0.55 — below the threshold Beta will accept.

Problem 2: Context drift over long conversations.
A single container incident can generate 15-20 messages between agents. By message 12, the context_blob was 400KB and full of noise. Beta started ignoring important details buried deep in the payload.

Fix: We implemented a sliding context window. Only the last 3 messages and a summary of everything before that get included. The summary is regenerated by each agent every 5 interactions.

python
# Context windowing in production
class ContextManager:
    def __init__(self, max_interactions: int = 5):
        self.max_interactions = max_interactions
        self.summarizer = SummarizerModel("gpt-4o-mini")  # Runs every 5 interactions

    def prepare_context(self, interaction_history: list[dict]) -> dict:
        if len(interaction_history) <= self.max_interactions:
            return {"type": "full", "data": interaction_history}

        # Keep last N, summarize the rest
        recent = interaction_history[-self.max_interactions:]
        past = interaction_history[:-self.max_interactions]
        summary = self.summarizer.generate(past)  # Runs ~200ms, costs $0.003

        return {
            "type": "windowed",
            "summary": summary,
            "recent": recent
        }

Problem 3: Circular dependencies.
Beta's customer notification sometimes triggered Alpha to check the container status again. Alpha would detect "still delayed" and escalate again. Beta would notify again. Customer got 4 emails in 10 minutes.

Fix: Deduplication by incident ID. If Beta sees an escalation for container_id: "NVIC-7823" within 30 minutes of the last one, it sends ACK back but doesn't re-notify. It also logs a DUPLICATE_IGNORED metric.

When A2A Fails (And It Will)

Let me be honest about the failure modes because every vendor article skips them.

Failure case 1: Network splits.
We run across 3 AWS regions. If the link between Frankfurt and Ireland goes down (happened in June 2024 for 18 minutes), Alpha and Beta can't talk. Our original design had the orchestrator hold the queue. But orchestrators are single points of failure.

Now: Each agent has a local message queue that persists to disk. If the connection drops, messages queue locally and replay when connectivity returns. Beta processes backlog with exponential backoff. We saw a 4-minute queue drain after that 18-minute outage.

Failure case 2: One agent goes rogue.
During a model update in September, Alpha's confidence scoring broke. It started sending confidence: 0.99 for everything — including obvious noise. Beta trusted it and sent 27 false notifications before we caught it.

Fix: Beta now maintains a running trust score for Alpha. If Alpha's false-positive rate exceeds 5% over a rolling 24-hour window, Beta automatically downgrades all messages from Alpha by 0.2 confidence. This isn't in the spec — it was built after the incident.

python
# Trust monitoring per agent pair - deployed after Sept 2024 incident
class TrustMonitor:
    def __init__(self, agent_id: str, threshold: float = 0.05):
        self.trust_buffer = deque(maxlen=500)  # Keep last 500 interactions
        self.false_positive_threshold = threshold
        self.penalty = 0.2

    def report_outcome(self, message_id: str, was_accurate: bool):
        self.trust_buffer.append(was_accurate)
        if len(self.trust_buffer) >= 100:
            false_positive_rate = 1 - (sum(self.trust_buffer) / len(self.trust_buffer))
            if false_positive_rate > self.false_positive_threshold:
                # Apply confidence penalty to all future messages from this agent
                self._apply_penalty()

What I Learned About A2A Design Patterns

After 14 months of building A2A systems for 3 different clients, here's what patterns work and what don't.

The Handshake Pattern (Works)

This is what Euronav uses. Agent A detects, Agent B acts, Agent A confirms receipt of action. Three messages max.

python
# Handshake pattern - most reliable
class HandshakeProtocol:
    def __init__(self, agent_a, agent_b):
        self.agent_a = agent_a
        self.agent_b = agent_b

    def execute(self, message: AgentMessage) -> bool:
        # Step 1: A sends to B
        response = self.agent_b.receive(message)
        if response.message_type == MessageType.ACK:
            # Step 2: B acknowledges - protocol complete
            return True
        elif response.message_type == MessageType.NEGOTIATE:
            # Step 3: B wants more info - A resends with context
            retry = self.agent_a.prepare_additional_context(message)
            final = self.agent_b.receive(retry)
            return final.message_type == MessageType.ACK
        return False

The Subscription Pattern (Works with Limits)

Agent A publishes events. Agent B subscribes to specific event types. This works great for fire-and-forget scenarios but fails for complex negotiations. We use it for status updates but not for incident escalation.

The Blackboard Pattern (Doesn't Scale)

We tried this in Q1 2024. Shared memory space where agents read and write. It created race conditions, deadlocks, and context poisoning. Abandoned after 3 weeks.

The Orchestrator Pattern (Not A2A)

Most articles claim this is A2A. It's not. It's RPC with extra JSON. Real A2A requires agents to have autonomy. If an orchestrator is making decisions about which agent does what, you don't have agent-to-agent interaction. You have a master-slave architecture.

The Numbers That Matter

I track three metrics for every A2A deployment:

Message delivery success rate: 99.7% over 6 months. The 0.3% failures are all network-related.
Agent resolution time: 3.2 seconds average from Alpha detecting to Beta completing notification. Down from 47 minutes with human operators.
False escalation rate: 1.8% in October, down from 7.2% in July.

The cost is higher than you'd think. Each A2A message costs about $0.04 to process (including the context summarization model). That's $320 per 8,000 messages. But it replaces 3 FTEs at $65K/year each. The ROI math works if you're processing more than 2,000 incidents per month.

FACTS vs Marketing (Agent-to-Agent Architecture)

Let me address the elephant in the room. Most of what you read about "multi-agent systems" is marketing. I've seen startups pitch A2A where the "agents" are just different endpoints of the same API. That's not A2A.

Real A2A requires:

Each agent has its own model. Not just a different prompt. Different model. Different fine-tuning. Different data sources.
Each agent can say "no." If your architecture doesn't allow agents to reject tasks, you don't have agent-to-agent interaction. You have function calling.
Context is ephemeral and scoped. Shared memory might be simpler, but it creates coupling that kills the whole point of distributed intelligence.

FAQ — What Is an Example of A2A?

Q: Can you give a simple example of A2A that doesn't involve logistics?
A: I built one for a legal tech company in March 2024. Agent A reads incoming contract changes. Agent B maintains the compliance database. When Agent A detects a jurisdiction change (say California to Texas), it sends a structured alert to Agent B. Agent B cross-references 47 state-specific compliance rules and returns an impact analysis. No human reads the contract at that stage. The whole cycle takes 6 seconds.

Q: Is A2A the same as multi-agent systems (MAS)?
A: No. MAS is the academic field. A2A is a specific architecture pattern within it. Most MAS research assumes cooperative agents sharing a goal. Production A2A systems work with agents that have different goals and different trust boundaries.

Q: Which companies are using A2A in production?
A: I can name three I've worked with directly: the logistics company Euronav (2024), a healthcare claims processor in the UK (St. Jude Health, 2023), and a financial compliance firm (ComplyFirst, early 2024). Google and Microsoft have demos but I haven't seen them in production at scale.

Q: What's the minimum viable setup for A2A?
A: You need two agents, a message queue (Redis Streams works fine), and a shared schema. That's it. Don't build a platform. Build the specific interaction your system needs. I've seen teams spend 6 months building a "generic A2A framework" and never ship anything useful.

Q: What language is best for building A2A systems?
A: Python for the agent logic. Go or Rust for the message bus. We use Go for the transport layer (8X faster than Python for message routing) and Python for the agent models.

Q: How do you handle security in A2A?
A: Short-lived context tokens (300 seconds max). Each agent runs in its own namespace. No shared databases. All messages encrypted in transit and at rest. We had a security audit in August 2024 — passed with one finding (token reuse in low-traffic periods, fixed).

Q: What happens when both agents disagree on a decision?
A: Escalate to a third agent that specializes in conflict resolution. We call it Agent Omega. It has visibility into both agents' last 10 interactions and makes a binding decision. In 6 months, Omega has been invoked 23 times across 12,000+ interactions. It sides with the higher-confidence agent 78% of the time.

Where A2A Is Headed

I'm watching three developments closely:

Standardized message formats. Google published their Agent-to-Agent Communication Protocol (A2A Protocol spec) in April 2024. It's overly complex for small systems but becoming the de facto standard for enterprise.
Trust scoring networks. Instead of each agent maintaining its own trust scores, I'm seeing startups build shared registries where agents can query each other's reliability. Privacy implications are messy, but the performance gains are real.
Economic models for agent work. If Agent A does work for Agent B, should it get paid? I'm serious. One of my clients is experimenting with microtransactions between agents — each successful message costs 0.001 credits. It sounds absurd until you realize it prevents spam and creates economic pressure to be accurate.

Final Thought

A2A isn't about making agents smarter. It's about making them better at working with each other. The hardest lesson I learned is that the intelligence isn't in any single agent — it's in the space between them. The conversation. The negotiation. The trust that builds (or breaks) over time.

If you're building an A2A system today, start with one pair of agents solving one specific problem. Don't build the platform. Build the relationship. Add agents only when a human is consistently mediating between two existing agents.

That's the pattern. That's the lesson. That's what an example of A2A looks like when you strip away the theory and look at what actually works.

What Is an Example of A2A? Real Agent-to-Agent Architecture in Production