A2A Protocol: Google's Agent-to-Agent Standard Explained

What the A2A Protocol Actually Is

A2A Protocol — short for Agent2Agent Protocol — is an open specification for inter-agent communication. It was unveiled by Google Cloud at Google Cloud Next in April 2025 with more than fifty launch partners including Atlassian, Box, Cohere, Intuit, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, and Workday. In mid-2025 Google donated the specification and reference implementations to the Linux Foundation, where it now sits alongside other neutral-governance standards.

The protocol is intentionally narrow. It defines five things and stops. First, an Agent Card — a JSON document, typically served at `/.well-known/agent.json`, that describes an agent's identity, capabilities, supported skills, authentication requirements, and endpoint URLs. Second, a Task object — the unit of work an agent accepts, with a unique ID, an input message, optional metadata, and a state machine that progresses through `submitted → working → input-required → completed | failed | canceled`. Third, Messages — the conversational turns exchanged within a task, each containing one or more Parts (text, file references, structured data). Fourth, Artifacts — the typed outputs an agent produces during a task (a generated report, a data file, a structured payload). Fifth, a small set of JSON-RPC 2.0 methods over HTTP — `tasks/send`, `tasks/sendSubscribe`, `tasks/get`, `tasks/cancel`, `tasks/pushNotification/set` — that move tasks through their lifecycle.

Everything else — the model behind the agent, the framework it uses internally, the language it is written in, the cloud it runs on — is opaque to the protocol. An A2A-compliant agent built on LangGraph can hand a task to an A2A-compliant agent built on CrewAI, which can in turn delegate to an agent built on Vertex AI's Agent Development Kit, and none of them need to know anything about the others' internals. That opacity is the entire point.

Why Agent-to-Agent Communication Needs a Protocol At All

By 2026, most large enterprises run more than one agent framework in production. Marketing might be on a no-code platform like Microsoft Copilot Studio. Engineering ships internal tools on LangGraph. The data team has standardised on Vertex AI Agent Builder. Customer support is using a vendor SaaS whose agents are a black box. Each of these populations has been deployed independently, by different teams, on different timelines, with different governance.

The second-order question — how do these agents collaborate when a workflow crosses team boundaries — has historically been answered with point-to-point integrations. Team A exposes a REST API, Team B writes a custom client, both teams pin to a schema, and any change requires coordinated releases. This works for two or three integrations. It collapses at twenty. The combinatorial cost of N agents needing to talk to N other agents is the same problem that drove the adoption of HTTP, GraphQL, and gRPC in earlier eras of distributed systems.

A2A is the engineering answer. A single, well-specified protocol that any agent can implement, any client can speak, and any gateway can mediate. The economic case is identical to the case for MCP at the tool layer: the cost of N×M custom integrations is replaced with the cost of N+M standard adapters. The governance case is stronger: a single A2A gateway becomes the place where authentication, audit logging, rate limiting, content filtering, and policy enforcement happen for inter-agent traffic — the same way an API gateway became the chokepoint for external API traffic a decade ago.

A2A's Five Core Concepts in Engineering Detail

The Most Common Misconception: A2A Does Not Replace MCP

The single most common question we field about A2A is whether it makes MCP obsolete. It does not. The two protocols solve different problems and are designed to compose.

A single agent's runtime almost always needs both. Internally, the agent uses MCP to discover and invoke its tools — query a database, post to Slack, read a Drive folder, call an internal API. Externally, the same agent exposes an A2A endpoint so that other agents can delegate work to it. From the outside, the agent is an A2A service. From the inside, it is an MCP client. The two protocols meet at the agent's process boundary and never overlap.

A useful mental model: MCP is the agent's nervous system — sensors and effectors that let it perceive and act on its immediate environment. A2A is the agent's social protocol — how it negotiates work with other agents in its network. An enterprise that has invested heavily in MCP servers has built up a strong tool layer; layering A2A on top lets those same tool-equipped agents collaborate. An enterprise that only has A2A endpoints but no MCP integration ends up with agents that can talk to each other but cannot actually do anything. Both layers are required for a complete agentic stack.

