A2A adoption in 2026: what 274 public Agent Cards show

In Emissar’s crawl of the Tranco top one million websites on September 26 and 27, 2026, 274 of the 999,550 domains checked served an A2A Agent Card at a well-known path. That is 0.027%. None of the 1,000 highest-ranked domains served one. Of the 274 cards, 200 use the v1.0 shape, and 113 of those still name their protocol binding with the v0.3 field name. No card carries a signature, 194 declare no security scheme, and only 74 send both a positive max-age and an ETag.

Public A2A discovery on the open web exists, it is small, and most of the cards that exist skip at least one thing the specification recommends. Every figure in this guide comes from Emissar’s report State of Agent-to-Agent: Q3 2026 or is computed from it. Sections headed “Emissar’s reading” are our interpretation of those figures.

What was measured

EmissarBot took the domains in Tranco list L5PZ4, created September 25, 2026, and sent each one at most three HTTPS GET requests: /robots.txt, then /.well-known/agent-card.json, then the older /.well-known/agent.json only when the first card path returned no card. It checked 999,550 of the list’s 1,000,000 domains. It called no agent, so every capability, binding and authentication figure below describes what a card declares. None of it was tested.

Term in the report	What it means
Domains checked	Domains that got exactly one outcome in this crawl
Served an Agent Card	A 2xx response with a JSON object in the v1.0 or v0.3 shape, from either path
v1.0 shape	The object has a supportedInterfaces array
v0.3 shape	No supportedInterfaces, but a url string plus protocolVersion or preferredTransport
Signed	The card has a non-empty signatures array; the crawl did not verify signatures

Two limits shape every number. The crawl looks only at apex domains, so a card published only on a subdomain such as agents.example.com is missed unless the apex redirects to it. It also counts only public cards at the two well-known paths: cards behind authentication, at other URLs or only in registries are not counted. The methodology covers robots.txt handling, timeouts and the other limits, and the aggregate CSV has every figure with its count and base.

The findings

Adoption: 274 cards, none in the top 1,000

Tranco rank	Domains checked	Agent Cards	Share
1 to 1,000	1,000	0	0%
1,001 to 10,000	9,000	3	0.033%
10,001 to 100,000	89,900	34	0.038%
100,001 to 1,000,000	899,650	237	0.026%
All ranges	999,550	274	0.027%

The highest share was in the 10,001 to 100,000 range. In the top 1,000, 511 domains returned an HTTP error, 222 failed to connect, 111 were blocked by robots.txt and 90 returned something other than JSON.

Across all domains checked, the most common outcome was an HTTP error: 574,929 domains (57.5%), of which 473,887 answered 404 or 410. Another 175,856 (17.6%) were blocked by robots.txt, 106,470 of them because robots.txt itself returned 429 or a 5xx, which counts as a full disallow. 86,764 domains returned something other than JSON, 71,810 of them an HTML page, and 1,187 returned JSON that was not an Agent Card.

Versions: 200 in v1.0 shape, 113 of them with a v0.3 field name

Shape and path	Cards	Share of cards
v1.0 shape at agent-card.json	199	72.6%
v0.3 shape at agent-card.json	68	24.8%
v0.3 shape at agent.json	6	2.2%
v1.0 shape at agent.json	1	0.4%

In total, 200 cards (73.0%) use the v1.0 shape and 74 (27.0%) the v0.3 shape. Seven were found only at the older agent.json path. The discovery location in the v1.0 specification is /.well-known/agent-card.json (section 8.2).

The shape test is structural, and the stored cards show where it is generous. Of the 200 v1.0-shape cards, 113 (56.5%) have at least one supportedInterfaces entry that names its binding with transport and has no protocolBinding. transport is the v0.3 field name. In v1.0, protocolBinding is a required field of every interface (AgentInterface in a2a.proto). Illustrative, this is the mixed form the report counts, which is not valid v1.0:

