Part 4 covered the infrastructure layer of DoveRunner Docs. We added response headers, made the site serve Markdown to agents that ask for it, and declared Content Signals in robots.txt. Our score on https://isitagentready.com went from 43 to 86 out of 100, and our Fern Agent Score from 0 to 99.
Through all of it, we never touched a word of the documentation itself.
This is why we treat Agent Readiness as two separate layers. On the infrastructure layer, a scanner tells you what passes, what fails, and what to fix. The content layer has no such tool. An agent being able to read your docs cleanly and an agent producing correct integration code from them are two different things.
In this post I’ll walk through what was actually wrong in the content layer of DoveRunner’s documentation, how we found and fixed it with an AI agent, what shipped to production, and where the work stopped short.
Overview: how the work ran
The project ran in six steps. The point of this post is where the agent’s half ends and ours begins, so here is the sequence first.
- The agent reads the Markdown sources, following integration workflows rather than individual pages.
- It logs each problem it finds with a type, a description, and the location in the source.
- It fixes what it can, edits the source files, and records the outcome next to each entry in the list.
- We open one pull request per product line.
- The product owner for each line reviews and confirms the changes to their product’s docs.
- We deploy to production.
Finding problems along the integration journey
Audit a doc site page by page and you get page-level findings: typos, broken links, a parameter left undescribed. Those are worth fixing, but they are rarely why an agent writes the wrong integration code.
So we used the end-to-end integration scenarios we had written for each product line from the customer’s point of view. A single journey a developer actually walks (from requesting a FairPlay certificate, through packaging, to confirming playback in an iOS player) became one unit, and the agent read every document that journey touches as a set.
Read this way, problems appear that no single page reveals. Each page is correct on its own, but information falls through the gap between them. The format one document hands off doesn’t match what the next one expects, or a prerequisite lives buried in the middle of another product’s guide instead of where it is needed.
The most dangerous finding in this audit was exactly that kind. When Forensic Watermarking is used together with Transcoding & Packaging (T&P), T&P writes the watermarked output into a specific folder structure. When a viewer starts playback, the server needs to know where that output lives, and the session-issuing API takes it through the prefix_folder parameter. The session API doc described that parameter correctly. The T&P doc was the problem: it said nothing about the folder structure it produces, or about the fact that the value has to be passed along at the next step.
Neither document is wrong on its own. But a developer or an agent working from the T&P doc alone had no way to know a value needed passing at all. Omissions of this kind don’t surface as an error message. They surface as playback that doesn’t work, which makes them slow to diagnose. The fix was a caution block in the T&P doc describing the folder structure and the parameter requirement, cross-linked to the session API section. It took minutes to write, and it was invisible until the two documents were read as one journey.
Across six product lines, this stage produced 71 content issues. Each entry carried a type (error, gap, or placement), a description, and the source file and line it came from. That list became the baseline for everything that followed.
The agent fixes, people review
With the list in place, we had the agent work through the entries it could handle. Because the docs are already managed as Markdown, editing the source needed no format conversion in between. After each fix, the agent wrote what it had checked and what it had changed into the remarks column of the list it had built. The issue list became the work log.
Here we made one deliberate choice. Rather than bundling 71 fixes into a single pull request, we split them by product line into three:
- Multi-DRM
- Watermarking / Anti-Piracy
- Mobile App Security
Each pull request was assigned to that line’s product owner (PO) as reviewer. The reason is review quality. The only people who can judge whether a documentation fix is factually right are the people who know the product. A PO handed 71 mixed changes has to page through edits that have nothing to do with their product, and review in that situation tends to go through the motions. A pull request containing only their own product’s changes is short enough to read line by line.
All three POs confirmed that their documentation had been corrected as intended, and we deployed.
Results, and the nine that remain
Here is where the full review landed.
| Outcome | Count |
| Fixed | 59 |
| No change needed (checked, not an issue) | 3 |
| Blocked on another team | 9 |
| Total | 71 |
That is 83%. But the number that taught us more was the nine still open, because they had something in common. In every case, the answer was not in the documentation at all.
An agent can read the entire corpus. So it is good at problems where the answer is somewhere in the docs but not where it needs to be: a detail explained on another page, a mismatch between what one document hands off and what the next assumes. The agent fixed 41 issues that way, and another 13 turned out to have been resolved already.
What an agent cannot do is produce a fact that exists nowhere in the corpus. Group the remaining nine by who has to weigh in and the pattern is clear:
- Needs the product teams: recommended API behavior and some response formats required for automated integration aren’t documented. Nearly half of the nine sit here.
- Needs platform team and business stakeholders: console labels, the supported scope of certain product types, and procedures entangled with contracts and legal review. All of them need confirmation from outside the docs before they can be written down.
None of these is a writing problem. Before you can document a recommended polling interval, someone has to decide what it is. Before you can document a token expiry, someone has to confirm the value is contractual behavior. These are decisions that have to precede documentation, and a developer relations (DevRel) team cannot resolve them alone.
That distinction was the most useful thing this project produced. All 71 items looked like documentation issues of equal weight at the start. After a full review, 62 of them were solvable by editing documentation, and nine were never documentation problems at all. They were unsettled organizational decisions showing up in the docs.
What the agent could take on
Looking back at the six steps, the agent handled steps one through three.
Reading, cataloguing, and fixing share a shape. The volume is high, the criteria are reasonably clear, and a person can verify the result afterward. Cross-checking six product lines’ documentation along integration journeys is tedious work that people skip parts of. It suits an agent well.
Steps four through six stayed with us. How to split the pull requests, who should review them, and what to ship are judgments about organizational context. Step five in particular has no substitute: deciding whether any of the agent’s 71 edits got a fact wrong requires someone who actually knows the product.
When you bring AI into documentation work, that boundary is a reasonable place to set expectations.
Closing
That covers how we audited and fixed the content layer of DoveRunner’s documentation.
Five posts reduce to one idea: Agent Readiness isn’t a score, it is two different kinds of work. On the infrastructure layer, a tool names the problem and an AI agent can resolve it quickly. On the content layer nothing names the problem for you, so you have to build the baseline yourself out of real integration journeys, and the last 10% or so of what you build can only be resolved by people.
If you work with DoveRunner’s documentation, everything described here is live at DoveRunner Docs. If something in the docs blocks you, tell us. As this project showed, the hardest problems to find come from the people who have actually walked the journey.