An AI catalog served at /.well-known/ai-catalog.json is a single document stating what a service does, where its machine-readable surfaces are, what authentication it expects, and what limits it imposes. It belongs to the agentic resource discovery family, alongside the API catalog defined in RFC 9727 and the older robots and sitemap conventions, and it is the least settled member of that family. I would rather open with that than sell it as an established standard, because the useful question is not whether the format has won but whether the thing it describes needs describing.
The problem it addresses is the one that appears the moment an agent has a hostname and an intent. The API catalog answers where the APIs are. The AI catalog answers a prior question, which is what this service is for and whether an agent is welcome to use it that way. Those are different questions, and as a result the second one currently has no good answer anywhere on most sites. An agent that wants to know whether it may call your service programmatically, and under what terms, has to infer it from marketing copy, a terms-of-service page written for lawyers, and whatever the API returns when it tries.
The mechanism is consolidation rather than novelty. Every field in a catalog exists somewhere already: the service description is on the homepage, the auth posture is in the docs, the rate limits are in a support article, the schema is wherever the schema is. However, each of those locations is prose, and prose has to be parsed and interpreted, which is exactly the step that goes wrong. Putting the same facts in one structured document at a predictable path does not add information. It removes the interpretation, and it does so in a form that stays stable when your marketing site is redesigned.
Adoption is genuinely low, and I am not going to attach a percentage to it, because the credible measurements do not exist yet and inventing one would undermine the point of the audit. What can be said is that the cost of publishing is close to zero, the file is static, and the downside if the format does not become dominant is a small JSON document that nobody reads. That is a favorable asymmetry, which is the honest argument for it, rather than a claim that agents are queuing up to fetch it today.
MachineRead publishes its own catalog at /.well-known/ai-catalog.json and checks yours as one of the 4 agent-consumable surfaces and one of the 8 default agent-readiness probes. The weighting is deliberately modest. Scoring an emerging convention as though it were load-bearing would produce exactly the inflated urgency the audit exists to avoid, and a site that fails this probe while passing bot access and structured data is in far better shape than the reverse.
So my recommendation is to treat this as the last item on the discovery list rather than the first. Fix fetchability, then structured data, then the API schema if you have an API, and then write the catalog, since ten lines of JSON describing your service, its surfaces, its auth posture, and its limits is an afternoon at most. Meaning you publish it, link it from your API catalog so the two reference each other, and then leave it alone. If agentic discovery consolidates on this format you are already there, and if it consolidates on something else you have lost an afternoon and gained a clear statement of what your service does, which is not a bad consolation.
See also
- Methodology reference - documents the ai-catalog probe and the machine_surfaces check group
- Launch post - covers how ai-catalog fits the four agent-consumable surfaces
- Related: api-catalog.json and llms.txt