A Minimal A2A Server and Client in Python

# ─── A MINIMAL A2A AGENT SERVER ──────────────────────────────────────
# Exposes an Agent Card at /.well-known/agent.json and a JSON-RPC
# endpoint at /a2a. Real implementations use the official SDK
# (python-a2a or @a2a-protocol/sdk for TypeScript) — this hand-rolled
# version is illustrative.

from fastapi import FastAPI, Request
from uuid import uuid4
from datetime import datetime, timezone

app = FastAPI()
TASKS: dict[str, dict] = {}

AGENT_CARD = {
    "name": "Risk Scoring Agent",
    "description": "Scores enterprise customer accounts on credit and churn risk.",
    "version": "1.2.0",
    "url": "https://risk-agent.example.com/a2a",
    "authentication": {"schemes": ["bearer"]},
    "capabilities": {"streaming": True, "pushNotifications": True},
    "skills": [
        {
            "id": "score_account",
            "name": "Score a customer account",
            "description": "Returns a 0–100 risk score plus rationale.",
            "inputModes": ["text", "data"],
            "outputModes": ["data"],
        }
    ],
}

@app.get("/.well-known/agent.json")
def agent_card():
    return AGENT_CARD

@app.post("/a2a")
async def a2a_endpoint(request: Request):
    body = await request.json()
    method = body["method"]
    params = body.get("params", {})

    if method == "tasks/send":
        task_id = params.get("id") or str(uuid4())
        message = params["message"]
        # Real agent would invoke its scoring model here.
        score = run_risk_model(message)
        TASKS[task_id] = {
            "id": task_id,
            "status": {"state": "completed",
                       "timestamp": datetime.now(timezone.utc).isoformat()},
            "artifacts": [{
                "name": "risk_score.json",
                "parts": [{"type": "data", "data": score}],
            }],
            "history": [message],
        }
        return {"jsonrpc": "2.0", "id": body.get("id"), "result": TASKS[task_id]}

    if method == "tasks/get":
        return {"jsonrpc": "2.0", "id": body.get("id"),
                "result": TASKS[params["id"]]}

    return {"jsonrpc": "2.0", "id": body.get("id"),
            "error": {"code": -32601, "message": "Method not found"}}


# ─── A MINIMAL A2A CLIENT ────────────────────────────────────────────
# A different agent — say, a customer-onboarding orchestrator — calls
# the risk agent to delegate scoring as part of a longer workflow.

import httpx

async def delegate_risk_scoring(customer_id: str) -> dict:
    async with httpx.AsyncClient(timeout=30) as client:
        # Discover capabilities (in production: cached or via registry)
        card = (await client.get(
            "https://risk-agent.example.com/.well-known/agent.json"
        )).json()

        # Send the task
        resp = await client.post(
            card["url"],
            headers={"Authorization": f"Bearer {RISK_AGENT_TOKEN}"},
            json={
                "jsonrpc": "2.0",
                "id": "req-1",
                "method": "tasks/send",
                "params": {
                    "message": {
                        "role": "user",
                        "parts": [{"type": "data",
                                   "data": {"customer_id": customer_id}}],
                    }
                },
            },
        )
        task = resp.json()["result"]
        # Pull the typed artifact, not free-text parsing
        return task["artifacts"][0]["parts"][0]["data"]

The orchestrator calls the risk agent without knowing what model, framework, or runtime is behind it. The Agent Card is the only contract.

Where A2A Genuinely Earns Its Place in the Enterprise Stack

How to Adopt A2A Without Breaking What You Already Have

The right A2A adoption pattern in 2026 is incremental. There is no value in rewriting your existing agent integrations on day one — and there is significant risk in doing so before your team has internalised the protocol's idioms.

