In brief
- A2A v1.0 is the first stable version of the open protocol and supports bindings including HTTP+JSON, JSON-RPC and gRPC.
- Agent Card, Message, Task and Artifact are its central domain objects.
- Polling, streaming and push notifications support both short and long-running work.
- A2A defines communication and security mechanisms, but does not make an agent connection inherently trustworthy or safe.
Which building blocks does A2A use?
A2A treats the remote agent as an independent service. The calling agent does not need to know its internal prompts, models or tools. It sees a published description of capabilities instead and exchanges standardised objects with it.
The Agent Card is a self-description, not an automatic trust guarantee. In A2A v1.0 it can be signed, but the surrounding platform still needs to verify provenance, signature, freshness and the capabilities that are actually permitted.
- Agent Card
- Describes an agent's identity, endpoints, supported protocol versions, capabilities, skills and advertised security schemes.
- Message
- Carries an input, clarification or response between client and agent. Content can contain multiple parts such as text, files or structured data.
- Task
- Represents stateful work that can take time, require clarification or be cancelled.
- Artifact
- Is an output produced by the agent, such as a report, file or structured dataset. An intermediate result must remain distinguishable from a final one.
How does an A2A interaction work?
A short request can be answered immediately with a Message. If it becomes longer-running work, the agent returns a Task with status and later updates. The protocol therefore supports not only synchronous request and response, but also incremental and asynchronous processing.
- Step 1
Discover the capability
The client reads an Agent Card and verifies its version, endpoint, advertised skills, security schemes and trustworthiness.
- Step 2
Send the assignment as a Message
Goal, context and permitted data are transmitted as narrowly and structurally as possible. Authorisation is enforced outside free-form message text.
- Step 3
Receive a Message or Task
A short answer may return directly. Longer work creates a Task with a unique identifier and traceable state.
- Step 4
Receive progress
Depending on duration and infrastructure, the client uses polling, a streaming channel or push notifications and handles retries idempotently.
- Step 5
Review and accept Artifacts
Outputs are validated, associated with their Task and agent version, and only then passed into a downstream process.
How do A2A, MCP and a normal API differ?
The three approaches are not necessarily competitors. They solve different integration problems. One architecture may combine a domain API as a reliable system boundary, MCP for controlled tool use within an agent and A2A for delegation between independent agent services.
| Building block | Connects | Suitable for | Not its responsibility |
|---|---|---|---|
| A2A | Independent agents across system or organisational boundaries | Discovering capabilities, delegating work and exchanging status and results | Not domain authorisation or a replacement for internal process controls |
| MCP | An AI application or agent with a server's tools, resources and templates | A consistent way to access exposed capabilities and context | Not general coordination between independent agents |
| Domain API | Software components through explicit endpoints and data contracts | Stable, testable system actions and queries with clear semantics | Not flexible goal negotiation or agentic task execution |
| Internal function call | Components within the same application | Tight, fast integration under one control boundary | Not an interoperable boundary for independent vendors or teams |
When is A2A worthwhile, and when is it not?
A2A becomes useful when two agents are operated independently, implemented differently or owned by separate organisations. Within a single application, the protocol often adds more complexity than value. Stable, fully specified data exchange is usually simpler and more testable through a normal API.
- Useful: a procurement agent delegates a supplier check to a separately governed compliance agent.
- Useful: agents from different vendors need to collaborate across a shared, versioned boundary.
- Useful: work is long-running and needs status, clarifications or multiple result artifacts.
- Usually unnecessary: one agent merely calls database, search or email tools; MCP or a direct API often fits better.
- Usually not ideal: a deterministic system process already has a stable API contract and needs no open-ended task delegation.
Which controls does enterprise A2A require?
TLS, security schemes and signed Agent Cards provide technical foundations, but they do not replace a trust decision. The receiving agent must authenticate every caller and authorise it for the specific resource and action. Even a correctly identified partner should receive only the minimum data and capabilities needed.
A2A v1.0 adds version negotiation and multiple bindings. Organisations should still define permitted versions and extensions, test compatibility and plan a controlled migration route. Protocol version, agent version from the Agent Card, Task, identity, approvals and Artifacts all belong in one traceable record.
| Control | Concrete implementation | Failure case to test |
|---|---|---|
| Identity and authentication | Verify server certificate and Agent Card provenance; authenticate the client with an appropriate method such as OAuth 2.0 or mTLS | An unknown or impersonating agent presents a familiar Agent Card |
| Authorisation and least privilege | Enforce rights by tenant, skill, data type and action; never forward broad user rights by default | A legitimate agent requests data outside its assignment |
| Data minimisation | Transfer only required Message parts and Artifacts; classify and filter sensitive fields | An intermediate result includes unnecessary customer data or credentials |
| Logging | Correlate Task history, status changes, caller identity, approvals, versions and result acceptance | An Artifact cannot later be linked to its assignment and accountable party |
| Versioning and failure | Define supported versions, run contract tests and control timeouts, cancellation and retries | An update changes field semantics or a retry executes an action twice |
Example: supplier screening across two agent systems
A procurement agent turns a request into a structured screening assignment. It discovers the approved compliance agent through its signed Agent Card and sends only supplier ID, country, screening purpose and deadline. The compliance agent creates a Task, requests missing information and later returns a report as an Artifact. The procurement agent may display the result but cannot override a block. Identities, versions, status changes and human approval are logged. Direct ERP postings continue to use a tightly scoped domain API.
What to remember
Use A2A where independent agents truly need to exchange assignments and results. Use MCP for tools and context and domain APIs for stable system actions, and treat every agent boundary as a regular security-critical service integration.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed