A2A v1.2 in Production: Enterprise Interoperability Guide

Search "what is the Agent2Agent protocol" and you get a clean, correct, slightly useless answer: A2A is an open standard that lets AI agents discover and call each other across platforms. True — and it tells an engineering leader nothing about whether to build on it, what it costs to do well, or how to tell a partner who has shipped it from one who has read the README.

This guide is the second answer. A2A is not hard to describe — it is a JSON document, a handful of RPC methods, and a task state machine. It is hard to run in production, because the gap between "the handshake works in a demo" and "the handshake survives a remote agent timing out, a rotated signing key, and a security review" is the gap consultancy slides skip. We will walk the spec at the depth you need to make a build decision, then walk a real cross-vendor handshake — an Agent Development Kit (ADK) agent calling a ServiceNow agent — and name what production-grade requires on top of the protocol.

1. What A2A is, and the problem it solves

A2A — Agent2Agent — is an open protocol for agent interoperability: a standard way for one autonomous agent to discover a second agent's capabilities, delegate a unit of work to it, and track that work to completion, regardless of who built either agent or what framework each runs on.

The problem is specific. The moment your agent estate has more than one agent, and those agents were not all built by the same team on the same framework, you have an integration surface. The pre-A2A answer was bespoke glue: a custom HTTP contract for every pair of agents that needed to talk, re-invented per integration. That does not scale past the third integration, and it locks you into whatever vendor's agent fabric you standardized on first.

A2A replaces the bespoke glue with one contract. An agent that speaks A2A can call any other agent that speaks A2A — the way an HTTP client can call any HTTP server — without either side knowing the other's implementation. Worth being precise about, because A2A is often described as if it competes with the frameworks themselves. It does not: A2A is the protocol between agents, indifferent to what each agent is built with.

2. Where A2A sits: a Linux Foundation project, not a Google product

This matters more than it looks, and getting it wrong is the most common framing error in published material on A2A.

A2A originated at Google, announced in April 2025. But in June 2025, Google donated the protocol to the Linux Foundation, which now provides its neutral governance home. The named participating organizations are not a Google customer list — they include AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow. The protocol is developed in the open, the specification is public, and no single vendor controls its direction.

By April 2026, the protocol passed 150 supporting organizations — up from roughly 50 a year earlier — with reference SDKs in Python, JavaScript, Java, Go, and .NET. More to the point for a production decision: the major platforms ship native support. Microsoft integrated A2A into Azure AI Foundry and Copilot Studio; AWS added it through Amazon Bedrock AgentCore Runtime; Google Cloud supports it across the Gemini Enterprise Agent Platform. A2A is no longer a proposal — it is infrastructure your vendors already implement.

3. The v1.2 spec changes that matter

If you evaluated A2A in its first months and shelved it, the v1.2 revision is the version worth re-reading. Three changes move it from "promising" to "productionable."

1. gRPC as a first-class transport. A2A defines three protocol bindings — JSON-RPC 2.0, gRPC, and HTTP+JSON/REST — and an agent may support more than one. gRPC matters for the high-volume, low-latency, internal case: streaming task updates over a gRPC channel beats long-polling a JSON-RPC endpoint when an orchestrator is fanning work out to a mesh of delegates. You pick the binding per deployment; the semantics are identical across all three.
2. Formalized Agent Card signing. Section 8.4 of the A2A specification covers Agent Card Signing — canonicalization of the card document and cryptographic verification of its signature. This is the change that makes A2A safe to run across a trust boundary, and we treat it as non-optional. Mechanics in section 4 and section 6.
3. Multi-tenancy. An optional tenant parameter across operations lets a single A2A endpoint serve multiple isolated tenants without a separate deployment per tenant. For a platform team running A2A as a shared surface, this removes a real piece of infrastructure sprawl.

None of these are cosmetic. gRPC changes the performance envelope, card signing changes the security posture, multi-tenancy changes the deployment topology — which is why "A2A v1.2" and "A2A, early version" are different engineering conversations.

