Agent2Agent is a protocol for one agent to delegate work to another. An agent advertises itself with a JSON card at a well-known path, and clients that find the card send it tasks. We now publish one at https://aisenseapi.com/.well-known/agent-card.json. This note is about what we learned on the way there, and why the card describes four capabilities and not twenty.
What the specification actually says
The current revision is 1.0.1, released in May 2026. The documentation site still shows 1.0.0 on its banner. Most tutorials describe 0.3 or earlier, and three things changed that they get wrong.
The method names moved to PascalCase. SendMessage, GetTask, ListTasks and CancelTask replaced the slash-separated names of 0.x. There is no method for fetching the public card in any revision; it is a plain HTTP GET. And the well-known path moved from agent.json to agent-card.json in revision 0.3, and is now registered with IANA.
Streaming and push notifications are capability flags. Declare them false and the specification requires the matching methods to answer a defined error. Returning that error is the conforming behaviour, not a gap. The two families use different error codes, and merging them would be wrong in a way no client reports back.
Skills are not addressable
This is the finding that decided our scope, and we found it nowhere else.
A card lists skills. Each has an id, a name, a description and tags. What it does not have is a way to be called. There is no skill id anywhere on the wire: not on SendMessage, not on a message, not on a task. Searching the full specification for a skill identifier field returns nothing. The protocol's own comment on the field calls a skill largely a descriptive concept.
So a skill is an advertisement, and the receiving agent is expected to read a free-form message and decide what to do. That works when the receiver has a language model. Ours does not. It can accept a strictly shaped request under a convention we document, and any client able to follow that convention could equally use our REST or MCP surface, both of which publish real schemas in band.
The consequence
Twenty tools as twenty skills would produce twenty paragraphs and no callable operations.
A2A earns its place only where the interesting object is a long-lived task that a person may need to act on. For everything else, MCP already says it better.
What is actually out there
We pulled the full corpus of one public registry, 370 entries, and then went to the sources ourselves: a read-only GET of the well-known path on 60 distinct domains from that corpus. The two views disagree, and the disagreement is the interesting part.
| Measured | Registry copy | At the source |
|---|---|---|
| Cards that parse | 369 of 370 | 55 of 60 |
Use the 1.0 supportedInterfaces field | 0 of 369 | 39 of 55 |
Declare streaming: false | 49 of 55 | |
Declare pushNotifications: false | 52 of 55 | |
| Publish both the 1.0 and the 0.3 shape | 14 of 55 | |
| Publish only the 0.3 shape | 16 of 55 |
The registry served every card in the legacy shape, including the ones whose sources had moved to 1.0. Registries are not a reliable mirror of what agents publish, and anything that reasons about the ecosystem from a registry dump is reasoning about a normalised cache.
The capability numbers settled two of our design questions. Declaring neither streaming nor push is what roughly nine in ten live cards do. And the 0.3 shape is still common enough that we serve it at the old path as well, built from the same skills so the two cannot describe different agents.
The skills people actually publish
Across the 55 live cards there were 413 skills. They are overwhelmingly API-shaped: render a document, send an email, look up a record, run a compliance check. Forty of the 55 cards accept JSON input. On the specification's own terms most of these are tools, not reasoning peers, and the specification's own companion text says tools belong to MCP.
So a utility provider publishing a card is unusual on paper and ordinary in practice. That cuts both ways. It means we are not the odd one out. It also means the ecosystem is not the peer-delegation network the protocol describes, and a card should not be expected to bring traffic.
Nobody measures whether cards get called
Every directory we found measures reachability: does the well-known path answer, does the card parse. One directory publishes its own funnel and reports that about one valid card in ten answers a JSON-RPC request at all. That is their figure, not ours. None of them, ours included, has a measurement of a card leading to real inbound work.
The eight daily requests that started this were not demand either. The user agents named themselves: two directory crawlers, one of which documents that it runs every six hours and sources candidates from certificate transparency logs. A domain that renews a TLS certificate gets probed whether or not it has ever published a card.
What we published
Four skills, the ones where a task is the natural object: waking on an outside event, asking a person to decide, receiving email at a disposable address, and capturing one inbound request. Streaming and push declared false. One protocol binding. The card went live last, after every advertised skill answered, and a gate refuses to pass unless that stays true.
The other sixteen tools are not reachable over A2A. They live on REST and MCP, where their schemas are published in the request itself. The endpoint guide has the details, including the convention for naming a skill inside a message, which is ours and not the protocol's.
What would change our mind
A named client, a framework's agent runtime rather than a directory, shown to discover cards at call time and route work by skill tag. That would make breadth of skills pay, and we would revisit the twenty. We looked and did not find one.
The other direction is also open. If the eight daily hits stay a single crawler on a six-hour cycle with no retries, the card buys presence and nothing more, and we will say so here.
The card
Read it, or read the guide behind it.
No account, no API key. Four task-shaped skills over JSON-RPC.