A2A Integration
Agent-to-Agent Protocol — task metadata and Agent Card extensions; declaration is not activation.
This section is advisory and non-prescriptive. It describes what the host protocol permits, read from its own primary artifact. Where this page and the host protocol disagree, the host is correct — build from its schema, not from an example here.
What it is. An open protocol for communication between AI agents. Task metadata is a key-value map explicitly defined as free for custom fields. Agent Cards published at /.well-known/agent-card.json carry a formal extensions mechanism.
Tier A — Available today. Task metadata accepts arbitrary keys without coordination:
{
"task": {
"id": "...",
"metadata": {
"legalContext": {
"type": "sha256",
"value": "0x7f83b165..."
}
}
}
}Agent Cards can declare LCP requirements under capabilities.extensions[] as an AgentExtension, enabling pre-interaction compatibility evaluation:
{
"name": "...",
"skills": [...],
"capabilities": {
"extensions": [
{
"uri": "<lcp-extension-uri>",
"required": true,
"params": {
"minimumLevel": 2,
"acceptedJurisdictions": ["..."],
"acceptedDisputeMethods": ["..."]
}
}
]
}
}The extension uri identifies the LCP Agent Card extension; params carries the service's LCP requirements.
Declaration is not activation. An Agent Card declaration advertises that an agent supports an extension;
it does not turn the extension on. A client activates by naming the extension URIs in an A2A-Extensions
request header — a comma-separated list — and the agent SHOULD echo the activated set back in the response
header. AgentExtension itself has four fields in a2a.proto, in this order: uri (the unique identifying
URI), description (a human-readable description of how this agent uses the extension), required (if true
the client must understand and comply), and params (optional configuration). The URI is an identifier, not a
location — A2A does not expect it to be dereferenced.
Note the failure mode: any requested extension the agent does not support "can be ignored". A client that activates a legal-context extension against an agent that does not implement it receives no error — the response simply omits it from the echoed set. A deployment that requires legal context to be handled must check the response header, not merely send the request one.
Tier B — Forward work. A formal extensions registration in the A2A schema would give parsers standardized handling across implementations.
Limitations. Custom keys in task metadata are interoperable only as far as receiving agents recognize them.
Steward invitation. The A2A stewards are invited to register legalContext as a first-class extension in both task metadata and Agent Cards, and to publish guidance on skill-level LCP requirements as part of capability negotiation.