A2A Protocol Guide 2026: Cross-Cloud Agent Communication for Enterprise

What is the A2A (Agent-to-Agent) protocol?

In short

A2A is an open, HTTP-based protocol that lets AI agents built on different frameworks, clouds, or vendors discover each other, authenticate, and delegate tasks. It launched at Google Cloud in April 2025, moved to the Linux Foundation in June 2025, and reached v1.0 in April 2026.

The Agent-to-Agent (A2A) protocol was introduced by Google Cloud in April 2025 with 50+ enterprise launch partners — Salesforce, SAP, Accenture, Deloitte, and a long tail of systems integrators and ISVs. In June 2025, Google donated the protocol, specification, SDKs, and reference tooling to the Linux Foundation, which established the Agent2Agent Project for vendor-neutral governance.

The v1.0.0 stable specification was released in April 2026, one year after launch. It is published at a2a-protocol.org and is the canonical source of truth for every implementation. Alice Labs treats the Linux Foundation spec — not any vendor's SDK documentation — as the primary reference for client work.

Mechanically, A2A is an HTTP protocol with three transport bindings — JSON-RPC 2.0, gRPC, and HTTP+JSON/REST — plus Server-Sent Events (SSE) for streaming updates and webhooks for push notifications on long-running tasks. There is no proprietary wire format. Any HTTP-capable runtime can implement it.

The critical distinction most enterprise teams get wrong: A2A is not a replacement for the Model Context Protocol (MCP). A2A standardizes how agents communicate with other agents. MCP standardizes how a single agent communicates with tools, data, and APIs. Both layers are typically used together in production — covered in detail in the A2A vs MCP section below.

For a broader survey of the frameworks A2A connects, see our best AI agent frameworks guide for 2026 — every framework in that comparison now ships some form of A2A support.

A2A spec v1.0: core objects and lifecycle

In short

The A2A v1.0 spec defines five core objects — Task, Message, Part, Artifact, and Agent Card — and eight Task lifecycle states. Three transport bindings maintain functionally equivalent representations of the same data model.

The A2A v1.0 data model is deliberately small. Five core objects, one lifecycle state machine, and one versioning header. That minimalism is what makes cross-framework interoperability tractable.

The five core objects:

• Task: The unit of work an agent performs. Every A2A interaction is a Task with a state, inputs, and outputs.
• Message: A single turn in the conversation between client and agent. Carries a role (USER or AGENT) and an array of Parts.
• Part: The atomic content unit inside a Message — text, bytes (files), URL references, or structured JSON.
• Artifact: A durable output produced by a Task — a report, a structured record, an image, or any file the agent generates.
• Agent Card: The JSON discovery document that declares an agent's identity, endpoint, skills, and supported authentication schemes.

Task lifecycle states are strict: SUBMITTED → WORKING → INPUT_REQUIRED → AUTH_REQUIRED → COMPLETED / FAILED / CANCELED / REJECTED. State transitions are the observability surface — every production A2A mesh Alice Labs has deployed logs every transition to an OpenTelemetry-compatible backend.

Versioning uses an A2A-Version HTTP header in Major.Minor format. v1.0 removed the "kind discriminator" field, relocated several extended card fields, and made other breaking changes documented in Appendix A of the specification's migration guide. Teams upgrading from 0.2.x or 0.3.x should walk that guide before pushing v1.0 to production.

All three transport bindings — JSON-RPC 2.0, gRPC, and HTTP+JSON/REST — carry the same Task/Message/Part/Artifact model. The spec calls them "functionally equivalent" and that equivalence is enforced by conformance tests: an Artifact produced by a gRPC agent round-trips cleanly through a JSON-RPC client.

A2A v1.0 Task Lifecycle States

Agent Cards: how agents discover each other

In short

Agent Cards are JSON documents published at /.well-known/agent-card.json that declare an agent's identity, endpoint, skills, and auth schemes. v1.0 introduced Signed Agent Cards using JSON Web Signature (JWS) for cryptographic identity verification.

Discovery is the feature that makes A2A worth adopting. Without it, every integration is still a bespoke contract negotiated by humans. With it, an orchestrator can query a registry, retrieve capability metadata, and delegate work at runtime — no code change required.

