A2A Protocol for Multi Agent Systems: The Missing Layer in Production AI

Free Technical Audit

Expert Review

Here's the uncomfortable truth about agentic AI in 2026: we spent two years building single-agent systems that work, and now the hard part is making them talk to each other.

I've spent the last eighteen months at SIVARO watching teams stitch together multi-agent architectures with duct tape and custom JSON. They write API endpoints for every agent interaction, hardcode agent addresses, and pray the message formats stay stable. It doesn't scale. It never did.

The Agent2Agent (A2A) protocol is Google's answer to this mess — an open standard for how agents discover each other, negotiate capabilities, and exchange tasks without a human writing bespoke integration code for every pair. Think of it as TCP/IP for AI agents, except it runs over HTTP and speaks JSON.

This isn't a theoretical exercise. We've run production workloads on A2A since early 2026, and I'm going to show you exactly what works, what doesn't, and where the protocol still hurts.

What A2A Protocol Actually Is (and Isn't)

A2A is not another model context protocol (MCP). MCP solves the problem of connecting an agent to tools and data — one agent, many integrations. A2A solves the problem of connecting agents to each other — many agents, one integration standard. They're complementary layers, not competitors (MCP vs A2A: A Guide to AI Agent Communication Protocols).

The core artifacts are simple:

Agent Cards: JSON documents that describe what an agent can do, its skills, and its endpoints
Tasks: The unit of work exchanged between agents, with states from submitted to completed or failed
Messages: The payloads of a task, including text, files, and structured data
Artifacts: The outputs produced by completing a task

Here's what a minimal agent card looks like:

json
{
  "name": "invoice-processor",
  "description": "Extracts data from invoices and returns structured JSON",
  "url": "https://agents.sivaro.com/invoice-processor",
  "skills": [
    {
      "id": "invoice-extraction",
      "name": "Invoice Extraction",
      "description": "Parses PDF invoices and extracts line items"
    }
  ],
  "security": {
    "authentication": {
      "schemes": ["bearer"],
      "credentials": "https://agents.sivaro.com/.well-known/oauth"
    }
  }
}

That's it. An agent advertises what it can do, and other agents can discover it dynamically. No compile-time dependencies, no hardcoded URL, no custom protocol.

Why I Initially Dismissed A2A (and Why I Was Wrong)

When the spec dropped in 2025, I called it a solution in search of a problem. We had working multi-agent systems with REST APIs. Each agent exposed endpoints, and the orchestrator called them. Simple. Tested. Ship it.

Then we hit the integration wall.

In March 2026, we were building a customer support system that needed five agents: triage, knowledge base search, order lookup, refund processing, and escalation. Three of those were internal. Two were third-party SaaS tools. The integration code was 2,000 lines of Python that had to be rewritten every time a vendor changed their API. Which they did. Twice in one quarter.

That's the real problem A2A solves. Not the protocol itself — the volatility it removes. When every agent speaks A2A, changing the internals of one agent doesn't break the contract. The agent card updates, discovery finds the new version, and the orchestration layer doesn't care.

Most people think A2A is about standardization. It's not. It's about resilience to change.

The Architecture of an A2A System

Let me walk you through how we actually structure these systems in production.

Agent Discovery

The first step is discovery. In our SIVARO control plane, we maintain a registry of agent cards. When a new agent comes online, it posts its card to the registry. When an orchestrator needs a capability, it queries the registry.

python
import requests

def discover_agents(registry_url, skill):
    response = requests.get(f"{registry_url}/agents/lookup", params={"skill": skill})
    response.raise_for_status()
    return response.json()["agents"]

We've found this centralized discovery approach works better than fully peer-to-peer for most production systems. The registry becomes a single place to enforce security policies and monitor agent health. Pure P2P discovery is elegant but a nightmare to debug when an agent goes quiet.

Task Execution

Once you've discovered an agent, you send it a task. The A2A spec defines a clear lifecycle: submitted, working, input-required, completed, failed, canceled.

json
{
  "jsonrpc": "2.0",
  "method": "tasks/send",
  "params": {
    "id": "task-12345",
    "message": {
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "Extract line items from /tmp/invoice.pdf"
        }
      ]
    }
  }
}

