On October 21, A2A merged a documentation change into its 1.1 development branch. The discovery guide on that branch now labels /.well-known/ai-catalog.json as preferred and describes /.well-known/agent-card.json as an option for single-agent deployments, because that path can advertise only one card per domain. Multi-agent and multi-tenant hosts are the stated reason for the change.

On November 4 we measured the deployed field. Of the 4,846 hosts in Agenstry's registry with a valid agent card, 780 already serve a catalog at that path. Twenty-one list two or more A2A cards. Seven list two or more on their own host. Catalogs have spread ahead of the specification, and so far they are doing a different job from the one that motivates the preference.

What changed, and what has not

The status of each piece matters here, because a merged pull request on a development branch is easy to misread as a released standard.

A2A core. v1.0.1 is still the latest release, and the specification on main still names the agent-card path. The roadmap lists v1.1 work without a date.
A2A 1.1 branch. The preference sits in the discovery guide. The branch's specification still requires servers to make a card available, and its well-known URI registration gains a note about the one-card limit. A separate open pull request would also recommend serving the card at the root of the agent's interface URL.
MCP. SEP-2127, merged October 6 with Final status, leaves domain-level discovery of Server Cards to an AI Catalog.
AI Catalog. The repository has no tagged release, and its README says the A2A and MCP steering committees will vote on adoption once the specification is finalized. The draft makes the well-known location optional for hosts.
Agentic Resource Discovery (ARD). ARD v0.91 defines a different path, /.well-known/ard.json, and calls ai-catalog.json its predecessor. Consumers must fetch ard.json and may consult the older path. Its publishing guidance warns that a resource left only on ai-catalog.json may not be found.

The last two items collide. A publisher following A2A's branch guidance and a consumer conforming to ARD can each do what their document asks and still miss one another. The two formats share an entry shape, so the disagreement is about location, and location is what a crawler needs first.

What the field looks like

We fetched both paths once from every registry host whose card our validator classes as current or legacy, using the crawler's SSRF-checked client with no credentials, a 7-second timeout and a 1 MB cap. A document counted as valid when it was a JSON object with an entries array. We did not run full schema validation. We followed nested catalogs one level deep, up to five per host. Three passes over the evening found 778, 779 and 780 valid ai-catalog.json documents. The figures below come from the last pass.

The population is selected: every host here already has a valid A2A card, so 16.1% says nothing about the web at large. It does say that catalogs are not a paper exercise among A2A publishers. The 780 hosts resolve to about 540 operators by registrable domain, with one operator accounting for 85 hosts. Among the 1,501 endpoints that answered our live JSON-RPC probe, 373 publish a catalog. This is our first such snapshot, so we can report a level but not a growth rate.

The path conflict is already visible in deployment:

Published at	Hosts
Both `ai-catalog.json` and `ard.json`	426
`ai-catalog.json` only	354
`ard.json` only	53

Under ARD's rules, the 354 are the hosts a minimal conformant consumer would not find. Under a reading of A2A's branch guidance that consults only the preferred path, the 53 are.

A catalog on an A2A host often omits the A2A card

Of the 780 catalogs, 358 contain no entry typed application/a2a-agent-card+json, though every one of those hosts serves a valid card. Another 75 of the 358 reference something that looks like a card under a different type or URL, which leaves 283 with no visible reference. MCP artifacts appear on 666 hosts and OpenAPI descriptions on 449. The median catalog has four entries, and only 71 have exactly one.

The practical consequence is for clients. A resolver that treats the catalog as authoritative and stops there would lose those agents. Absence from a catalog is not evidence of absence from the host. For now the agent-card path remains a required fallback, and the guide on the 1.1 branch keeps it as a valid option.

The multi-agent case barely appears, and we may be undercounting it

The seven hosts listing several A2A cards on themselves are the use case the change was written for. Fourteen more list two or more cards spread across hosts. No catalog embeds a card inline, although the format allows it. All 485 A2A entries we counted use a URL.

Operators running many agents appear to have solved the problem another way. After excluding the shared-hosting and public suffixes we could identify, 338 registrable domains hold two or more hostnames in our registry, 1,459 hosts in total. Fourteen of those domains hold 668 hosts. None of the seven same-host listings comes from this group, although 92 of those domains publish a catalog on at least one hostname. Giving each agent its own hostname is the deployed workaround for the one-card limit, and a catalog does not require undoing it. Hostnames are not proof of distinct agents; some are mirrors or regional copies.

