All posts
· 9 min read ·

A2A 1.0 is six months old. Two-thirds of agent cards still declare 0.3.

Across the 1,910 version-declaring cards in Agenstry's crawl, 65.5% still say 0.3.x, 41 declare an MCP revision date as their A2A version, and of the 91 signed cards only 52 verify. A field-by-field read of where the public agent web actually is.

A2A 1.0 has been stable since March 12. Six months later, of the 1,910 agent cards in Agenstry's registry that declare a protocolVersion at all, 65.5% still declare a 0.3.x version and 25.5% declare any 1.0.x. Forty-one declare a version that isn't an A2A version — it's a date, in the exact format the MCP specification uses for its revisions. Nine more declare versions that have never existed in any spec: 1.1, 1.2, 2.0, 5.0, one lone 9.2.9.

In July, Kin Lane probed 22,341 hosts from the APIs.io catalog and found 65 published agent cards, of which ten fully conformed to A2A 1.0. His conclusion — "the Agent Card is quietly decoupling from A2A" — was drawn from a small outside-in sample. Our crawl watches the whole public surface continuously, and the full-population numbers say he is measuring something real. The cards parse. What they mostly don't do is speak the current protocol.

What 1.0 changed, and why the version field is the tell

The version story has two earlier chapters. In July 2025, v0.3.0 renamed the card's well-known location from agent.json to agent-card.json — a small change that doubles as a maintenance probe, because an agent still serving only the old path has not been touched in over a year. In March 2026, v1.0 restructured the card itself: transport moved into supportedInterfaces[], each interface carrying its own protocolVersion, and the card gained an optional JWS signature block — the "Signed Agent Cards" the Linux Foundation put at the top of the one-year announcement in April.

So the version a card declares is not trivia. It predicts which parsers can read it, whether signature verification is even possible, and whether the deployment is maintained.

Here is the declared-version distribution across every card in the registry today:

Declared protocolVersion — 1,910 cards, Agenstry registry, 2026-09-01 0.3.x 1,252 · 65.5% 1.0.x 488 · 25.5% 0.2.x 105 MCP date 41 nonexistent 9 other 15

Three details in that distribution deserve more attention than the headline split.

The identity field is where protocol confusion shows up first. The 41 cards declaring 2025-06-18, 2025-03-26, 2025-11-25 or 2026-07-28 are not typos — those are MCP specification revision dates, pasted into an A2A field. Operators are publishing one manifest and filling its fields from whichever protocol's documentation they read last. Lane saw the same drift from the outside; the version field shows it from the inside. Add the cards declaring erc8004/1 or a vendor string as their protocol version, and the manifest-first reading gets hard to dismiss: for a meaningful slice of publishers, the Agent Card is a general discovery document, and A2A is one possible thing it might point to.

The legacy path is a quiet unmaintained-deployment census. 385 of the 2,785 agents whose card path we classify — 13.8% — still serve their card only at the pre-0.3 location the spec renamed fourteen months ago. Lane's outside sample put the same figure at 23%. Whichever end of that range you trust, roughly one card in five to seven has survived two spec generations without its operator touching it.

Signing — the flagship 1.0 trust feature — is where the gap is widest. Of 6,019 agents with a parseable card, 91 publish a JWS signature block: 1.5%. Of those 91, 52 signatures actually verify against a key the domain serves. Six fail verification outright, and 33 sign with a key that can't be fetched at all. In other words: six months after signed cards became the headline feature of the 1.0 release, the number of agents on the public web whose identity claim cryptographically checks out is 52 — and an agent that attempts signing has roughly a 43% chance of producing something a verifier can't accept. The feature works; the deployment discipline around key publication doesn't exist yet.

What this means if you build on agent cards

For anyone writing a strict A2A 1.0 client, the numbers are an instruction: a parser that rejects non-conformant cards rejects most of the public agent web. Our own crawler stopped discarding malformed cards in August and instead repairs them field by field, recording each repair as a finding — the strict path had silently blanked 21 real, live agents over a single non-conformant sub-field before we changed it. Verifiers, gateways and registries face the same choice, and the ones that pick strictness will see a much smaller web than the ones that pick salvage-and-annotate.

For the A2A project itself, the picture is more encouraging than the 25.5% suggests. The 1.0.x share was zero in March. The v1.0 migration path was designed to let 0.3 clients keep working, which means there is no forcing function — and version distributions without forcing functions move slowly everywhere. TLS 1.3, HTTP/2 and IPv6 all spent their first years with adoption curves that looked like this.

For anyone reading adoption claims: organization counts and card-population measurements are different instruments. More than 150 organizations back the protocol, and A2A joined MCP under the Agentic AI Foundation in August. Both facts are real. Neither tells you what fraction of publicly published cards a 1.0 verifier can consume today. That number is 25.5% of the cards that state a version at all — and it is the one this page will keep reporting as it moves.

What we're watching

Three measurements will tell us whether this year's picture is a lag or a plateau. First, the 1.0.x share in the distribution above — if the SDK releases that quietly ship 1.0 defaults are doing their job, it should climb without any operator reading a migration guide. Second, the signature verify-rate: 52-of-91 is small enough that a single hosting provider adding key publication to its template would visibly move it. Third, the multi-agent listing format — we began digesting /.well-known/agents.json documents this week, and how many agents arrive through listings rather than single cards will say whether the registry-shaped future the A2A registry proposal describes is actually being deployed.

Sources

← Back to blog Agenstry