The agent responds with a task object that includes a status. For long-running tasks, you poll or set up streaming:

python
task_status = agent.send_task(task_payload)

while task_status.state not in ["completed", "failed", "canceled"]:
    time.sleep(5)
    task_status = agent.get_task(task_status.id)

This looks boring. It should. The whole point of a protocol is to make the hard parts invisible.

One Protocol, Many Agents

Here's the moment I got it. We had a data enrichment pipeline in April 2026 that needed to pull company financials from a third-party provider. The provider's native API was a mess — SOAP endpoints, weird auth, undocumented rate limits.

Their A2A interface? Clean. Obvious. One POST request with a task, one response with structured data.

I'm not saying every SaaS vendor will offer A2A interfaces. But the ones that do instantly become easier to integrate than the ones that don't. That's the flywheel: protocol adoption creates convenience, convenience drives adoption.

The Elastic team makes this exact point — A2A works best when you have heterogeneous agents that need to discover each other at runtime. If you have one orchestrator and a fixed set of worker agents, a simple API might be enough.

A2A Protocol vs API for Agents: When the Protocol Wins

I get asked this constantly: why not just build APIs for my agents? The answer depends on your architecture.

An API works when:

You control both sides of the conversation
Agent interactions are stable and well-defined
The number of agents is small enough to integrate manually

A2A wins when:

Agents change frequently
Third parties are involved
You want dynamic discovery rather than hardcoded connections
Agents need to negotiate capabilities at runtime

The a2a protocol vs api for agents debate isn't about which is more powerful — it's about which reduces your total integration cost over the system's lifetime.

Here's a concrete example. We built a document processing system at SIVARO with three agents: classification, OCR, and extraction. The boundaries between these agents were stable. An API was fine.

Then a client asked to plug in their own extraction model. With APIs, that's a rewrite. With A2A, they published an agent card, our registry picked it up, and the orchestrator started routing to it. Same day. That's the difference.

The JSON-RPC Layer

A2A uses JSON-RPC 2.0 as its transport. Not REST. This matters for two reasons:

It's a standard with clear semantics for requests and responses
It supports streaming, which REST doesn't handle well natively

The spec defines methods like tasks/send, tasks/get, tasks/cancel, and message/stream. Each request carries an agent card identifier, so both sides know who they're talking to.

Memory and Context: The Hidden Challenge

Here's the thing everyone gets wrong about multi-agent systems: context is the real currency, and protocols don't give it to you for free.

Redis has a good breakdown of this — MCP is about giving agents access to external context (tools, memory stores, vector databases), while A2A keeps context between agents. A2A doesn't define how memory works. That's a design decision, not an oversight.

In practice, you need a shared memory layer. Orca Security's analysis of agent context protocols makes the case that protocols like MCP and A2A need to interoperate with memory systems like MemGPT-style context management.

Our production pattern looks like this:

python
# Pseudo-code for a shared memory layer
class AgentContext:
    def __init__(self, memory_store, task_id):
        self.memory_store = memory_store
        self.task_id = task_id
    
    def get_context(self, agent_id):
        # Returns the relevant conversation history for this agent
        return self.memory_store.get(f"{self.task_id}:{agent_id}")
    
    def append_context(self, agent_id, message):
        self.memory_store.append(f"{self.task_id}:{agent_id}", message)

Without this layer, your A2A messages are stateless requests. Fine for simple tasks. Insufficient for anything that requires multi-step reasoning across agent boundaries.

Security: The Part Nobody Wants to Talk About

Let me be direct: A2A's security model is barely there. The spec supports authentication schemes in agent cards, but the actual enforcement is left to implementations.

That's dangerous in production.