4. The Agent Card: the contract an agent publishes about itself

The Agent Card is the heart of A2A discovery — a JSON metadata document that describes, machine-readably, what an agent is and how to talk to it: its identity, skills, service endpoints, and — critically — its authentication requirements, declared in a securitySchemes field.

By convention, an agent publishes its card at a well-known URI on its host, so a client that knows only the agent's domain can fetch the card and learn everything else. The discovery flow is deliberately HTTP-shaped: resolve the host, GET the card, read the capabilities, call the agent.

What goes in the card is an architectural decision, not a formality. A minimal, honest card:

{
  "name": "Claims Adjudicator Agent",
  "description": "Adjudicates submitted insurance claims against policy rules and returns an approve / deny / review decision with rationale.",
  "version": "2.1.0",
  "url": "https://agents.example-health.com/a2a/claims-adjudicator",
  "preferredTransport": "JSONRPC",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "securitySchemes": {
    "oauth2": {
      "type": "oauth2",
      "flows": {
        "clientCredentials": {
          "tokenUrl": "https://auth.example-health.com/oauth2/token",
          "scopes": {
            "claims:adjudicate": "Submit a claim for adjudication"
          }
        }
      }
    }
  },
  "skills": [
    {
      "id": "adjudicate-claim",
      "name": "Adjudicate a claim",
      "description": "Takes a structured claim payload, returns a decision and rationale.",
      "inputModes": ["application/json"],
      "outputModes": ["application/json"]
    }
  ]
}

Two rules we hold to when authoring cards. First, the description and skill text are read by other agents' models — they are the basis on which a calling orchestrator decides whether this is the right agent for a task. Vague skill descriptions produce wrong delegation decisions; write them as carefully as a tool docstring, because functionally that is what they are. Second, the card is a public contract. Once another team's agent is resolving your card and calling your endpoint, changing a skill's shape is a breaking API change. Version the card, and treat the skills array with the discipline of a published REST schema.

5. The task lifecycle: states, retries, and cancellation

A2A models a unit of delegated work as a task, and a task moves through an explicit state machine. Getting your code to respect that state machine — rather than assuming every call is a fast, synchronous request/response — is most of what separates a dependable A2A client from a fragile one.

The states:

Three consequences your code has to handle deliberately:

• Tasks are not assumed-synchronous. A task can sit in TASK_STATE_WORKING for a long time. A caller subscribes to streaming updates or polls — either way, "I called it and got an answer" is not a safe mental model. A long-running adjudication, a research task, a multi-step workflow handed to a delegate all complete on their own clock.
• INPUT_REQUIRED and AUTH_REQUIRED are not errors. They are the protocol letting an agent pause and ask. Treating them as failures — retrying blindly, surfacing an exception — breaks the interaction model. They are a prompt to supply something and continue the same task.
• Retry semantics are yours to define, and must be idempotency-aware. The protocol gives you task IDs and terminal states, not a blanket "retry on failure" guarantee. A TASK_STATE_FAILED on a task that already had side effects is not safe to blindly resubmit. Decide per skill whether a task is idempotent, and build retry logic that respects the answer. Cancellation exists for the same reason — explicitly cancel a task that is no longer needed rather than leaking the remote agent's resources.

6. Authentication and signed-card verification

A2A's auth model has two layers, and they answer two different questions. Conflating them is a security mistake.

Layer one — transport authentication — answers "may this caller invoke this agent?" The agent declares its accepted schemes in the card's securitySchemes field — the standard set: API keys, HTTP authentication, OAuth 2.0, OpenID Connect, and Mutual TLS. Credentials are exchanged out of band; A2A composes with the identity system you already run rather than inventing one. For internal, high-trust, service-to-service traffic, mTLS is the strong default — both ends present certificates, and the channel is mutually authenticated before any task is submitted. For cross-organizational calls, OAuth 2.0 client-credentials is the common shape, with the calling agent holding a credential scoped to exactly the skills it is allowed to invoke.