An Agent Card is a JSON document served at a well-known path — canonically /.well-known/agent-card.json on the agent's own host. It declares:

• Identity — human-readable name, description, provider org
• Endpoint URL — where clients POST Task requests
• Skills — capability tags an orchestrator can match against
• Input/output modalities — text, files, structured JSON, streaming
• Supported authentication schemes — advertised, not enforced
• Extensions — optional protocol extensions the agent implements

v1.0 introduced Signed Agent Cards using JSON Web Signature (JWS). A signed card carries a detached JWS that a client can verify against a known issuer public key. This closes a class of impersonation attacks that plagued 0.x implementations — an attacker could previously host a card claiming to be another agent's endpoint, and clients had no cryptographic recourse.

Signing is supported but not enforced by the protocol. The spec explicitly leaves signing enforcement to implementers. Alice Labs' default posture for enterprise deployments: unsigned Agent Cards are acceptable only in a single-team development environment; production and staging require signed cards with a pinned trusted-issuer list.

Registries — separate infrastructure, not part of the core protocol — let orchestrators list many agents, query by capability tag, and receive freshness/health signals. Several cloud vendors ship first-party registries (Vertex AI Agent Builder, Azure AI Foundry), and open-source registries exist for self-hosted meshes.

A2A transport methods: JSON-RPC, gRPC, and REST

In short

A2A v1.0 defines three transport bindings: JSON-RPC 2.0 over HTTP or WebSocket (reference), gRPC (typed streaming), and HTTP+JSON/REST. All three carry the same Task and Artifact model. SSE handles streaming; webhooks handle push notifications.

The three transport bindings exist because enterprise teams have different existing infrastructure. Forcing a choice between JSON-RPC and REST would have blocked adoption in shops that had standardized on one or the other. The spec's promise of functional equivalence — the same Task round-trips through each transport — is what makes multi-transport meshes viable.

A2A v1.0 Transport Bindings Compared

Server-Sent Events (SSE) is the default streaming mechanism — a Task in the WORKING state can push incremental updates (partial Artifacts, thought traces, tool-call results) to the caller over a single long-lived HTTP response. For long-running Tasks that outlive a client connection, webhooks let the agent POST completion notifications to a caller-registered URL.

Alice Labs' default for enterprise deployments is JSON-RPC 2.0 over HTTPS with SSE for streaming. The reason is boring but decisive: it drops into existing API gateway, authentication, and observability stacks without any custom infrastructure. gRPC becomes the right choice when the agent is inside a service mesh (Istio, Linkerd) that already carries other gRPC traffic.

A2A vs MCP: two protocols, two layers

In short

MCP connects one agent to tools, databases, and APIs. A2A connects multiple agents so they can delegate tasks to each other across boundaries. Production multi-agent systems typically use both: MCP inside each agent for tool access, A2A between agents for coordination.

The most common architectural mistake Alice Labs encounters during A2A adoption reviews: teams treat A2A and MCP as competing standards and pick one. They solve different layers. Picking one leaves half the stack unstandardized.

A2A vs MCP: What Each Standardizes

The reference pattern shipped in every A2A launch talk since April 2025: a retail inventory agent uses MCP to check stock in its own warehouse database, then uses A2A to delegate a purchase order to a supplier's remote agent. MCP handles the internal tool call. A2A crosses the organizational boundary.

The two protocols also compose cleanly. Every agent exposed over A2A should have its own MCP-based tool belt on the inside — that way, callers do not need to know anything about the internal tools, and internal tools can be swapped without breaking the external contract.

For a deeper walk-through of the framework matrix that consumes both protocols, see our best AI agent frameworks guide for 2026.

Cross-cloud agent communication with A2A

In short

A2A has GA support inside Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore Runtime, and Google Vertex AI Agent Builder. Cross-cloud calls are plain HTTPS, so existing cloud networking controls — private endpoints, VPC peering, egress rules — still apply.

The enterprise pain A2A actually solves: an agent built on one cloud's stack cannot easily call an agent built on another cloud's stack. Every pair of vendors had a different way to expose agents, a different auth model, and a different way to stream partial results. That N-squared integration problem is what the Linux Foundation's April 2026 update explicitly targeted.

As of April 2026, GA support ships inside:

