Agents do not read your docs. They fetch them.

An agent that arrives at your documentation does not browse it. It fetches a URL, parses what comes back, looks for the next URL, and repeats until it has enough to act. Every hop spends context, and the context runs out.

Most teams treat machine-readable documentation as an inventory question. Do we publish llms.txt? Is there an OpenAPI file? Have we shipped an MCP endpoint? Three yeses and the ticket closes.

The agent is answering a different question. From a cold start, how many fetches and how many bytes does it take to construct a request that comes back 200? That number is a property of the path between your files, not of the files themselves — and you can publish all three artifacts without the path existing.

The only number that matters

Call it agent time to first call: the distance, measured in fetches and bytes, from an agent's first request to your site to the first request it can send to your API with a reasonable expectation that it will work.

It is deliberately not the same as time to first call for a person. A human number includes creating an account, waiting for a verification code and finding the key in a dashboard — mostly latency that has nothing to do with documentation. Mixing the two produces a figure that moves when your email provider has a slow morning.

The agent number isolates one thing: whether the machine-readable surface actually connects. It is cheap to measure, it is reproducible by anyone from outside, and — this is the uncomfortable part — you should run it on yourself before you quote it about anyone else.

Four files, four different jobs

The four artifacts in this conversation are routinely discussed as if they were alternatives. They are not. Each answers a question the others do not.

Having four working files is a starting condition, not a result. The result is whether an agent that lands on the first one reaches the third.

How to measure it

The procedure is short enough to run by hand in an afternoon, and it is worth running by hand the first time — automating it early hides the places where you quietly helped.

1. Start cold — the first fetch is /llms.txt. No search engine, no memory of the site, no URL you happen to know.
2. Follow only machine-resolvable links — anything behind a sign-up wall, a cookie gate or client-side rendering is a dead end for this measurement, whatever it looks like in a browser.
3. Stop at constructibility — the moment the agent has a method, a full URL, the shape of the auth header and the body format, the route is over. Not when it has read everything: when it could send something.
4. Record fetches and bytes — both, because they fail differently. Fetches cost latency and tool calls; bytes cost context.
5. Repeat per route — there is rarely one path, and the shortest one is not always the one your index recommends.

What ours measured

We ran it against the published tree on 2026-09-05. Three routes end in a constructible call, and they are not close to each other.

The spec route is the cheapest that a machine can act on without prose parsing: 54 KB against the corpus route's 642 KB, which is roughly 8x the bytes for one fetch fewer. That is the trade every agent makes, and it is the reason a single large corpus file is a fallback rather than a plan.

Then the measurement turned up two things we had not been looking for.

The index that forgot the corpus

120 pages on this site tell assistants, in so many words, that Cogneris publishes its full site text at /llms-full.txt. The file is real, current and 641,634 bytes.

llms.txt — the index an agent reads first, and the one artifact whose entire job is to point at the others — links it zero times.

So an agent that follows the convention exactly, fetching the index and walking its links, never arrives at the corpus. It gets there only by already knowing the URL, or by reading one of the 120 pages first, which means it did not need the index. Nothing was broken. The file was fine, the pages were fine, and the path between them did not exist — which is precisely the class of defect that no test fails on, because nothing looks.

"Optional" is an instruction, not a label

Our llms.txt carries 146 links across 12 sections. The OpenAPI file is in the last one, under the heading ## Optional.

In the llms.txt convention that heading has a defined meaning: secondary material, safe to skip when the context window is short. We had therefore filed the one artifact that lets an agent construct a call in the section that tells agents to drop it first, immediately after About and Contact.

The same file is absent from all 280 URLs in sitemap.xml, so a crawler that walks the sitemap instead of the index never encounters it either. Neither of these is a bug — both files are valid, both parse, both are served. They are placements. And on a machine-readable surface, placement is the entire mechanism: an agent does not notice that something important is in the wrong section, it just never reads it.

MCP moves the finish line, not the starting one

Our MCP endpoint publishes 11 tools across 2 scopes, over streamable HTTP, with OAuth 2.1 and PKCE. For an agent that speaks the protocol it is a genuinely shorter route: tools/list returns typed, callable tools, so the parse step disappears entirely and there is no spec to interpret.

It does not shorten discovery. The agent still has to learn that the endpoint exists, and that fact lives in ordinary documentation — in our case, correctly, in the ## Documentation section of the index rather than in ## Optional. MCP is a faster last mile attached to the same first mile.

What this is not

This is not generative engine optimization, and conflating the two is how the work gets misfunded. GEO is about being cited — a person asks a model a question, and your material is good enough to be summarized back to them. The reader is human and the outcome is a mention.

This is about being called — software that has already decided to use you needs to construct a valid request. The reader is a program and the outcome is an HTTP status code. A page can be beautifully cited and completely uncallable, and the two failures share no symptoms and no fix.

The floor no documentation can lower

Every route above terminates at a request that needs an API key, and no arrangement of files issues a credential. That is a real ceiling on what this measurement can claim, and it should be stated rather than absorbed.

So publish it as a floor: documentation time to first call, with the credential step excluded and named as excluded. A headline number that quietly includes a person pasting a key measures that person's reaction time and calls it your developer experience — the same error as publishing a latency figure that includes the time somebody spent looking for the tab.

Worth an afternoon

The whole exercise is four steps, and the first two are the ones that find things.

1. Fetch your own index cold — then follow only its links, and see where you stop.
2. Check what your pages promise — anything they advertise to assistants should be reachable from the index, not merely served.
3. Read your section headings as instructions — ## Optional is a directive to skip, so nothing an agent needs belongs under it.
4. Record fetches and bytes, with a date — the number changes every time the site does, so an undated one is a claim rather than a measurement.

Ours is published above, with the date and the routes, so it can be checked against the live files rather than taken on trust. The quickstart is the shortest human route to the same first call, and the MCP server is the shortest one for an agent that speaks the protocol.