Layer two — Agent Card signing — answers "is this card telling me the truth?" This is the layer teams skip, and the one v1.2 formalizes. The threat: an Agent Card is a public JSON document asserting an agent's endpoints, capabilities, and security requirements. Fetch a card over a compromised path and trust it unverified, and you are trusting an attacker's description of where to send your data and what credentials to attach. Card signing closes that — the publisher signs the canonicalized card document with a private key, and the consumer verifies the signature against the publisher's public key before trusting a single field.

The discipline that makes this real in production: pin publisher keys through a channel you already trust (your secret manager, a key registry), verify on every card fetch rather than caching a once-verified card forever, and fail closed — a card that does not verify is a card you do not call.

7. Cross-vendor handshake: an ADK agent calling a ServiceNow agent

This is the pattern A2A exists for, and the one we build for clients: an agent on the Gemini Enterprise Agent Platform delegating a unit of work to an agent on an entirely different vendor's platform. Concretely — an ADK orchestrator that needs to open and track an IT incident hands that task to a ServiceNow agent, and neither side knows the other's internals.

The handshake is five steps, in a fixed order. Discovery: the ADK agent resolves the ServiceNow agent's well-known URI and fetches its Agent Card — endpoint, skills, transport preference, securitySchemes. Verification: before trusting any of that, it verifies the card's signature against ServiceNow's published public key; a card that fails verification stops here. Credential acquisition: the card's securitySchemes says OAuth 2.0 client-credentials, so the agent acquires a token from the declared endpoint, scoped to exactly the skill it intends to call — out of band, through the OAuth provider, not through A2A. Task submission: it submits a task over the card's preferred transport, bearer token attached and trace context propagated (section 8 — not optional). Lifecycle tracking: the task returns TASK_STATE_SUBMITTED, moves to TASK_STATE_WORKING, and the agent tracks it to a terminal state, handling INPUT_REQUIRED as an interrupt rather than a failure.

In ADK, the calling side is wired as a tool on the orchestrator — the remote A2A agent is exposed to the model as something it can invoke, like any local function tool. A pared-down version of the client logic:

import httpx
from google.adk.agents import LlmAgent
 
A2A_CARD_URL = "https://agents.servicenow.example.com/.well-known/agent-card.json"
 
 
async def delegate_to_servicenow_agent(incident_summary: str) -> dict:
    """Open and track an IT incident via the ServiceNow A2A agent.
 
    Discovers the remote agent, verifies its signed card, acquires a
    scoped token, submits the task, and tracks it to a terminal state.
    """
    async with httpx.AsyncClient(timeout=30.0) as http:
        # 1. Discovery — fetch the Agent Card from the well-known URI.
        card = (await http.get(A2A_CARD_URL)).json()
 
        # 2. Verification — never act on an unverified card. `verify_card`
        #    canonicalizes the document and checks the §8.4 signature
        #    against ServiceNow's pinned public key. Failure raises.
        verify_card(card, trusted_keys=load_trusted_keys("servicenow"))
 
        # 3. Credentials — out-of-band OAuth 2.0 client-credentials,
        #    scoped to exactly the skill we intend to call.
        token = await acquire_oauth_token(
            token_url=card["securitySchemes"]["oauth2"]["flows"][
                "clientCredentials"
            ]["tokenUrl"],
            scopes=["incident:create"],
        )
 
        # 4. Task submission — bearer token attached, trace context
        #    propagated across the vendor boundary (see section 8).
        submit = await http.post(
            card["url"],
            headers={
                "Authorization": f"Bearer {token}",
                "traceparent": current_trace_context(),
            },
            json={
                "jsonrpc": "2.0",
                "method": "message/send",
                "id": 1,
                "params": {
                    "message": {
                        "role": "user",
                        "parts": [{"kind": "text", "text": incident_summary}],
                    }
                },
            },
        )
        task = submit.json()["result"]
 
        # 5. Lifecycle — poll to a terminal state. INPUT_REQUIRED and
        #    AUTH_REQUIRED are interrupts to handle, not failures.
        return await track_task_to_completion(
            http, card["url"], task["id"], token
        )
 
 