• Microsoft Copilot Studio and Azure AI Foundry — both outbound (call remote A2A agents as tools) and incoming (expose Foundry agents as A2A endpoints, public preview announced at Microsoft Build 2026).
• Amazon Bedrock AgentCore Runtime — first-party A2A hosting for agents deployed on Bedrock.
• Google Vertex AI Agent Builder — native A2A hosting plus client SDKs (Google's original launch surface).

The Technical Steering Committee of the Agent2Agent Project includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow. Governance is genuinely vendor-neutral — no single cloud can unilaterally change the wire format.

Cross-cloud calls remain plain HTTP requests. That is deliberate and important: standard cloud networking still applies. Private endpoints, VPC peering, egress rules, WAF policies, and API gateways all work exactly as they do for any other HTTP service. A2A does not require any new network primitive.

Alice Labs has shipped 100+ production AI implementations including multi-cloud A2A orchestrations that span Azure, AWS Bedrock, and Google Vertex — typically with a LangGraph orchestrator on one cloud delegating to specialist agents on the others. The engineering pattern is straightforward once the security controls are set: mTLS + OIDC on the ingress, signed Agent Cards on discovery, OpenTelemetry on every Task state transition.

A2A in Microsoft Agent Framework (.NET and Python)

In short

Microsoft shipped A2A v1 support in the Microsoft Agent Framework for .NET on April 28, 2026, with Python parity in agent-framework-a2a on July 30, 2026. Two package roles exist: A2A Agent (client-side) and A2A Hosting (server-side).

Microsoft Agent Framework (MAF) was one of the fastest movers on A2A v1. The .NET SDK landed A2A v1 support on April 28, 2026 — days after the protocol went stable — and the Python SDK reached parity on July 30, 2026.

MAF splits A2A into two package roles you compose depending on which side of the wire you are on:

• A2A Agent (client-side): Lets a MAF orchestrator consume a remote A2A agent as if it were any other AIAgent instance. The client uses A2ACardResolver to fetch and verify the remote Agent Card, then invokes Tasks against the returned agent.
• A2A Hosting (server-side): Exposes a MAF agent as an A2A endpoint that any A2A-compliant client can call. The .NET pattern is services.AddA2AServer(agent) then app.MapA2AHttpJson("/a2a") and app.MapWellKnownAgentCard().

The Foundry integration goes further. Azure AI Foundry supports both outbound A2A (Foundry agents calling remote A2A agents as tools) and incoming A2A (Foundry agents exposed as A2A endpoints, in public preview at Microsoft Build 2026). This is the surface Alice Labs uses most often for Nordic enterprise clients — Foundry provides the managed hosting, MAF provides the code, A2A provides the wire.

A minimal .NET hosting example — the shape of code MAF ships in its A2A samples:

// ASP.NET Core — expose a MAF agent as an A2A endpoint
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddA2AServer(agent);      // registers the A2A hosting layer

var app = builder.Build();

app.MapA2AHttpJson("/a2a");                // JSON-RPC 2.0 endpoint
app.MapWellKnownAgentCard();               // /.well-known/agent-card.json

app.Run();

On the client side, consuming a remote A2A agent is a two-step: resolve the card, invoke:

// Client-side — consume a remote A2A agent as an AIAgent
var resolver = new A2ACardResolver("https://partner.example.com");
AIAgent remote = await resolver.GetAgentAsync();

var response = await remote.RunAsync("Draft a supplier purchase order for SKU 1029");

For a deeper look at how MAF composes agents into full applications — before you get to A2A — see our best AI agent frameworks guide for 2026 and the surrounding framework deep-dives.

A2A in LangGraph and Google ADK

In short

LangSmith Agent Server exposes A2A at /a2a/{assistant_id} out of the box. Google ADK ships first-party A2A hosting and is the reference implementation for streaming Task updates. LangGraph orchestrators can delegate subtasks to peer A2A agents via a registry lookup and JSON-RPC 2.0 call.

LangGraph and Google ADK — the two most-used orchestration frameworks alongside Microsoft Agent Framework — both ship first-party A2A support. Between them and MAF, almost any polyglot enterprise mesh is buildable without custom protocol code.

LangGraph. LangSmith Agent Server exposes an A2A endpoint at /a2a/{assistant_id} for every deployed LangGraph assistant. That means any A2A-compliant client can call a LangGraph agent without knowing anything about LangGraph itself. On the orchestrator side, a LangGraph node can query a registry, match a Task against capability tags in remote Agent Cards, and invoke the winning agent via JSON-RPC 2.0. A community feature request is open for making remote A2A agents first-class LangGraph sub-graphs (with checkpointing and state sharing across the wire), but that is not yet native.

For the LangGraph fundamentals A2A sits on top of, see our LangGraph tutorial for 2026.

Google ADK. The Google Agent Development Kit ships first-party A2A hosting and is the reference implementation Google's own launch demos use for streaming Task updates. ADK research agents were the canonical example at Google Cloud Next 2025 and remain the highest-quality reference for SSE-based partial-result streaming over A2A.

A reference multi-framework topology Alice Labs has deployed for European clients:

• LangGraph orchestrator hosted on Azure — receives the user request, decides which specialist to invoke, checkpoints state to PostgreSQL.
• Google ADK research worker hosted on Vertex — invoked over A2A when the request needs deep web research; streams partial findings back via SSE.
• MAF domain worker hosted on AWS Bedrock — invoked over A2A when the request needs domain-specific action inside a Microsoft-centric enterprise system.

All three communicate over A2A v1.0 with signed Agent Cards and mTLS. No custom protocol code exists anywhere in the mesh — every hop uses framework-native A2A packages.

A2A in CrewAI and other frameworks

In short

CrewAI ships A2A adapters so one Crew can be exposed as a standardized endpoint. Semantic Kernel, .NET code, CrewAI, and commercial CRM agents (Salesforce Agentforce, ServiceNow AI Agents) all interoperate over A2A. SDK coverage as of Q2 2026: Python, JavaScript, Java, Go, and .NET.

Beyond MAF, LangGraph, and ADK, the framework matrix that speaks A2A has expanded significantly in the year since launch. As of Q2 2026 the picture is:

• CrewAI — first-party A2A adapters. One Crew can be exposed as a standardized A2A endpoint that another Crew (or any other framework) can call. See our CrewAI guide for 2026 for role-based agent patterns that pair well with A2A across-Crew delegation.
• Semantic Kernel and custom .NET code — via the same MAF-adjacent A2A packages Microsoft ships.
• IBM watsonx.ai — A2A adapters for LangGraph-backed agents.
• Salesforce Agentforce and ServiceNow AI Agents — commercial CRM and ITSM agents exposing A2A endpoints for enterprise integration.

SDK coverage across languages is now production-grade in five: Python, JavaScript, Java, Go, and .NET. That covers essentially every enterprise runtime an AI team is likely to standardize on.

The important architectural point: any HTTP-capable runtime can implement A2A. There is no framework lock-in. A team could write an A2A agent in Rust with no framework at all, and a LangGraph orchestrator would call it exactly the same way as any other A2A endpoint. This is the level of freedom that distinguishes A2A from earlier, vendor-controlled agent APIs.

For teams still choosing which orchestration framework to standardize on — before worrying about A2A between them — start with our best AI agent frameworks guide for 2026 and the LangGraph vs CrewAI vs AutoGen comparison.

A2A authentication and security schemes

In short

A2A supports six auth schemes: APIKey, HTTP Basic, HTTP Bearer, OAuth 2.0 (three flows), OpenID Connect, and mutual TLS. Schemes are advertised in the Agent Card but not enforced by the protocol — credential acquisition is delegated to implementers via out-of-band flows.

Security in A2A is a discoverable contract, not an enforced mandate. The Agent Card declares which schemes an agent supports; the protocol does not mandate that the agent actually verifies them. That means implementer discipline determines whether an A2A mesh is safe.

The six supported authentication schemes:

• APIKey — simple bearer token, minimum bar for dev/staging
• HTTP Basic — legacy, discouraged for new deployments
• HTTP Bearer — bearer token in Authorization header
• OAuth 2.0 — three flows supported: authorization code, client credentials, device code
• OpenID Connect — identity layer on top of OAuth 2.0
• Mutual TLS (mTLS) — certificate-based mutual authentication, highest bar

The Agent Card exposes supported schemes via AgentCard.securitySchemes and required scopes via AgentCard.security. Clients read those fields, obtain credentials via the appropriate out-of-band process (OAuth authorization redirect, mTLS certificate issuance, etc.), and present them on Task submission.

Alice Labs' default recommendation for enterprise deployments crossing organizational boundaries: OpenID Connect for user identity plus mTLS for service identity. OIDC handles delegated user authorization (the human's consent flows through to the downstream agent). mTLS handles machine-to-machine trust (the calling service proves it is who it says it is at the transport layer). Together, they satisfy the auth requirements of every regulated Nordic and European client we have shipped for.

