Agent Readiness for Technical Documentation — Part 4

Part 3 of this series documented two agent-readiness scan results against DoveRunner Docs, our developer documentation site: 43/100 on isitagentready.com and 0/100 on Fern Agent Score. Both pointed to the same root problem: the infrastructure for agents to consume this documentation optimally was not in place.

This post covers the fixes we applied to the infrastructure layer.

The Starting Point: isitagentready.com

isitagentready.com scored DoveRunner Docs at 43/100 — Level 1: Basic Web Presence on a content-site profile. Of seven applicable checks, four were failing.

Three fixes addressed three of the four failures. The fourth, DNS-AID, was a deliberate skip.

Fix 1: Link Response Headers

Effort: Low

Link headers (RFC 8288) let a server declare relationships between resources in the HTTP response. For agent readiness, the relevant use is pointing to the Markdown version of a page: an agent that reads the header knows where to find clean content without parsing HTML first.

DoveRunner Docs was not emitting any Link headers. We solved this with a simple configuration change in Vercel, the cloud platform hosting the website.

Score: 43 → 57

Fix 2: Markdown Content Negotiation

Effort: Medium

This was the most involved fix because it required changing how the site is built, not just how it is served.

The requirement: when an agent sends Accept: text/markdown in its request, the server returns the page as plain Markdown instead of HTML. HTML contains navigation elements, sidebars, and layout markup that add noise when an agent is trying to read documentation. Markdown is what agents work with cleanly.

DoveRunner Docs is a statically built site. The source content is written in Markdown, but every HTTP response is HTML. The fix required pre-generating a Markdown version of every page at build time and configuring the CDN to serve those files transparently when the Accept header matches. We didn't change anything in the documentation content itself nor the source files. Only the delivery layer.

The result: agents sending Accept: text/markdown now receive clean Markdown. Browsers requesting HTML still get HTML. The same URL handles both.

Score: 57 → 71

The DNS-AID Decision

Check: Discoverability / DNS-AID Decision: Skipped, not applicable

DNS-AID is a specification for an agent to register itself in an agents directory. It is designed for agents that need to be discovered by other agents or orchestrators.

DoveRunner Docs is a documentation site being made ready for agents to consume. It is not an agent registering itself. The check does not apply.

This distinction is worth flagging for any team running the same scan. Not every check in an agent-readiness tool assumes the target is a content site. Some assume the target is itself an agent. Reading the check description before treating a failure as a fix priority saves effort.

Fix 3: Content Signals

Effort: Low, one line in robots.txt

Content Signals is a standard that lets a site declare its AI usage preferences directly in robots.txt. Three preferences matter here:

• ai-train: can this content be used to train AI models?
• search: can search engines index it?
• ai-input: can AI agents use it as context?

For DoveRunner Docs, each choice is intentional.

• ai-train=no: DoveRunner's documentation contains proprietary integration patterns and platform-specific implementation details. Using it to train AI models could benefit competitors. The documentation should help developers who work with DoveRunner's products, not serve as a training corpus for anyone else.
• search=yes: Public developer documentation should be indexed. No reason to restrict this.
• ai-input=yes: This is the purpose of the entire agent-readiness project. The documentation is being optimized so AI coding agents can use it as context when helping developers integrate. Blocking this would contradict the goal.

The practical value of Content Signals is this distinction: ai-train=no, ai-input=yes. A blanket Disallow: GPTBot block makes documentation invisible to the agents it was meant to help. Content Signals let a site say something more precise: use our docs to assist developers; do not use them to train your model.

Score: 71 → 86

The Result

Final score: 86/100 — Level 5: Agent-Native

Three fixes. No documentation content was touched. The improvement from 43 to 86 came entirely from infrastructure: how the site is served, what headers it emits, and what it declares about its own AI usage preferences.

That is the point of separating infrastructure from content in the agent readiness framework. The two problems require different remediation approaches and move on different timescales. Infrastructure gaps close in days. Content gaps require tracing actual integration journeys through the documentation which will covered in the next part.

Mapped to the three-stage maturity model from Part 2:

• Stage 1 (Discoverability): Substantially complete. robots.txt, sitemap, and Link headers all pass. One meaningful gap remains: llms.txt, the machine-readable site index for AI agents. That is a Fern Agent Score check, not an isitagentready.com check — addressed in the next section.
• Stage 2 (Governance): Complete. Markdown delivery, Content Signals, and AI bot rules all pass.
• Stage 3 (Controlled Interaction): Not applicable. API Catalog, MCP Server Card, and OAuth Discovery are not necessary to document-based content websites.

The Second Scanner: Fern Agent Score

The second tool, Fern Agent Score, measures a different layer. It looks at whether the site publishes a single index file that lists every page for AI agents, and whether it serves clean text versions of those pages.

That tool scored DoveRunner Docs at 0 out of 100 at the start. The number looked alarming, but the cause was simple: the site had no llms.txt, or index file for agents. Without one, the scanner could only find a single page to look at, so almost every category came back blank and the score collapsed to zero. The machinery for serving clean content to agents was already built (that was Fix 2 above). The site had simply never published the index that tells agents it exists.

One file, one decision

The popular way to add llms.txt to a static documentation site like ours is a ready-made plugin. We tried it and removed it. It bundled five features when we needed one, and it brought version conflicts with tools we already used. Instead, we wrote a small piece of code, modeled on patterns already in our codebase, that regenerates the index automatically every time the site builds. No extra dependencies, and the index can never fall out of date with the pages.

A plugin that bundles five features is a bad trade when you need one and already own the other four.

From 0 to 99

Publishing llms.txt jumped the score from 0 to 91 immediately. The last few points came from two bugs that only showed up once the site was live. Both taught the same lesson: test the way the agent tests.

• The first attempt put the agent-facing pointer in a part of the page the scanner doesn't read. Moving it to where the scanner actually looks fixed the problem.
• The second was subtler. Our manual tests all passed because we tested page addresses with a trailing slash. The scanner tested them without one. And on those, the server quietly returned the wrong format. Reproducing the scanner's exact request made the bug obvious in seconds.

The final Fern Agent Score: 99/100. The single remaining point is a content problem, a couple of oversized pages that should be split, so we stopped there on purpose. The whole effort cost one new piece of code, one small template change, a handful of config lines, and zero new dependencies.

When a check disagrees with your own testing, reproduce exactly what the checker does before assuming it is wrong.

What's Next

Both scanners are now addressed. 86 on the first, 99 on the second. That covers the infrastructure layer: whether agents can find and consume the documentation. It says nothing about the harder question, whether agents can generate correct integration code from it.

In the final post (Part 5), I will show you how AI agents help identify and fix issues in the content layer of documents.

This series documents a systematic effort to define and close the gaps between DoveRunner's developer documentation and what AI coding agents need.