Skip to main content

​
On the data and methodology

You’re right that we can’t be 100% certain, but these endpoints were purpose-built for AI consumption and have no meaningful human use case. Someone typing /llms-full.txt into a browser is essentially unheard of. Other than technical writers checking their own files, few human users even know these endpoints exist. It’s the clearest signal we have, which is why we treat it as “certain” rather than “inconclusive.” Traditional bots (link checkers, SEO crawlers) don’t target AI-specific endpoints.
The range is the honest answer. The 9.3 million events between those percentages are genuinely ambiguous. High-volume clients wearing human user agents. We could pick a midpoint, but that would be false precision. The range tells you something true: 35% is the floor (only traffic we trust), 47% is the ceiling (everything suspicious is attributed to AI). The gap is the size of our uncertainty and will shrink as we refine how we detect AI traffic.
For behavioral patterns—conversation length, message style, verbosity by turn—yes. These reflect stable user behaviors that don’t change dramatically day-to-day. For volume trends, seasonal patterns, or day-of-week effects, a single day may not be sufficient.
This data is aggregate analytics, the same category as web server logs. No personally identifiable information is stored. IP addresses are used for pattern detection (identifying bot clusters) and cloud provider attribution, not for tracking individuals. The analysis is at the level of user agent and IP pairs and event counts. There are no user profiles or identities involved.
This data is a snapshot. What we can say is that 35-47% is where we are today, and the infrastructure (llms.txt, MCP tool integration) is still being broadly adopted. The ceiling is likely higher as more AI products add documentation retrieval.

​
On the AI agents

Both, probably. “Claude” in the named agent breakdown is a group of distinct user agents:
  • ClaudeBot — Anthropic’s crawler, used for training and indexing
  • Claude-User — Claude responding to a user query in real time, fetching docs to answer
  • Claude Code — the coding agent fetching documentation programmatically during development tasks
They all show up with distinct user agent strings and we group them under “Claude.” The 591K figure is the aggregate. Claude Code alone was 11,008 events in the same 24-hour window.
Less “write for Claude” and more “write for machine consumption generally.” Clear structure, good headings, concise section introductions, explicit context—these help agents and humans alike. The optimization isn’t at odds with good documentation practice; it raises the stakes for structure.The most AI-specific thing you can add is llms.txt. It’s the entry point agents use to orient in a doc site. Everything else is just good documentation hygiene.As evidence rises that agents need shorter file sizes than humans, writing for the two audiences may diverge.
Model Context Protocol is an open standard that lets agents call tools and fetch structured data from external sources. A documentation site that implements MCP exposes a search or retrieval tool that agents (like Claude) can call on demand, rather than relying on a cached crawl. It’s a more direct, more accurate integration between agents and live documentation. Mintlify implements MCP natively, which is what the MCP events in the traffic data represent.

​
On the Read layer

We don’t. 55% one-and-done could mean “got the answer immediately” or “gave up immediately.” The data is silent on this. Designing to find out—a simple thumbs up/down, a follow-up prompt—is part of the process. If you can’t distinguish success from abandonment, you can’t improve. You shouldn’t rely on only quantitative data to make decisions.
Users hit a wall. By turn 7 they’ve tried and failed several times, so they switch strategy—dumping all context at once hoping something sticks. This is a known pattern in human-computer interaction when the system doesn’t behave as expected. Average response length at turns 6 and 7 reaches 70-150 words vs ~32 words at turn 2. It’s an intervention opportunity: if you can detect turn 5-6 degradation, you can surface different help before the user gives up.

​
On the Write layer

Writing agents are multi-step by design. They read existing docs, check a codebase, draft content, verify, revise. Each step is a separate API call. The reading assistant is effectively single-shot: one question, one answer. The 19.7 vs 3.3 ratio reflects architectural difference, not inefficiency.

​
On the craft

Yes, in specific ways. Agents don’t scroll, don’t click “show more,” don’t infer context from page layout. They parse text.
  • Clear headings matter more, not less. They’re navigation signals for machines and humans
  • Code examples should be self-contained. An agent may retrieve just the code block
  • Avoid burying key information in sidebars or tabs. Agents often don’t see them
  • Write section introductions that stand alone. Agents often retrieve just one section
  • llms.txt is the entry point agents knock on. It’s no longer optional
None of this conflicts with writing for humans. It raises the stakes for structure.
We can’t answer that from this data. We’re seeing shares, not absolute human trends over time. What we can say is that AI is adding a massive new category of reads on top of whatever humans are doing. Whether humans are reading more, less, or the same is a genuinely separate question this data doesn’t address.