A2A security risks and mitigations

In short

Named A2A risks include agent impersonation, Agent Card tampering, replay attacks, webhook SSRF, and context poisoning. Mitigations: enforce signed Agent Cards, pin trusted issuers, validate JWS on every fetch, gate webhook targets by allowlist, and log every Task state transition.

The security literature on A2A matured quickly once v1.0 shipped. Palo Alto Networks and Tyk both published threat models in 2026 that name the specific classes of attack an orchestrator must control for. Every one of these is addressable — but only if the controls are designed in from day one.

A2A Security Risks and Mitigations

McKinsey's 2025 framing of the five agent risks — uncontrolled autonomy, fragmented access, low observability, expanding attack surface, and agent sprawl — all apply to A2A meshes at scale. A registry of 30+ agents with untracked owners is where these risks compound.

For the broader security posture that A2A slots into, see our AI agent security risks guide.

A2A enterprise use cases in production (2026)

In short

The Linux Foundation reports active A2A production deployments in supply chain, financial services, insurance, and IT operations as of April 2026. Common patterns: cross-organizational purchase orders, claims triage delegation, incident triage across cloud boundaries, and 60+ payments partners backing the AP2 layer.

The Linux Foundation's one-year update in April 2026 named four verticals with active A2A production deployments: supply chain, financial services, insurance, and IT operations. Each has settled on a recognizable pattern.