We learned this the hard way. In May 2026, one of our clients had an A2A endpoint exposed without authentication, and a crawler found it. The agent started processing garbage tasks and computing nonsense results. The system didn't fail — it silently degraded over three days before anyone noticed.

StackOne's comparison of MCP and A2A architectures hits this hard: A2A lacks explicit security controls around task poisoning and prompt injection between agents. The protocol assumes you've solved identity at the network layer.

Our mitigation stack:

Every agent endpoint sits behind a reverse proxy with mutual TLS
Agent-to-agent calls carry signed JWTs with short expiry
The registry maintains an allowlist of agent IDs
All exchanged data passes through a content filter that strips executable content

The protocol is not the security boundary. Your infrastructure is.

Streaming and Long-Running Tasks

Textbook A2A examples show tasks completing in milliseconds. Production tasks take minutes.

The spec handles this with streaming. An agent can send a message/stream response that pushes partial results as they're generated. This is the difference between waiting for a complete report and watching it materialize in real-time.

We built a live transcription agent that streams its output through A2A events:

json
{
  "jsonrpc": "2.0",
  "method": "message/stream",
  "params": {
    "task_id": "task-777",
    "message": {
      "role": "agent",
      "parts": [
        {
          "kind": "text",
          "text": "Partial transcription from segment 3..."
        }
      ]
    }
  }
}

The streaming semantics work. The tricky part is error recovery — if the orchestrator loses the connection mid-stream, the spec doesn't define how to resume. In practice, we've had to implement idempotency keys to avoid duplicate processing.

The Agent Card as a Living Contract

Your agent card should never be static. It's not documentation — it's a discovery contract that changes as your agent's capabilities change.

Our CI/CD pipeline at SIVARO treats agent cards as deployable artifacts. Every time we release a new model version, the pipeline regenerates the card with updated capabilities and pushes it to the registry. Downstream agents see the change and adapt their routing.

yaml
# GitHub Actions workflow snippet
- name: Publish agent card
  run: |
    python scripts/generate_agent_card.py \
      --model ${{ steps.model_name.outputs.name }} \
      --version ${{ github.sha }}
    curl -X POST \
      -H "Authorization: Bearer ${{ secrets.REGISTRY_TOKEN }}" \
      -d @agent_card.json \
      https://registry.sivaro.com/agents/register

This sounds obvious, but most teams I talk to treat agent cards as a one-time configuration. You'd think they'd know better by now, having seen what happens when contracts go stale.

Debugging A2A Systems: The Painful Reality

I need to be honest: debugging A2A systems is harder than debugging monolithic applications.

The problem is distributed tracing across agent boundaries. When a task fails, it can fail at any hop — the orchestrator, the worker, the memory store, the network. The protocol gives you task IDs, but correlating those across logs requires infrastructure you probably don't have.

Our stack:

OpenTelemetry spans for every A2A call, with task IDs as span attributes
A centralized log aggregator that indexes by agent card URL
Post-mortems that question the protocol before blaming the code

The hardest failures are the ones where the protocol succeeds but the outcome is wrong. The invoice agent says "completed." The orchestrator says "completed." The resulting JSON has the wrong vendor name. That's not a protocol failure — that's an AI failure, and the protocol gives you no visibility into it.

This is why I believe A2A will converge with more explicit evaluation layers. The protocol handles message delivery, not outcome validation. Those are different problems, and they'll need different solutions.

What I'd Change About A2A

If the protocol maintainers are listening, these are the gaps I'd fill based on our production experience:

Idempotency is undefined. The spec assumes at-most-once delivery, but production systems need at-least-once with deduplication keys.
Resume streaming isn't specified. Connection drops mid-task are common, and recovery is left to implementers.
Capability negotiation is too naive. The agent card says what an agent can do, but not how well. We need performance metadata so orchestrators can route to the best agent, not just a capable one.
Task prioritization is absent. In workloads with mixed criticality tasks, we had to build our own queueing layer.