# The remote agent is exposed to the orchestrator's model as a tool —
# the model decides when delegation to ServiceNow is the right move.
orchestrator = LlmAgent(
    name="it_ops_orchestrator",
    model="gemini-2.5-flash",
    instruction=(
        "You triage IT requests. When a request requires opening or "
        "updating an incident ticket, delegate it to the ServiceNow "
        "agent via the delegate_to_servicenow_agent tool."
    ),
    tools=[delegate_to_servicenow_agent],
)

The code is not the interesting part — the sequence is. Discovery, verification, scoped credentials, a submission carrying trace context, lifecycle tracking that respects the state machine. A handshake that skips verification or treats the task as synchronous will pass a demo and fail a production incident. For a worked, full-depth version inside a real workflow, the claims processing adjudication blueprint is built around an A2A handoff between a router agent and an adjudicator.

8. What production-grade A2A requires

The wire protocol gets you a working handshake. It does not get you a production system. Four things have to be added on top, and their absence is how you tell a real A2A practice from a protocol citation.

Trace propagation across the boundary. When an ADK orchestrator calls a ServiceNow agent and something is slow or wrong, you need one distributed trace spanning both agents — not two disconnected traces you correlate by hand at 2 a.m. That means propagating W3C trace context (traceparent) on every request, and the remote side continuing the trace rather than starting a new one. A2A does not do this for you; your instrumentation has to.

Explicit error and task-state handling. Every terminal state needs a defined behavior. TASK_STATE_FAILED on an idempotent task: retry with backoff. On a non-idempotent task: surface, do not retry. TASK_STATE_REJECTED: route elsewhere or escalate. A system that maps every state to an explicit action is sound; one with a generic catch-all for "not completed" is not.

Registry enrollment. A2A makes agents callable; it does not make them discoverable at organization scale. An agent not enrolled in your Agent Registry is one your platform team cannot see, govern, or inventory. Production A2A means every agent — yours and the cross-vendor ones you depend on — has a registry entry, so the estate is a managed inventory rather than a set of URLs passed around in documentation.

Model Armor on the traffic. A2A is a channel over which prompts and tool outputs cross a trust boundary. It needs the same content inspection as any other model-adjacent surface — prompt-injection screening on what comes back, sensitive-data inspection on what you send out. Wrapping A2A traffic with Model Armor is what makes a cross-vendor call safe to put in front of a security review, especially in regulated settings where what crosses the boundary might be PHI or PII.

These four are the Govern and Scale pillars doing their job around the protocol. The Gemini Enterprise Agent Platform overview maps how Build, Scale, Govern, and Optimize fit together; treating A2A interop as "just the protocol" is the mistake that produces an ungoverned agent estate.

9. Common architecture patterns

Three shapes cover most A2A systems, and picking the right one is an early decision with long consequences.

1. Orchestrator and delegates. One coordinating agent owns the workflow and delegates sub-tasks to specialist agents over A2A. The orchestrator holds the state and sequence; the delegates are workers. This is the most common enterprise shape — the one in the ServiceNow handshake above — easy to reason about, easy to govern, with the orchestrator as a clear single point of observability.
2. Peer mesh. Agents call each other directly, with no central coordinator. More flexible, appropriate when there is genuinely no natural owner of the workflow — but the observability and governance cost is real, because there is no single place the whole interaction is visible. Choose it deliberately.
3. Event-sourced. Agents communicate through an event log rather than direct calls — an agent emits an event, interested agents react. This decouples agents in time and gives you a durable, replayable record of every delegation. The trade-off: control flow is implicit in the event graph rather than explicit in an orchestrator.

Start with orchestrator-and-delegates and move to a mesh or event-sourced shape only when a specific requirement forces it. That pattern's legibility — one agent, one trace root, one governance choke point — is worth a lot, and "we might need more flexibility later" is not a reason to give it up on day one.