The approach we use across Inductivee's enterprise engagements is a four-phase rollout. Phase one is wrapping — pick the two agents that already need to talk to each other most painfully and put thin A2A facades in front of both. Both agents continue to do exactly what they did; the facade just translates their existing inputs and outputs into Tasks, Messages, and Artifacts. Phase two is one new integration — the next time a workflow requires a third agent, build it A2A-native rather than as a custom point-to-point integration. Phase three is the gateway — introduce a central A2A gateway as soon as you have three or more agents talking, before the topology becomes a mesh. Phase four is the registry — publish all internal Agent Cards to a discoverable registry so new agents and new workflows can find existing capabilities without tribal knowledge.

The key discipline across all four phases is to keep MCP and A2A separate in your team's vocabulary. Tool integration is MCP. Agent integration is A2A. Conflating them — or building one when you needed the other — is how teams end up with the worst of both protocols and the benefits of neither.

Five Decisions Every Enterprise A2A Adopter Has to Make Early

• **Agent identity model.** How do agents authenticate to each other? Bearer tokens scoped per skill, mTLS with a private CA, or OAuth2 with a workforce identity provider? Each has tradeoffs around rotation, revocation, and observability. We default to mTLS for internal traffic and OAuth2 for partner-facing endpoints.
• **Gateway-first or peer-to-peer.** Will all A2A traffic flow through a central gateway, or will agents call each other directly? Gateway-first is more governable but adds latency and a single point of failure. Peer-to-peer is faster and simpler but harder to audit. For most enterprises, gateway-first wins by a wide margin once the agent population exceeds three.
• **Task durability.** Where do Tasks live? In the agent's memory? A shared Postgres? A durable workflow engine like Temporal? The choice determines whether your agents survive restarts, scale horizontally, and resume long-running work after outages. We treat durable Task storage as non-negotiable for production deployments — see our note on agent memory architecture for why.
• **Schema discipline for Artifacts.** Free-text Artifacts are a trap. They look easy on day one and become impossible to evolve on day ninety. Define typed schemas (JSON Schema, Pydantic, or protobuf) for every Artifact your agents produce, version them explicitly, and reject Artifacts that fail validation at the gateway. This is the single highest-leverage decision in the whole adoption.
• **Cross-agent observability.** Standard logs are not enough. You need distributed tracing across agent boundaries — every Task carries a correlation ID that propagates into the called agent's traces, so a failure in step seven of a twelve-step delegation chain is debuggable. OpenTelemetry semantic conventions for A2A are emerging; adopt them now rather than rebuilding later.

Where A2A Fits in Inductivee's 2026 Engineering Practice

Across our agentic engagements, the pattern over the past nine months has been consistent: enterprises that started multi-agent work in 2024–2025 hit the integration wall around the time their agent count crossed five. A2A is the protocol layer that lets them break through that wall without throwing away the agents they already shipped.

For new engagements we now propose A2A from the first design conversation. The cost of designing agents to be A2A-native from day one is marginal — the SDKs are mature enough that exposing an Agent Card and JSON-RPC endpoint is a matter of hours, not weeks. The cost of retrofitting A2A onto an existing population of point-to-point integrations is much higher, both in engineering time and in the political cost of touching production systems that work.

We expect 2026 to be the year A2A crosses from "interesting standard" to "default assumption" in enterprise agent architecture, in roughly the same way MCP crossed that line in 2025. Teams that adopt early will accumulate optionality — the freedom to swap frameworks, add specialist agents, and integrate vendor capabilities with a configuration change rather than a sprint. Teams that wait will spend 2027 doing the same migration work, under more pressure, with more legacy to unwind.

If this matches a problem you are working on now, our team can help scope it — we have shipped A2A and MCP-based architectures across financial services, healthcare, and logistics engagements over the past year and the playbook is well-tested.