These are fixable. The protocol's architecture is sound. But production hardening is still underway.

A2A in Production: The Practical Checklist

If you're shipping A2A to production, here's the bare minimum I'd require:

Discovery

Registry with health checks and heartbeat timeouts
Caching on the client side to avoid registry round-trips per task
Versioned agent cards with change notifications

Execution

Timeout and retry policies at every agent boundary
Idempotency keys on all task submissions
Structured error codes, not just "failed" states

Observability

Request IDs propagated through all downstream calls
Metric collection for task latency, failure rates, and discovery time
Log everything. Seriously. You'll wish you had the logs in week three.

The Future: A2A and Production AI

The agent landscape consolidating around A2A is the single best thing that's happened to multi-agent AI this year. When I see startups and enterprises adopting the same protocol, I know integration costs will crash. And when integration costs crash, experimentation increases.

But let me set expectations clearly: A2A is not magic. It won't make your agents smarter, your models better, or your infrastructure more reliable. It reduces friction between intelligent systems that exist in isolation. It doesn't create intelligence.

We're using A2A in most of our SIVARO client deployments now. It's the right call for dynamic, multi-party agent ecosystems. For fixed pipelines with stable boundaries, a well-designed API is still the right answer. Don't let anyone tell you otherwise.

The a2a protocol for multi agent systems market is still young. The winners will be the teams that pair protocol adoption with strong infrastructure — observability, security, and evaluation layers. That's where the real work is. The decision between MCP and A2A isn't either-or, it's both-and, layered by protocol maturity.

I have a bias, and I'll end with it: in 2026, every system we build has a protocol layer between agents. If a client pushes back on adding that layer because they "just want it to work," I know we're in for a long project. The protocol is maintenance. The protocol is future-proofing. The protocol is what separates a demo from a deployment.

FAQ

What is the difference between MCP and A2A?

MCP connects agents to tools and data sources. A2A connects agents to each other. MCP is about giving a single agent context and capabilities. A2A coordinates work across multiple agents. In practice, you'll use both in the same system — MCP for your agent's tools, A2A for agent-to-agent communication.

Is A2A a replacement for REST APIs?

No. A2A runs over HTTP and uses JSON-RPC as its transport. It's an abstraction layer on top of typical web protocols, not a replacement. You might still expose REST APIs to non-agent consumers, while A2A handles agent-to-agent traffic.

When should I use A2A protocol for multi agent systems instead of building custom APIs?

Use A2A when you need dynamic discovery, when agents are developed independently or by different teams, and when you expect the agent topology to change. Use custom APIs when you control both sides and the interface is stable.

What is an agent card?

An agent card is a JSON document that describes an agent's identity, capabilities, and security parameters. It's how agents discover each other in an A2A network. Think of it as a combination of a business card and a service description.

What does an A2A implementation spec require?

The basic requirements are: an HTTP endpoint that implements JSON-RPC 2.0, a published agent card, and support for the core task lifecycle methods (tasks/send, tasks/get, tasks/cancel). Beyond that, the implementation varies by use case.

Is A2A secure enough for production?

The protocol itself provides minimal security controls. You need to add your own authentication, authorization, and rate limiting at the infrastructure layer. Treat every agent endpoint as a public-facing API, because that's exactly what it is.

How does A2A handle long-running tasks?

The protocol supports both polling and streaming for long-running tasks. The streaming option pushes partial results to the client as they're generated. For tasks that take minutes, you'd typically pair streaming with checkpointing to handle failures.

What's the relationship between A2A and agent memory systems?

A2A doesn't define memory. It's a message-passing protocol. To maintain context across agent interactions, you need a shared memory layer that both agents can read and write. MCP-style memory tools or a custom context store typically fill this gap.

Is Google behind A2A?

Yes, Google launched A2A. But it's an open specification with contributions from more than 50 partners, including major tech companies. It's designed to be vendor-neutral and transport-agnostic.

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