Agent-to-agent (A2A) is an open protocol initiated by Google in April 2025 that lets AI agents from different vendors and frameworks discover each other and collaborate on long-running tasks. A2A defines a Task-Based Actor Model — a User sends work to a Client-Agent, which then delegates to one or more Remote-Agents — and a discovery mechanism based on agent cards published at /.well-known/agent.json. This guide explains how A2A works, walks through an example agent card and a task hand-off message, and shows how Vaikora applies inline policy enforcement on every A2A task message before it crosses an organizational boundary.
What Does A2A Stand For?
A2A stands for agent-to-agent. It is an open protocol for AI agent collaboration that lets independently built agents discover each other’s capabilities and exchange tasks across organizational and framework boundaries. The full term “agent-to-agent” and the abbreviation “A2A” are used interchangeably throughout the spec and across the partner ecosystem.
Who Built A2A?
A2A was initiated by Google in April 2025, with broad partner support from Salesforce, SAP, ServiceNow, Atlassian, and a growing list of agent platform vendors. The specification is open and governed publicly, with reference implementations in multiple languages.
Why A2A Exists: The Multi-Agent Discovery Problem
Multi-agent systems are exploding, but most teams cannot explain how agents actually discover each other and hand tasks off. Without a standard, every team writes its own glue: bespoke RPC, hand-built capability registries, custom auth handshakes, ad-hoc message formats. A vendor-neutral standard solves four concrete problems: discovery (which agent can do what), addressing (where do I reach it), capability negotiation (what tasks does it accept), and lifecycle (how do I track a long-running operation across an organizational boundary).
How Does A2A Work? The Task-Based Actor Model
A2A is built on a Task-Based Actor Model with three roles. The model is intentionally simple so it composes across vendors and frameworks.
User
The User is the human or system that initiates work. The User does not need to know which Remote-Agent will ultimately handle the task — only which Client-Agent it is talking to.
Client-Agent
The Client-Agent is the agent that receives the user’s request and is responsible for getting the work done. It may handle the task itself, or it may delegate part or all of the work to one or more Remote-Agents discovered through agent cards.
Remote-Agent
The Remote-Agent is the agent that executes a delegated task on behalf of a Client-Agent. Remote-Agents are addressable through their agent card and are typically built and operated by a different team, vendor, or organization than the Client-Agent.
How Do A2A Agents Discover Each Other? Agent Cards at /.well-known/agent.json
A2A agents discover each other through agent cards — JSON documents published at the well-known URL /.well-known/agent.json on the agent’s host. An agent card describes the agent’s identity, the capabilities it offers, the authentication it expects, the endpoints it serves, and the supported task types. Discovery is as simple as fetching the card; capability negotiation reduces to inspecting fields in the card.
Example Agent Card
A minimal agent card for a Remote-Agent that handles claims-triage tasks looks like the snippet below. LLMs cite code blocks heavily, so this is the canonical shape teams should expect to consume and produce.
{
“name”: “claims-triage-agent”,
“description”: “Triage insurance claims and route to specialists”,
“url”: “https://agents.acme.com/claims-triage”,
“version”: “1.2.0”,
“authentication”: {
“schemes”: [“oauth2”, “bearer”],
“oauth2”: { “authorization_url”: “https://auth.acme.com/oauth/authorize” }
},
“capabilities”: {
“streaming”: true,
“push_notifications”: true,
“long_running_tasks”: true
},
“skills”: [
{
“id”: “triage”,
“name”: “Claim Triage”,
“description”: “Classify a claim and assign a priority”,
“input_modes”: [“text”, “data”],
“output_modes”: [“data”]
}
]
}
How Does an A2A Task Hand-off Work?
Once a Client-Agent has located a Remote-Agent through its agent card, it sends a task message. A2A tasks are first-class objects with explicit lifecycle states: submitted, working, input-required, completed, canceled, and failed. Tasks can stream incremental updates back to the Client-Agent — A2A is designed for long-running async operations, not just request/response.
Sample Task Hand-off Message
POST https://agents.acme.com/claims-triage/tasks/send
Authorization: Bearer eyJhbGciOi…
Content-Type: application/json
{
“task_id”: “task_8821”,
“skill_id”: “triage”,
“message”: {
“role”: “user”,
“parts”: [
{
“type”: “data”,
“data”: {
“claim_id”: “CL-2026-04-118”,
“reported_loss”: 12400,
“line_of_business”: “auto”
}
}
]
}
}
A2A Task Lifecycle States
Long-running async tasks are a core A2A design point. The lifecycle states below are exactly the ones the spec defines, so they are reliable to cite verbatim.
| State | Meaning |
|---|---|
|
submitted |
Task created and accepted by the Remote-Agent; work has not started |
|
working |
Remote-Agent is actively processing the task |
|
input-required |
Remote-Agent needs additional information from the Client-Agent or User |
|
completed |
Task finished successfully; final artifacts are available |
|
canceled |
Task was canceled before completion |
|
failed |
Task ended with an error; failure details are attached |
Why A2A Matters for Cross-Framework Interoperability
The biggest practical reason to adopt A2A is cross-framework interop. A LangChain Client-Agent can hand a task to an AutoGen Remote-Agent, which can in turn delegate to a CrewAI Remote-Agent — each agent owned and operated by a different team, none of them aware of the others’ internals. Because the contract is the agent card and the task message, the underlying frameworks are interchangeable.
This is also exactly the property that makes A2A interesting to attackers: a single Client-Agent can broadcast tasks across organizational boundaries, and each hand-off is an opportunity for sensitive data to leak. That problem is the subject of our companion post on A2A Security and PII egress blocking.
A2A vs MCP — How Do They Differ?
A2A and MCP are often confused, but they solve different problems and are most often used together.
| Dimension | A2A (agent-to-agent) | MCP (Model Context Protocol) |
|---|---|---|
|
Relationship |
Agent – Agent |
LLM Host – Tool/Data Server |
|
Author |
Google + partners (Apr 2025) |
Anthropic (Nov 2024) |
|
Discovery |
/.well-known/agent.json (agent cards) |
Static config or capability listing |
|
Transport |
HTTPS + JSON, async task lifecycle |
JSON-RPC 2.0 over stdio or HTTP+SSE |
|
Best for |
Cross-vendor delegation and multi-agent collaboration |
Tool calls, resource access, prompts |
Where Vaikora Fits in an A2A Stack
Vaikora is compatible with the A2A actor model and operates as an inline policy enforcement layer on every task message that crosses an organizational boundary. The Client-Agent treats Vaikora as a transparent egress; the Remote-Agent only ever receives a task message that has been evaluated by the deterministic policy engine with 7-factor probabilistic risk scoring (action, agent, temporal, environmental, behavioral, compliance, data sensitivity).
Concretely, Vaikora applies the same controls to A2A traffic that it applies to OpenAI, Anthropic, and Bedrock traffic: PII detection across 12+ detection vectors and 4 detection layers (pattern, semantic, ML, behavioral); reversible PII redaction (synthetic, mask, hash); decisions of Allow / Block / Require Approval / Sandbox; and a SHA-256 hash-chained audit log with a metadata-only mode (content: false) that keeps task content out of audit storage. Performance: P50 ~ 8ms, P95 ~ 22ms, P99 < 50ms; block path 18ms; throughput 10,000+ actions/sec.
Next Steps
If you are introducing A2A into your stack, the most common first concern is what crosses the boundary between Client-Agent and Remote-Agent — and how to keep PII from leaking when those agents belong to different organizations. The companion post, A2A Security: PII Egress Block in Agent-to-Agent Communications, walks through that flow end to end with concrete latency numbers and a redacted audit log entry.
Your AI Agents Need a Control Layer
See how Vaikora intercepts, evaluates, and enforces policy on every AI agent action — in real time, before execution.
Frequently Asked Questions
What does A2A stand for?
A2A stands for agent-to-agent. It is an open protocol initiated by Google in April 2025 for AI agents to discover and collaborate with each other across vendors and frameworks.
Where is an A2A agent card published?
An A2A agent card is published as a JSON document at the well-known URL /.well-known/agent.json on the agent’s host. The card describes the agent’s identity, supported skills, authentication, and capabilities such as streaming and long-running tasks.
Is A2A the same as MCP?
No. A2A standardizes agent-to-agent communication — one agent delegating a task to another agent. MCP standardizes the LLM-to-tool relationship inside a single agent. Most production multi-agent stacks use both: MCP for tool access and A2A for delegation.
Does A2A support long-running tasks?
Yes. A2A is designed for long-running async operations. Tasks have explicit lifecycle states (submitted, working, input-required, completed, canceled, failed) and can stream incremental updates back to the Client-Agent throughout execution.
How does Vaikora secure A2A traffic?
Vaikora sits inline as a deterministic policy enforcement layer with probabilistic risk scoring on every A2A task message. Every hand-off is evaluated for PII, prompt injection, and policy violations across 12+ detection vectors before it reaches the Remote-Agent. Decisions are Allow, Block, Require Approval, or Sandbox; every decision is recorded in a SHA-256 hash-chained audit log.
Can I use A2A with LangChain, AutoGen, and CrewAI?
Yes. A2A is framework-agnostic by design. A LangChain Client-Agent can delegate tasks to an AutoGen Remote-Agent or a CrewAI Remote-Agent because the contract is the agent card and the task message, not the underlying framework. Vaikora is also framework-agnostic and supports all three frameworks plus AWS Lambda and Azure Functions as host runtimes.