Three limits apply, and all of them bias the count of seven downward. We see only unauthenticated documents, so the per-tenant catalogs the guide describes are invisible. We start from hosts that already have a card we index. And our registry itself has the limitation under discussion: Agenstry's agents table is keyed by hostname, and the crawler's catalog follow-up skips a card on a host it has already seen. The host listing eight cards occupies one row. A preference for catalogs turns that from a modelling shortcut into a defect we need to address. For transparency, agenstry.com is one of the 780 and publishes the same entries at both paths.

A listing is a claim

Ninety-six hosts list 130 A2A cards on other hostnames, and 34 of them cross a registrable-domain boundary with 40 entries. Sixty of the 130 entries, covering 43 distinct hostnames, point to hosts not yet in our registry. For a crawler that is useful discovery. For a trust system it is only a statement by the publisher.

The AI Catalog draft is direct about this: HTTPS authenticates the serving domain, and a signer-supplied host.identifier is not a trust anchor by itself. In our snapshot, 297 catalogs carry a did:-prefixed host identifier, none carries a catalog-level signature, 194 include Trust Manifests, and 55 include at least one manifest with a signature. We did not verify those signatures, so 55 is an upper bound on anything cryptographically meaningful. And 712 catalogs declare specVersion: "1.0" for a specification with no tagged release, a value its own examples use.

What this implies today

For publishers. Keep /.well-known/agent-card.json. If you publish a catalog, serve identical entries at both ai-catalog.json and ard.json from one generator so they cannot drift, and list your A2A card under its registered media type. If you run several agents on one host, a catalog is the first standard way to enumerate them.

For clients. Resolve ard.json, ai-catalog.json and agent-card.json, and merge the results. Treat a missing entry as unknown. Fetch the target of every entry and check it, whichever host listed it.

For registries. Key on the card URL, not the hostname. Record "host A lists card B" as a claim with a timestamp, separate from what probing B shows. A cross-domain listing should create a discovery lead and transfer no reputation.

What we're watching

Three things would change this picture: a tagged AI Catalog release and the steering-committee votes that follow it, a reconciliation of the ard.json and ai-catalog.json paths, and the wording that survives into a released A2A 1.1. The number to track is the seven. If the preference is working, same-host multi-agent catalogs should grow faster than catalogs overall, and we will rerun this probe to find out.

Sources

docs(spec): update agent discovery to prefer AI Catalog over well-known URI, PR #2240 — A2A Project, merged October 21, 2026.
Agent Discovery in A2A, dev-1.1 branch — A2A Project, retrieved November 4, 2026.
A2A v1.0.1 release — A2A Project, May 28, 2026.
A2A specification, main branch — A2A Project, retrieved November 4, 2026.
A2A protocol roadmap — A2A Project, updated September 15, 2026.
A2A specification, dev-1.1 branch — A2A Project, retrieved November 4, 2026.
Recommend serving AgentCard at agent root endpoint, PR #2378 — A2A Project, open as of November 4, 2026.
SEP-2127: MCP Server Cards — Model Context Protocol, Final status.
SEP-2127 pull request — Model Context Protocol, merged October 6, 2026.
Common AI Catalog and Registry Standard — Agent-Card working repository, retrieved November 4, 2026.
AI Catalog specification — editor's draft, retrieved November 4, 2026.
Agentic Resource Discovery specification v0.91 — ARD Project, retrieved November 4, 2026.
Agenstry registry statistics — Agenstry, snapshot November 4, 2026. Reports card formats and live counts across all formats; this post counts only current and legacy cards. Catalog figures come from the one-off probe described above.

Cite this post

@misc{agenstry-ai-catalog-discovery-2026,
  author       = {Hilbers, Sebastiaan},
  title        = {780 agent hosts publish an AI Catalog. Seven use it to list several agents on one host.},
  howpublished = {Agenstry research blog},
  year         = {2026},
  month        = {nov},
  url          = {https://agenstry.com/blog/ai-catalog-a2a-discovery-measured}
}