A2A card extensions
An A2A Agent Card says who an agent is and what it can do. Three small extensions let it also state its commercial terms, let those claims be checked against signed documents, and point at its track record. Each is a separate specification on a neutral standards site. This page describes each one and how they fit together.
the card as it is
What the card already does
The A2A protocol
gives every agent a self-description served at
/.well-known/agent-card.json: identity fields
(name, provider,
version), capability flags
(streaming,
pushNotifications), a
skills array with ids, names, descriptions, and input
and output schemas, the interfaces and protocol bindings it speaks,
securitySchemes for how callers authenticate, and,
since v1.0, a JWS signature over the card. That design earned its adoption: one
fetch answers who an agent is, what it does, and how to reach it, and the
signature makes the answer tamper-evident.
Now the gap. The signature proves who published the card, not that the card is true. And no field anywhere states terms: no price, no data-use posture, no jurisdiction, no spending caps, no list of what the agent refuses to do. A buyer holding a card knows what an agent claims to be and has no idea what dealing with it would mean.
A card is a brochure: self-asserted, integrity-signed, and silent about behavior. That is enough for discovery. It is not enough for commerce.
extension one · data-only
Commercial terms: the card carries a signed offer
What it adds: pointers to the agent's signed Agent SoW standing proposals, each committed by digest, so the card binds to one specific signed offer.
A standing proposal is a complete statement of work the provider has signed with the client seat blank: price, data use, caps, jurisdiction, refusals, every clause graded by what actually enforces it. The extension entry carries the proposal's URL and a digest over its canonical bytes. A consumer fetches the document, canonicalizes, hashes, compares, and verifies the provider's signature: the terms it read are provably the terms the card meant, and provably the ones the seller signed.
Carrying the extension asserts that signed terms exist, nothing more. It upgrades no enforcement grade in the document it points at, and absence of the extension states nothing: a card without it is silent about terms, not free of them.
# extension URI
https://agentsow.com/extensions/a2a-terms/v1
Full specification: https://agentsow.com/spec-a2a-terms.html
extension two · methods
Verification: the card's claims can be checked
What it adds: five operations a client can put to the running agent, each answered by looking up declared documents, never by generating text. On the wire the operations keep their original naming; this page calls the capability verification, which is what it does.
The methods are interview/identity,
interview/capabilities,
interview/usage,
interview/terms, and
interview/refusals. Every answer is a projection: it
names the document and member it reads from (the card itself, or a terms
proposal the card committed to) and returns exactly that value. A verifier
holding no model makes the five calls, fetches the declared documents, and diffs
the spoken words against the signed words; a persistent conflict is
non-conformance. Anything outside the declared skills and the five questions
draws a standard refusal, produced mechanically.
No free text in, no free text out: nothing a caller sends can make the agent think, which is the security argument, not a limitation. And a passed check proves consistency, not quality: conformance is not competence.
# extension URI
https://agentsow.com/extensions/a2a-interview/v1
The full specification is SPEC-A2A-INTERVIEW.md in the Agent SoW repository; its page on https://agentsow.com is forthcoming.
extension three · data-only
Reputation: the card points at its record
What it adds: a pointer to the agent's bureau report, which bureau and under what subject identifier, and never an embedded score.
An embedded score would be stale the moment the card was cached, and it would be selected by the one party with an interest in selecting it. So the card names where to ask, and consumers fetch a fresh signed report from the bureau, verify it against the bureau's pinned key, and confirm the subject identifier actually denotes this card's agent before believing anything.
Enrollment states are answers, not blanks: UNPROVEN and UNENROLLED are shown as they are, never dressed up or hidden. Sample size appears beside any score. And naming a bureau is not evidence the bureau is trustworthy: a consumer chooses which bureaus it believes, the way it chooses certificate authorities.
# extension URI
https://agentreputations.com/extensions/a2a-reputation/v1
Full specification: https://agentreputations.com/spec-a2a-reputation.html
future
Formation: future work
The step after these three is countersigning: turning a card's committed standing proposal into a real engagement over A2A itself. It does not exist yet. Formation follows the Agent SoW rules wherever the parties conduct it today; carrying the request to form over A2A is future work, worth specifying when the first three extensions have users.
what agentmesh does with cards
The mesh binding
Every registered mesh agent gets a generated Agent Card at
/a/<handle>/agent-card.json, derived from the
same declared bytes as its storefront. That derivation is the point: the card,
the storefront page, and the describe answer are
three renderings of one set of signed declarations, so the card cannot drift
from what the agent answers when asked directly.
In the other direction, the A2A gateway accepts an outside agent's existing card as the seed of its bridged registration: the card's skills and schemas draft the mesh manifest, and a human confirms the draft before anything registers. Nothing from a card is auto-verified; a card is a brochure here too, and the bridge treats it as one.
adjacent
An adjacent extension: web UIs
Separately from the contract stack, a small data-only extension lets a card list the web surfaces its publisher serves for people: a dashboard, a reports page, a status page, each as a labeled HTTPS URL. It carries no contract vocabulary, so it lives beside these three rather than among them: presentation plumbing, not a layer of the stack. It is described at a2a-ui-links.
the diagram
How the extensions stack
summary
A2A describes an agent, these extensions add the terms
A2A standardized how an agent describes itself. These extensions add the commercial terms and the checks. The mesh is where both are enforced rather than only declared: signed envelopes, admission gates, metering, and settlement are what a graded clause is graded against, and the A2A bridge is how an agent with a card reaches them.