A2A Production Patterns by Vertical (April 2026)

The financial services momentum is the loudest signal. The Agent Payments Protocol (AP2) launched in September 2025 with Google and Coinbase, and by April 2026 had 60+ partner organizations including Adyen, American Express, Mastercard, MetaMask, PayPal, Revolut, Salesforce, and Worldpay. AP2 layers cryptographic payment mandates on top of A2A — the payment agents talk to each other over A2A, and the mandate is the payload.

Alice Labs' Nordic client work in the same window has concentrated on IT operations (incident triage across Azure, AWS, and on-premise clouds for a Swedish energy client) and supply chain (multi-tier supplier delegation for a Nordic retail group). The engineering complexity has been much lower than the security and governance work — a recurring pattern in every A2A production project we have shipped.

Agent Payments Protocol (AP2) and the x402 extension

In short

AP2 launched September 2025 with Google + Coinbase and 60+ partners; it uses cryptographic mandates so agents can autonomously execute payments with verifiable trust. The A2A x402 extension (co-developed with Coinbase and MetaMask) carries crypto payment authority alongside traditional card rails.

The Agent Payments Protocol (AP2) is the fastest-moving A2A extension surface. It launched in September 2025 with Google and Coinbase leading, and by April 2026 had 60+ partners across issuers, networks, wallets, and platforms — Adyen, American Express, Mastercard, MetaMask, PayPal, Revolut, Salesforce, Worldpay, and more.

The core primitive is a cryptographic mandate: a signed authorization an agent carries that lets it execute a payment within specific bounds (amount, payee, time window) without further human approval. Mandates travel as A2A message parts; payment agents on either side verify signatures before acting.

The A2A x402 extension, co-developed with Coinbase and MetaMask, is the crypto rail. It carries payment authority for on-chain settlement alongside traditional card rails. Reference implementations live at github.com/google-a2a/a2a-x402 and are production-ready for crypto flows today.

Card-based AP2 flows are further from production. Issuer support is still maturing, and the risk models for agent-initiated card payments are being negotiated inside each network. As of Q3 2026, x402 crypto flows are the fastest path to production for agentic commerce; card-based AP2 will follow as issuers publish their agent-payment policies.

