Your Docs Have a Second Reader Now

Something started reading your documentation that does not care how it looks.

It does not see your theme. It does not scroll your sidebar or notice that you finally fixed the dark-mode contrast. It fetches a page, strips it to text, and tries to answer a question or make a call. The fastest-growing reader of API documentation has no eyes, and most docs are still written as if every reader does.

Two readers, one source

Documentation Is the Contract Surface makes the case that documentation became the surface humans and agents both ground on. That is two audiences with opposite needs reading the same pages. The human wants layout, navigation, and a sense of place. The agent wants the reverse: no chrome, no JavaScript to execute, just structured text it can pull into a context window without driving a headless browser.

You cannot serve both by picking one. You serve both by generating both from the same source. That is what llms.txt and llms-full.txt are: a flat, linkable, plain-text view of the same documentation graph that renders the HTML.

# Cheese Store API

> A sample REST API, documented with Sourcey.

## Endpoints
- [List cheeses](/api/list-cheeses): GET /cheeses
- [Add a cheese](/api/add-cheese): POST /cheeses
- [Authentication](/guides/auth): API keys in the Authorization header

The snippet is boring on purpose. That is the point: it is the docs with the cinema removed, which is exactly what the machine reader wanted all along. One build, two outputs, nothing kept in sync by hand.

Why the incumbents will be late

A hosted docs platform optimizes the surface that closes the deal, and the surface that closes the deal is the polished human one in the procurement demo. The agent does not attend the demo. It has no seat in your plan and no line in the contract. To a subscription business, a first-class machine surface is a cost with no buyer attached.

So the incumbents will ship it eventually, slowly, as a checkbox, because their incentive points at the human evaluator and the agent is someone else’s problem. The reader growing fastest is the one their pricing was structured to ignore.

The byproduct that becomes the moat

Sourcey emits the machine view because it is a renderer sitting on top of source you own, not a platform selling a hosted experience. Once the source graph is in hand, the plain-text view is nearly free to produce; it falls out of the same build that makes the HTML. There is no tier to unlock it, because there is no platform underneath to meter it.

That inverts the usual order. For a hosted docs product, agent-readability is a feature it has to be talked into shipping. For a tool that already owns the source and outputs static files, it is a default it would have to go out of its way to remove. The advantage is not cleverness; it is that the machine reader and the file owner want the same thing, and the subscription model wants something else.

Write for the reader that cannot complain

The human reader tells you when your docs are bad. They file issues, they post on Hacker News, they email. The agent will not. It will quietly ground on a stale endpoint, invent a parameter you renamed, and hand your user a call that 400s, and you will never see the bug report. The second reader is silent, which makes the quality of what you feed it your problem, not its.

The teams that win the next few years of developer tooling will be the ones whose docs are correct in the format a machine ingests, not only beautiful in the format a human admires. Owning your output and emitting a machine view from it is how you stop guessing which reader you built for. You built for both, from one source, and you can prove it by reading the file the agent reads.