10. Governance: how the registry and Model Armor wrap A2A

A2A traffic is not exempt from governance because it is "just agents talking." If anything it needs more scrutiny — it is the traffic that leaves your control boundary.

The Agent Registry is the inventory layer. Every agent, in-house or cross-vendor, is enrolled, so the platform team has a single answer to "what agents exist, what can they call, what calls them." Without it, A2A's ease of connection becomes a liability: agents proliferate, integrations multiply, and nobody owns the map.

Model Armor is the content-inspection layer on the traffic itself. A2A requests carry prompts; responses carry model-generated content and tool outputs. Both directions are an attack surface — a compromised remote agent can return a prompt-injection payload; a poorly scoped local agent can leak sensitive data outward. Model Armor inspects both, and in regulated environments it is also where PHI and PII redaction happens before anything crosses the boundary.

Together they answer the security team's real question — not "is the protocol secure" but "can you see and control what your agents are doing." That is the question our enterprise governance approach is built to answer: governance enrolled and enforced from the first deploy, not retrofitted when a launch gets blocked.

11. When NOT to use A2A

A protocol guide that only tells you when to adopt is a sales document. The honest negative space — three cases where A2A is the wrong tool.

A single-vendor stack. If every agent you have and plan to have is an ADK agent on the Gemini Enterprise Agent Platform, the in-framework composition primitives — ADK's own sub-agent and agent-as-tool patterns — are simpler and lower-latency than an A2A boundary between two agents in the same runtime. A2A's value is crossing a boundary; with no boundary, you are paying for interoperability you do not use. The nuance: if you expect a cross-vendor agent later, exposing a clean A2A surface early can be a reasonable hedge.

Low-frequency, simple calls. If agent A needs something from agent B once an hour and the request is simple and stable, a plain authenticated REST call is fine. A2A's task lifecycle, card discovery, and signing machinery earn their cost when delegation is frequent, the work is long-running, or the set of agents is dynamic. For a low-frequency point-to-point call, it is overhead.

Pure RAG with no delegation. If your "agent" retrieves documents and generates an answer and never hands a unit of work to another autonomous agent, there is no agent-to-agent interaction to standardize. A2A is for delegation between agents; a retrieval pipeline is not that.

The throughline: A2A is the right answer when you have genuine multi-agent, multi-owner, cross-boundary delegation — and then it is the right answer decisively. When you do not, reaching for it is architecture for its own sake.

12. What a partner has to demonstrate to claim "A2A in production"

Because A2A is easy to name and hard to ship, the evaluation question for a consultancy is concrete. A partner who has genuinely shipped A2A can show you, specifically:

• A working cross-vendor handshake — not a diagram. An agent on one platform calling an agent on a different vendor's platform, with discovery, verification, and lifecycle steps real and running.
• Their signed-card verification flow — how they pin publisher keys, when they verify, what "fail closed" means in their implementation.
• Their task-state handling — the explicit mapping from each terminal state to a defined behavior, and how they handle idempotency for retries.
• Their trace propagation — one distributed trace spanning the vendor boundary, demonstrated on a real call.
• Their governance wiring — registry enrollment for every agent and Model Armor on the traffic.

A partner who can walk all five has built it. One who can only cite the protocol and show an architecture slide has read about it. That distinction is the point of asking — and it is the standard Zinch holds itself to, including through our participation in the Linux Foundation A2A working group. The agent blueprints catalog is the worked-example library; the Zinch engineering approach is the team and standards behind it.

A2A is a small protocol with a large consequence: the difference between an agent estate you can grow across vendors and clouds, and one locked to whatever you standardized on first. The protocol is public and free. Running it so it survives a security review and a production incident is the part worth getting right — and the part worth choosing a partner for.

If your agent roadmap has a second agent in it — built by a different team, on a different platform, or by a vendor you do not control — that is the moment A2A stops being interesting and starts being load-bearing. Talk to us about the cross-vendor pattern before it is bespoke glue you cannot maintain.

13. FAQ