A2A protocol provides a robust and standardized framework for agent-to-agent communication. It also recognizes that a one-size-fits-all approach may not be suitable for every scenario. This is where extensions come in. Extensions allow developers to add custom, domain-specific functionalities and methods to their A2A servers, going beyond the core protocol. Besides, it enables clients to add additional requirements that remote agents should support. This can be incredibly useful when an agent needs to offer specialized features.
Getting started is straightforward. Here’s a ‘helloworld’ extension designed to add timestamps to messages and artifacts within the A2A framework. An agent simply declares its support for an extension in its „Agent Card,” a JSON file that outlines its capabilities. Because anyone can define, publish, and implement an extension—each identified by a unique URI—the ecosystem is incredibly open and community-driven. This approach ensures the A2A protocol remains highly flexible and adaptable, empowering developers to build far more powerful and specialized multi-agent systems.
A2A Extensions in Use Today
As A2A adoption continues, we witness a wide range of extension use cases.
Traceability Extension in A2A
To ensure diverse AI agents collaborate reliably and without errors, it’s crucial to evaluate their communication. A traceability extension makes this evaluation possible by providing the deep visibility needed to track interactions and effectively diagnose issues.
How It Works: The ResponseTrace
The core of this extension is the ResponseTrace message, a structured log that captures the sequence of actions an agent takes. It’s designed to be lightweight and independent of the main A2A protocol, focusing only on logging the requests made by the agent.
A ResponseTrace is composed of a series of Steps. Each Step represents a single operation and can be one of two types:
ToolInvocation: A call to a specific tool, like a function or an API.
2. AgentInvocation: A call to another agent, which could be another A2A agent or a different type.
Crucially, these steps are hierarchical. If an agent calls a second agent that also supports traceability, the second agent’s trace can be nested inside the first. This provides a complete, end-to-end view of the entire workflow.
For further information, review the details here.
Twilio’s Latency Extension
Twilio built a latency-aware extension to A2A aiding the model selection for their voice agent built on Twilio ConversationRelay. This is a classic example of domain specific functionality. Broadcasting latency information of an agent is not part of the core protocol’s specification of agent card. However, Twilio built an extension for exactly that in order for aiding the selection of the best fit agent or adapt gracefully.
For further information, review Twilio’s documentation.
Other interesting applications
Identity Machines implements zero-trust handshakes for agent-to-agent calls via A2A extensions. In their implementation, identity machines showcased how agent task delegation is anchored on trust and independent policy-gates wherein the purpose, budget, capability, model, PII status, etc. (custom) can be enforced before an agent accepts a task.
For further information, review the documentation.
On a similar note, Ethereum has proposed ERC-8004 that aims to create a trust layer for AI agents, allowing them to interact across different organizational boundaries. This standard introduces on-chain registries for identity, reputation, and validation to enable secure and interoperable communication between agents from various ecosystems.
Add comment