A2A, or Agent2Agent, is an open protocol for communication and interoperability between independent AI agents. It is designed for environments where one agent may need to discover, delegate to or collaborate with another specialist instead of performing every task itself.
A2A is infrastructure, not intelligence. It does not select the model, write business policy or guarantee agent quality. Its job is to make independently built agent services easier to describe and connect.
Why A2A Exists
As organizations deploy agents for research, coding, finance, support, procurement and operations, custom pairwise integrations become difficult to maintain. Every team can invent its own capability schema, task lifecycle, streaming method and authentication conventions, but that creates a fragile integration mesh.
A2A provides shared conventions for the boundary between autonomous services. Its value grows with organizational and vendor diversity.
Core Building Blocks
| Concept | Role |
|---|---|
| Agent Card | Machine-readable metadata describing an agent and how to reach it |
| Agent Skill | Focused descriptive capability |
| Message | Communication turn between client and agent |
| Part | Content unit inside a message |
| Streaming | Incremental status/results |
| Push notification | Asynchronous updates for long-running work |
What Is an Agent Card?
The Agent Card is the protocol’s discovery and setup document. Current A2A documentation describes it as machine-readable metadata containing identity, service endpoint, capabilities, authentication requirements and skills. A standardized well-known URI helps clients locate a public Agent Card for an agent domain.
Agent Cards can also include signatures. That can help with integrity, but callers still need their own trust policy and identity validation.
What Is an A2A Skill?
An A2A skill is descriptive metadata for a specific capability. Official documentation includes an ID, name, description, tags, examples, supported media modes and security requirements. A skill is not the same thing as an executable tool function. It describes what the agent is suited to do.
This distinction allows registries to search and rank agents based on capabilities while leaving implementation details behind the agent boundary.
Agent Discovery
A2A supports discoverable metadata, but it is not a universal global directory. Discovery can happen through a well-known Agent Card, a private enterprise registry, configuration or a platform catalog. Google Cloud Agent Registry demonstrates the registry pattern by extracting A2A skills from compatible Agent Cards and indexing them for search.
Messages, Streaming and Long-Running Work
Agent work can take longer than a normal API response. A2A includes communication patterns for incremental results and asynchronous status. This matters for research, procurement, coding or analytical jobs that may involve several external systems and minutes of work.
The protocol’s task and messaging model lets a client maintain a coherent interaction without inventing a completely proprietary lifecycle.
A2A vs REST APIs
Two agents can communicate using ordinary REST. A2A becomes valuable when interoperability itself is the product requirement. It standardizes how capabilities are described and how common agent interactions are represented, reducing the amount of custom glue between independently built services.
For one internal agent and one fixed caller, a custom API may remain simpler.
A2A vs MCP
A2A focuses on agent-to-agent communication. MCP focuses on connecting AI applications to tools and data. They can be used together. A travel coordinator can delegate to a hotel agent through A2A while the hotel agent uses MCP to query inventory and booking systems.
A Real Multi-Agent Workflow
- A coordinator receives a purchase request.
- It searches an approved registry for procurement capabilities.
- It validates the selected agent’s identity and policy eligibility.
- It delegates the sourcing task.
- The specialist uses its own tools to collect quotes.
- A compliance agent checks policy.
- A human approves the final purchase.
A2A standardizes the independent-agent boundary. It does not remove business controls.
What A2A Does Not Solve
- Model choice and model quality
- Business rules and workflow policy
- Data governance
- Authentication infrastructure outside protocol declarations
- Observability and evaluation
- Human approval design
Security and Trust
Discoverability is not trust. A remote agent can be misconfigured, compromised or operated under different data rules. Validate identity, owner, endpoint, authorization requirements and the class of data being delegated. Treat Agent Card metadata as routing evidence, not unlimited permission.
When A2A Is a Good Fit
- Several independently deployed specialist agents
- Cross-team or cross-vendor interoperability
- Capability discovery through machine-readable metadata
- Long-running delegated work
- A need to reduce custom agent-to-agent schemas
When It Is Overkill
A small agent system with a fixed set of internal services may not need A2A. Every protocol adds versioning, testing and operational complexity. Adopt it when interoperability cost is real.
Bottom Line
A2A helps turn isolated agent services into a more interoperable ecosystem. Agent Cards make capabilities machine-readable, skills make them searchable, and common communication patterns reduce custom pairwise integration. Its importance grows as organizations deploy more independent agents.
How A2A Changes Multi-Agent Design
Without a protocol, multi-agent systems often become framework-specific. One orchestrator knows how to call one internal agent class, how to serialize its prompt and how to parse its output. That works until another team deploys an agent using a different framework or infrastructure stack. A2A moves the interoperability contract outside the framework so an agent can remain independent behind a common interface.
This is especially useful for enterprises where different teams have different release schedules and security boundaries. The purchasing team can update its agent without requiring the research team’s orchestrator to understand its internal code.
Agent Cards in More Detail
Agent Cards are valuable because they make capabilities inspectable before execution. A routing layer can read an agent’s declared skills, supported interaction modes and security requirements and decide whether it is even a candidate. The card can also provide the service endpoint and other metadata needed to establish communication.
However, capability metadata should be reviewed like an API contract. Vague descriptions make routing unreliable. Teams publishing agents should write skills that are narrow enough to distinguish one specialist from another and should include examples that make the intended scope clear.
Designing Good Agent Skills
A good skill name is specific, a good description explains inputs and expected outputs, and examples represent realistic tasks. Tags should help discovery without becoming a keyword dump. Security requirements should be explicit when the skill needs authenticated access or sensitive context.
For example, “finance” is a weak skill. “Analyze monthly SaaS revenue variance from structured finance exports” is far more useful because an orchestrator can understand when it applies and when it does not.
Task Boundaries
Delegation works best when the caller gives a bounded objective, relevant context, expected output format and clear success criteria. Sending “do whatever is necessary” to a remote agent increases ambiguity and security risk. A2A standardizes communication, but good task design is still an application responsibility.
Streaming and Asynchronous Work
Some delegated tasks are naturally interactive or long-running. A specialist may need several minutes to search, compute or wait for an external system. Streaming allows the caller to receive incremental status, while asynchronous notification patterns let the workflow continue without keeping one synchronous request open indefinitely.
These patterns are valuable for user experience as well as infrastructure. A coordinator can show meaningful progress, allow cancellation or escalate a stuck task instead of presenting a frozen interface.
Interoperability Does Not Mean Homogeneity
Two A2A agents do not need the same model, memory system or internal framework. One can use a hosted frontier model and another can use a specialized local model. One can rely on MCP and another can use proprietary internal APIs. The protocol standardizes the external interaction, not the implementation.
Operational Governance
Organizations adopting A2A should maintain an approved-agent inventory, owner information, versioning rules, incident contacts and data-sharing policy. If an agent is removed or compromised, callers need a way to revoke trust quickly. Discovery without lifecycle management creates stale dependencies.
Measuring Agent Quality
A2A skill metadata says what an agent claims to do. Production routing should also learn how well it actually performs. Track task success, latency, cost, escalation rate, policy violations and user review outcomes. Over time, these signals can complement capability metadata when choosing among several agents with similar skills.
Adoption Checklist
- Identify independent agents that currently use custom pairwise APIs.
- Define narrow, machine-readable skills.
- Publish Agent Cards through approved discovery mechanisms.
- Define authentication and authorization policy.
- Add tracing for delegated tasks.
- Create acceptance criteria for remote results.
- Test streaming, timeout and cancellation behavior.
- Document version compatibility and deprecation policy.
The A2A Interaction Model in Plain English
An A2A client does not need to know how the remote agent is built. The server may use a different model, programming language, orchestration framework or internal tool stack. What matters is that it can describe how to reach it and what it can do, then participate in the protocol’s supported interaction patterns.
This external contract is the main architectural value of A2A. It lets teams improve or replace an agent behind the boundary without forcing every caller to understand its internals.
Agent Cards in Detail
The Agent Card is a machine-readable manifest for an agent. Current A2A documentation describes it as a place for identity, service endpoints, supported interfaces, capabilities, authentication requirements and skills. Public cards should avoid secrets and sensitive internal details. More detailed information can be protected behind authenticated discovery when necessary.
Well-written Agent Cards make automated routing more reliable. Poor cards create the same problem as poor API documentation: callers may technically connect but will not know when the service is appropriate.
How to Design Useful Skills
A skill should describe a focused capability, not an entire department. “Finance” is vague; “analyze SaaS monthly revenue variance from structured exports” gives a router much better information. Descriptions should explain boundaries, expected inputs and outputs. Examples should reflect realistic tasks rather than marketing slogans.
Tags can help categorization, but stuffing a skill with every possible keyword makes discovery worse. Treat skill metadata as an information-retrieval surface.
Messages, Parts and Artifacts
Agent communication often contains more than plain text. A task can include structured data, files or other media. The protocol’s message and part concepts provide a consistent way to represent those exchanges while allowing agents to support different media modes. The important design principle is to keep task context explicit so a remote agent receives what it needs without inheriting unrelated sensitive data.
Streaming and Push Notifications
Some agent work cannot finish inside a short synchronous request. A2A supports real-time streaming for incremental status and asynchronous notification patterns for very long-running or disconnected workflows. These capabilities matter for research, coding, procurement and other jobs that may take minutes or hours.
A product using these features should expose meaningful progress and cancellation. “Working…” for ten minutes is not sufficient observability.
Discovery Strategies
A2A does not imply a single global directory. Official documentation describes several discovery strategies: known well-known Agent Card locations, curated registries or catalogs and direct configuration. Static configuration is simple and safe for small environments; registries become useful as the number of services grows.
Sensitive agent cards should be protected. Internal URLs, private capabilities and security details can reveal valuable information to an attacker even if the agent itself still requires authorization.
Security Requirements
Secure A2A deployment starts before the first task is delegated. Validate the remote identity, protect Agent Cards that expose sensitive metadata, use TLS, enforce authentication and authorization, and minimize the context sent to the remote agent. If signatures are present, clients should verify them according to their trust policy.
The caller should also decide which types of agents can receive which data classes. An approved research agent may still be prohibited from receiving payroll or health information.
Long-Running Task Governance
Long-running tasks need deadlines, cost budgets and escalation rules. A coordinator should know when to cancel, retry with another agent or ask the user for clarification. Without limits, a distributed agent workflow can consume resources long after the task has stopped providing value.
Testing A2A Interoperability
Test more than the happy path. Validate Agent Card parsing, authentication failures, incompatible media modes, timeouts, streaming interruption, cancellation and malformed outputs. If a registry is involved, test stale entries and duplicate agents. Protocol interoperability is only useful when failure behavior is predictable.
When A2A Adds Real Value
A2A is strongest when agents are independently deployed, owned by different teams or vendors, or expected to evolve independently. It is less valuable when a single application calls a few internal functions that already share the same codebase. In that situation a normal function interface can be simpler and safer.
Adoption Checklist
- Identify a real independent-agent boundary.
- Define narrow skills and clear ownership.
- Publish or register an Agent Card.
- Define authentication and data-sharing policy.
- Set time, cost and retry budgets.
- Trace every delegated task.
- Validate returned artifacts against acceptance criteria.
- Version the interface and maintain deprecation rules.
FAQ
Is A2A only for Google agents?
No. Its purpose is interoperability across independently built agents and providers.
Does A2A require MCP?
No. They can be used separately or together.
Does an Agent Card make an agent safe?
No. It helps describe the agent; trust and authorization still require separate controls.
Can A2A support long-running work?
Yes. Its interaction patterns include streaming and asynchronous operations.
