Agent-to-agent (A2A) integration for the enterprise
A2A lets agents built on different platforms delegate work to each other without exposing their internals. Integration teams already know this problem: it is B2B, with agents instead of trading partners.
MCP gives an agent tools. It does not help when the thing on the other side is another agent with its own model, memory and permissions, run by another team, another vendor or another company. That is the gap the Agent2Agent (A2A) protocol fills. Google announced it in April 2025, donated it to the Linux Foundation that June, and the community shipped v1.0 in March 2026. In August 2026 it joined MCP under the Agentic AI Foundation.
For integration architects the mental model is familiar. A2A is to agents what AS2 and EDI were to trading partners: a contract for discovering a counterparty, exchanging messages and tracking a long-running business transaction, while each side keeps its internals private.
Four concepts you need
| Concept | What it is | B2B analogy |
|---|---|---|
| Agent Card | JSON metadata describing an agent: name, skills, endpoints, supported bindings, security schemes, optional signatures | Partner profile / trading partner agreement |
| Message | A turn from a user or agent, made of parts (text, raw bytes, URL or structured data) | A business document |
| Task | The unit of work, with an ID, state, history and artifacts | A purchase order and its lifecycle |
| Artifact | An output the remote agent produces, such as a report or structured result | The response document (order confirmation, invoice) |
The Agent Card
Discovery starts with the Agent Card, usually published at a well-known URL. In v1.0 the card lists supportedInterfaces, each with its own URL, binding and protocol version, so one agent can offer JSON-RPC, gRPC and HTTP+JSON side by side. An abridged example:
{
"name": "Supplier Availability Agent",
"description": "Confirms stock and earliest ship date for catalogue items.",
"version": "2.1.0",
"provider": { "organization": "Example Supplier GmbH", "url": "https://supplier.example.com" },
"supportedInterfaces": [
{ "url": "https://agents.supplier.example.com/a2a", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" },
{ "url": "https://agents.supplier.example.com", "protocolBinding": "HTTP+JSON", "protocolVersion": "1.0" }
],
"capabilities": { "streaming": true, "pushNotifications": true, "extendedAgentCard": true },
"securitySchemes": { "oauth": { "...": "OAuth 2.0 authorization code with PKCE" } },
"defaultInputModes": ["application/json", "text/plain"],
"defaultOutputModes": ["application/json"],
"skills": [
{ "id": "check-availability", "name": "Check availability",
"description": "Stock and ship date for up to 50 SKUs.", "tags": ["inventory", "b2b"] }
],
"signatures": [ { "...": "detached JWS over the canonicalized card" } ]
}Abridged for readability. Validate real cards against the official A2A schema; the Agent Card builder on this site produces a starting draft.
Two v1.0 features matter most for enterprises. Signed cards use JWS over a JSON-canonicalized (RFC 8785) form of the card, so you can verify a card was issued by the organization it claims to come from. And the extended Agent Card lets an agent show a fuller set of skills only to authenticated callers, which is how you avoid advertising internal capabilities to the internet.
Tasks and their lifecycle
Everything in A2A revolves around a task state machine. The v1.0 states are SUBMITTED, WORKING, INPUT_REQUIRED, AUTH_REQUIRED, COMPLETED, FAILED, CANCELED and REJECTED (prefixed TASK_STATE_ on the wire).
Results reach the caller in one of three ways: polling (GetTask), streaming over server-sent events (SendStreamingMessage, SubscribeToTask), or push notifications to a webhook the caller registers. A returnImmediately flag lets the caller choose between waiting and getting a task handle straight away.
Security model
A2A deliberately reuses existing standards rather than inventing an auth scheme. An Agent Card declares its security schemes; v1.0 supports OAuth 2.0 authorization code (with a pkce_required flag), client credentials, the device code flow (RFC 8628), OpenID Connect, API keys and mutual TLS, and it removed the implicit and password flows. The caller authenticates with ordinary HTTP mechanisms, and the remote agent decides what that identity may do.
Three practical rules:
- Verify signatures before trusting a card. An unsigned card fetched over TLS proves the host, not the publisher's intent. Pin keys for important partners.
- Use
AUTH_REQUIREDfor step-up. When a task needs more privilege (approve a credit limit change), pause and re-authorize instead of granting broad scopes up front. - Treat messages from other agents as untrusted input. OWASP lists insecure inter-agent communication (ASI07) and cascading failures (ASI08) among the top agentic risks. A partner agent's response is data, never an instruction to your agent.
Running A2A inside an enterprise
| Concern | Pattern |
|---|---|
| Ingress and egress | Put an agent gateway in front of A2A endpoints, as you would with APIs. agentgateway, Kong AI Gateway and IBM ContextForge proxy A2A natively; AgentCore Gateway fronts A2A targets. |
| Discovery | Run an internal registry of approved Agent Cards. Do not let agents discover and call arbitrary agents on the internet. |
| Multi-tenancy | Use the v1.0 tenant field to separate business units or customers served by one agent deployment. |
| Push notifications | Terminate webhooks on your gateway, authenticate them, and hand them to your event broker (for example SAP Event Mesh or Advanced Event Mesh) rather than exposing agents directly. |
| Long-running tasks | Persist task IDs against the business object (sales order, case) so operations staff can trace and cancel them. |
| Versioning | Clients send an A2A-Version header; servers reject unsupported versions explicitly. Record supported versions in the registry. |
| Observability | Log task ID, caller identity, skill, state transitions and duration. Correlate with MCP tool calls the remote agent makes. |
Where A2A already lives
According to the Linux Foundation's April 2026 update, A2A is integrated into Azure AI Foundry and Copilot Studio, supported through Amazon Bedrock AgentCore Runtime, and native to Google's agent platforms. Its technical steering committee includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow. In SAP's 2026 positioning, A2A is how Joule discovers and delegates to other agents, while MCP is how agents reach governed tools.
The practical consequence: in most enterprises A2A will not be something you implement from scratch. It will be a capability of the agent platforms you already license. The integration team's job is the same as with any new protocol: govern the traffic, inventory the endpoints, and connect the long-running work to the systems of record.
Onboarding an external agent: a checklist
- Obtain the partner's Agent Card and verify its signature against a key exchanged out of band.
- Record the agent in your registry with owner, skills, supported versions, data classification and expiry date.
- Agree scopes per skill; prefer OAuth with PKCE or mTLS over static API keys.
- Route traffic through your agent gateway with quotas and payload size limits.
- Define which task states require human attention (
INPUT_REQUIRED,AUTH_REQUIRED,FAILED) and alert on them. - Test in a sandbox tenant with adversarial messages, including instructions embedded in returned data.
- Agree a kill switch and an incident contact, exactly as you would for an EDI partner.
Frequently asked questions
What is the difference between A2A and MCP?
MCP connects an agent to tools and data it controls; A2A connects an agent to another agent whose internals stay private. A2A tasks can run for a long time and pause for input or authorization.
Which transports does A2A v1.0 support?
Three equivalent bindings: JSON-RPC, gRPC and HTTP+JSON. Results can be polled, streamed over server-sent events, or pushed to a registered webhook.
Are A2A Agent Cards signed?
They can be. A2A v1.0 adds a signatures field holding a detached JWS over a canonicalized form of the card, so callers can verify who issued it.
Is A2A governed by Google?
No. Google donated A2A to the Linux Foundation in June 2025, and in August 2026 it joined the Agentic AI Foundation alongside MCP. A multi-vendor technical steering committee maintains it.
Sources and further reading
- A2A: What's new in v1.0
- Linux Foundation: A2A passes 150 organizations (Apr 2026)
- Forbes: Agent2Agent joins the Agentic AI Foundation
- DX Heroes: What is the A2A protocol?
- OWASP Top 10 for Agentic Applications 2026