Alice Labs' guidance for enterprise clients evaluating AP2: treat it as a strategic surface to prototype on, but do not put mandated agent payments on the critical path of a live business process until your finance, legal, and compliance functions have signed off on the specific mandate scope. The technology is ahead of the governance in most large enterprises today.

When to use A2A vs in-process agent composition

In short

Use A2A when agents cross a service, team, cloud, or organizational boundary. Skip A2A when all agents live in the same process and are owned by the same team — agents-as-tools has less overhead. Alice Labs' rule: A2A between crews, agents-as-tools inside a crew.

Not every multi-agent system needs A2A. The most common over-engineering mistake we see in Alice Labs' architecture reviews is teams putting HTTP hops between agents that live in the same Python process, owned by the same team, deployed to the same container.

The decision framework we use:

• Use A2A when agents cross a service boundary (different deployment units), a team boundary (different owners), a cloud boundary (Azure ↔ AWS ↔ GCP), or an organizational boundary (your company ↔ a partner).
• Skip A2A when all agents live in the same process, are owned by the same team, and are deployed together. Use your framework's native agents-as-tools pattern instead — LangGraph sub-graphs, MAF handoffs, CrewAI role composition.

The overhead A2A adds is real. Every A2A call is an HTTP round-trip — roughly 10–100ms of latency depending on network topology, plus serialization overhead on both ends. In-process function calls are microseconds. When a supervisor delegates to a specialist five times per user turn, the difference between in-process and A2A can be the difference between a snappy UX and a slow one.

The other subtle cost: remote agents own their conversation state. A restarted remote agent can lose context that a client thought was preserved. Same-process agents share memory directly and do not have this failure mode.

Alice Labs' rule of thumb, distilled from 100+ implementations: A2A between crews, agents-as-tools inside a crew. A crew is a bounded team of agents built and deployed together. Inside a crew, use your framework's native composition. Between crews — where a different team, different repo, or different cloud is involved — reach for A2A.

For patterns on in-process multi-agent composition, see our multi-agent systems guide and our AI agent orchestration deep-dive.

Alice Labs A2A implementation playbook

In short

Five production practices from Alice Labs' 100+ implementations: start with a registry not point-to-point, enforce signed Agent Cards from day one, pair A2A with MCP inside every agent, instrument every Task state transition, and gate EU A2A endpoints with mTLS + OIDC for AI Act Article 12 compliance.

Alice Labs has shipped A2A meshes into regulated Nordic and European enterprises across energy, financial services, retail, and public sector. Every project has surfaced variations of the same five lessons.

1. Start with a registry, not point-to-point. Even three agents benefit from a discovery layer — it removes hard-coded URLs, enables capability-based routing, and gives you a single place to enforce policy. Retrofitting a registry into a point-to-point mesh is painful; adding one on day one costs a day.
2. Enforce signed Agent Cards from day one. Unsigned cards are acceptable only in a single-team development environment. Production, staging, and anything a partner can call requires signed cards with a pinned trusted-issuer list. This is a two-line policy in most gateways.
3. Pair A2A with MCP. Give every A2A-exposed agent its own MCP-based tool belt. Callers should not need to know anything about internal tools, and internal tools should be swappable without breaking the external contract. This separation is what makes A2A endpoints stable over time.
4. Instrument every Task state transition. Log SUBMITTED, WORKING, INPUT_REQUIRED, AUTH_REQUIRED, COMPLETED, FAILED, CANCELED, and REJECTED to your observability stack. OpenTelemetry Agent semantic conventions are stabilizing in 2026 and are the recommended shape. Without this instrumentation, debugging a cross-cloud A2A mesh is guessing.
5. For EU deployments, gate A2A endpoints with mTLS + OIDC. Log Task inputs, outputs, and state transitions with sufficient granularity to satisfy EU AI Act Article 12 (record-keeping obligations for high-risk AI systems). This is the single most-asked question from Nordic legal teams during A2A rollouts.

None of this is exotic. Every practice on this list is standard security and platform engineering applied to a new surface. The A2A protocol makes the surface possible; the playbook makes it safe to run.

For the broader EU AI Act context these controls satisfy, see our EU AI Act compliance checklist for 2026.