{
  "supportedInterfaces": [
    {
      "url": "https://example.com/a2a/v1",
      "transport": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ]
}

The v1.0 form changes one field name:

{
  "supportedInterfaces": [
    {
      "url": "https://example.com/a2a/v1",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ]
}

Counting each card once per binding it declares: 102 cards (37.2%) declare HTTP+JSON, 88 (32.1%) JSONRPC and none GRPC. 125 cards (45.6%) declare a value outside those three standard names, and 45 (16.4%) declare no binding at all.

Signing: none of 274

No card had a non-empty signatures array. The specification says cards MAY be signed with JWS, and that clients SHOULD verify at least one signature before trusting a card (sections 8.4 and 8.4.3). In this crawl, a client that required a signature would have accepted no card.

Authentication: 194 cards declare no security scheme

Security scheme type	Cards	Share of cards
None declared	194	70.8%
OAuth 2.0	57	20.8%
HTTP, other scheme	30	10.9%
API key	23	8.4%
HTTP Bearer	16	5.8%
Other (non-standard type)	5	1.8%
OpenID Connect	2	0.7%

A card can declare several types, so the rows add up to more than 274. The remaining 80 cards declare at least one scheme, and none declares mutual TLS or HTTP Basic. Under section 7.3 of the specification, clients learn which authentication a server requires from the card’s securitySchemes. Declaring none is accurate for an agent that accepts requests without credentials. The data cannot say which of the 194 are open by design.

HTTP caching and content type

Property	Cards	Share of cards
Cache-Control header	232	84.7%
Cache-Control max-age above 0	161	58.8%
ETag header	120	43.8%
max-age above 0 and ETag	74	27.0%
Content-Type: application/json	270	98.5%

Section 8.6.1 says card endpoints SHOULD send Cache-Control with a max-age and an ETag. 74 cards do both. 18 cards (6.6%) were served with no-store. Of the four cards not served as application/json, two used application/a2a+json, one text/html and one another type.

Capabilities and skills

62 cards (22.6%) declare streaming, 37 (13.5%) push notifications and 18 (6.6%) at least one extension. None declares support for an extended Agent Card. Most cards list 2 to 4 skills (131 cards, 47.8%) or 5 to 9 (94 cards, 34.3%). 38 list one skill and 5 list none, although the v1.0 specification marks skills as required and says a required array must hold at least one element (section 5.7). 175 cards (63.9%) name a provider organization, across 141 distinct names.

Emissar’s reading: what this means for businesses

The bar is specific and within reach. A v1.0 card with v1.0 field names, truthful authentication, caching headers and a signature would clear every check where the cards in this crawl most often fall short. None of those fixes needs a change to the agent behind the card.

The most common defect is in the field clients use to connect. A client following section 8.3.2 reads supportedInterfaces to pick an endpoint. A strict v1.0 client that expects the required protocolBinding may skip an interface that names only transport. For 113 cards, the fix is a field rename.

Read the zero in the top 1,000 narrowly. It means none of those apex domains served a public card at a well-known path to EmissarBot on those dates. It does not show whether those companies run agents on subdomains, behind authentication or in registries, and it does not show why.

Declare authentication if you need it. A card with no security scheme tells a client to call without credentials. If your endpoint then refuses, the client has no way to learn from the card what it should have sent.

Emissar’s reading: what this means for agent builders

A 2xx response may not be a card. Domain-based discovery returned no card for almost every domain, and 71,810 domains answered a card path with an HTML page and a 2xx status. Parse the body and check its structure before treating it as an Agent Card.

Read both shapes and tolerate transport. 74 cards use the v0.3 shape and 113 v1.0-shape cards use the v0.3 field name. Appendix A.2 of the specification advises clients to handle legacy names where schemas permit and to log a warning when they see them. Reading transport as the binding when protocolBinding is missing, and flagging it, matches that advice and matches how the report counted it.

Pick only bindings you implement. 125 cards declare a binding value outside the three standard names. Section 8.3.2 already tells clients to choose the first supported interface, so skip entries you don’t recognise rather than guess.

You cannot require signatures yet. With no signed cards, a hard signature requirement rejects every card in this crawl. What remains is the origin: a card fetched over HTTPS from a domain tells you that domain served it (sections 7.1 and 7.2). Tie trust to that domain and that fetch, treat the provider name as the card’s own claim, verify signatures whenever they appear, and prefer signed cards when you can choose. For anything consequential, such as payments or account changes, rely on the authentication the card declares plus your own checks. Agent identity: what “verified” should mean covers the layers above a signature.

Plan for missing cache headers. 42 cards send no Cache-Control and 154 send no ETag. Section 8.6.2 lets clients apply their own default cache duration when a server sends no caching headers, and a conditional request needs an ETag to work.

Treat capabilities as claims. The crawl never called an agent. A card that declares streaming or push notifications may still refuse the operation, so handle the error. The agent directory lists the public cards the crawl found, one page per agent, which is a quick way to see real variation before you write a parser.

If you publish a card, do these five things

1. Serve it at /.well-known/agent-card.json as application/json. Seven cards in this crawl were found only at the older agent.json path, and one was served as text/html.
2. Use v1.0 field names and fill every required field. Each supportedInterfaces entry needs url, protocolBinding and protocolVersion "1.0", and skills needs at least one entry. 113 v1.0-shape cards used transport and 5 cards listed no skills. The validator’s Interfaces and Field names checks catch both.
3. Declare how to authenticate. If the endpoint needs credentials, add securitySchemes and securityRequirements; if it doesn’t, leaving them out is correct. The validator’s Security check confirms that requirements name declared schemes.
4. Send Cache-Control with a max-age, and an ETag. 74 of 274 cards do both today. The validator’s HTTP caching check tests the live response.
5. Sign the card. Canonicalize with RFC 8785, sign with JWS, and publish the public key where the jku header points. Signed Agent Cards walks through it, and the validator verifies the result. No card in this crawl was signed.

Run the Agent Card validator after each change. It checks all five and cites the section of the specification behind every result. If you are starting from nothing, Tutorial: publish your first Agent Card covers steps 1 to 4, and Moving from A2A 0.3 to 1.0 covers the field renames.