Agents are the majority reader now
A coding agent answering from your docs is answering from the commit you merged. This month there is data on how much that matters.
Matthew Blode
What the report measured
Mintlify published its 2026 State of Knowledge Report this week, built on server-side traffic from the docs it hosts between February and August. In August, agents made 257 million requests against 131 million human page loads. That is 66% of readership, up from 21% in February, and 83% of it arrived through the machine-friendly routes: the .md version of a page, an llms.txt index, or an agent skill. Agents request those files only when they know they exist.
It is the data of the host we compare ourselves against, and it argues for the same thing whichever host you pick: the Markdown an agent reads has to exist, has to be findable, and has to be current.
Reading was never the problem
The part worth acting on is a controlled benchmark: 2,400 tasks across 20 documentation sites, run with Claude and Codex, the same docs served four ways. Answer accuracy stayed between 94% and 99% in every format. What moved was navigation. Agents fetch a page, guess a sibling URL, get a 404, back up, and guess again.
| Format served | Failed requests per task |
|---|---|
| HTML | 2.23 |
| Markdown | 1.42 |
| Markdown with a link to llms.txt | 0.11 |
Stripping a page to Markdown removes the sidebar with the chrome, so a bare .md file leaves an agent with nothing to navigate by. One link to the index fixed most of it, a 20x improvement over HTML, and the same runs used 26% to 60% fewer tokens. The map is worth more than the Markdown.
What a Blode.md deploy already does
Every deploy writes llms.txt, llms-full.txt, and a .md twin of every page from the same MDX as the HTML. Each twin opens with a blockquote that names the HTML page and the index before the content starts, which is the exact shape that scored 0.11 in the benchmark. The Link header on every HTML page advertises the index and the page's Markdown alternate, so an agent learns the routes exist from the first response. Nothing is hand-authored, so nothing drifts from the commit.
The report also puts numbers on the drift. Only 24% of teams get a product change into their docs the same day; 22% take a month or longer. An agent that reaches a stale page does not notice. It writes the old parameter into a codebase. Publishing from the merge that changed the product, through the GitHub App or a CI push, is the only fix that does not depend on someone remembering.
What is on you
Two things. First, give every page a one-sentence description. It becomes the page's line in llms.txt, and that line is how an agent decides which page to open. A page without one lists as a bare title. blodemd validate now warns when pages are missing it. Second, keep the changelog and migration notes inside the docs folder, because the index is where an agent looks when a parameter it was told about has gone.
The full list of what ships and what you control is in Docs for agents.
What we do not do yet
We do not show you how many agents read your docs. PostHog on a docs site counts humans, because agents run no JavaScript, and we have not built the server-side count. Until we do, the honest number is no data, and if you need it you can put a proxy you can log in front of the docs and count requests for .md, llms.txt, and the AI user agents.
Try it
Sign in with GitHub and push. The merge publishes the site and the Markdown agents read from that commit.