Will My Agent Answer This?

Part 1

The problem

The problem is that an AI support agent never reads your article. Software splits it into pieces and files each piece separately. It does not split at every heading, either: one vendor picks a single heading level for the whole article and cuts only there, so a piece can carry several of your sections, and adding one heading can move every boundary in the document. When a customer asks a question, it retrieves the few pieces that best match and the agent answers from those alone, without the title, the introduction, or the paragraphs that came before. So a section that only makes sense in sequence is a section the agent will get wrong.

The test for that is manual, and it is the routine two vendors describe in Part 2. It fails for two reasons. It asks a writer to imagine how retrieval software reads, which is not a skill anyone was hired for, and at the size of a real knowledge base it is a second job rather than a test. Knowing what breaks an answer belongs in a tool that applies the same judgment to every section, not in the head of each author on each paragraph.

Jobs To Be Done describes the progress someone wants rather than the feature they asked for. Here the job is:

That job belongs to the person who owns the content, not to the engineer who configured the retrieval software or the marketer chasing mentions in AI search. Their target for tickets resolved without a human is now tied to somebody else's model, and their worst day is a customer being told something untrue with complete confidence.

The forces of progress

The Forces of Progress model asks what pushes someone away from how they work now, what pulls them to something new, what makes them nervous, and what keeps them where they are. Adoption needs the first two to outweigh the last two.

Neither of those worries is a marketing problem. Each one settled a piece of the architecture, which is decisions 1 and 2 in Part 5.

Part 2

The evidence

The manual test is being recommended in public, by the vendors selling the agents. Every quote in this first list was re-checked at its own page in August 2026; the mechanism evidence further down was checked separately, and carries its own date.

• SearchUnify Building an AI-Ready Knowledge Base, published 1 July 2026

  "Pull a paragraph from the middle of each one, remove the title and surrounding context, and read it the way an agent would, as a standalone fragment. If that fragment alone isn't enough to produce a reliable answer, the knowledge base is the performance bottleneck."

  A later answer in the same guide gives the rule behind the test: "if a section can't be understood without reading what came before it, it needs to be rewritten." Read the guide.

• Rankscale Chunkability for RAG, under the heading "The paste-into-a-blank-doc test"

  "Cut it, paste it into a blank document. Read it cold… Rewrite. Repeat for every paragraph on the page."

  A different vendor arriving at the same hands-on routine. Read the module.

• Rezolve.ai on auditing the content you already have

  "It's common for only a small percentage of content to be AI-ready in its current form."

  Read the post.

• RefineTrain AI Y Combinator, W22
  A funded company whose business is rewriting and optimizing internal documentation for LLMs, which tells me this is a fundable problem rather than a private irritation.
• Gartner press release, March 2025 · a prediction, not a measurement
  By 2029, agentic AI will autonomously resolve 80% of common customer service issues without human intervention, leading to a 30% reduction in operational costs. Gartner press release. Graded: this is an analyst's forecast about 2029, not an observation of anything that has happened. It is worth citing because it tells you where the buying is pointed, and it is worth nothing as proof that agents fail on today's articles. Nothing in this teardown rests on the 80% being right.

The mechanism, documented by the vendors

The evidence above is about demand: people are being told to run this test by hand. This is a different kind, and it arrived later. Three companies document the retrieval mechanism itself in their own technical documentation, and two of them instruct writers to do exactly what this tool scores. Every quotation below was checked at the vendor's own page on 13 August 2026.

• Moveworks Writing AI-ready KB Articles for Moveworks, under "Snippetizing Best Practices"

  "Ideally, ensure each section can be understood independent of the rest of the article when served as a snippet."

  The same page, under "Content": "Do not rely on article hierarchies to provide context". Read the guidance.

• Intercom Optimizing content for Fin, updated 30 June 2026, under "Repeat key terms throughout (Entity distribution)"

  "When Fin retrieves a section mid-article, it needs enough context to know what's being discussed."

  Read the article.

• Zendesk Optimizing your knowledge content for generative AI

  "Repeat the question or topic from the title. This ensures that context isn't lost during chunking, and avoids separating questions from their answers."

  Its instruction to writers, under "Best practices for writing content for AI use", is the heading "Create self-contained content". Read the article.

This does not calibrate anything. The weights are still my judgment and the score is still uncalibrated, for the reasons in what I got wrong. What it changes is the premise underneath the weights. The claim that a section is retrieved alone and has to survive alone is no longer only my reading of the problem; it is how three vendors describe their own products, in the pages they write for their own customers.

Part 3

Market and incentives

One outside number, and it is a forecast rather than a measurement: Gartner's 2029 prediction above. It gives direction, not size, and nothing here rests on it. A market-size projection used to sit alongside it and has been cut, because the same firm published a materially different figure for the same market, and a number I have to caveat twice is not evidence.

The tool sits in the author's workflow, at the point where an article either becomes answerable or does not. That point is upstream of the retrieval software and the agent, and it is also what enterprise platforms sell as a paid readiness audit rather than as software you can use yourself.

Why the incumbents will not build this

What follows infers motive from business model, so I flag it as my reading rather than anything these companies have said.

• Enterprise knowledge platforms such as Bloomfire, SearchUnify, Rezolve and DevRev sell AI readiness as audits, modules and services, and a free paste-an-article tool eats into that revenue. The pricing is the tell: Bloomfire publishes its own guide on auditing a knowledge base for AI readiness and sends you to a sales form rather than a self-serve plan.
• AI search visibility tools make their money from marketers who want public pages quoted in AI answers. An internal knowledge-base author has neither a public page nor a budget line.
• Retrieval infrastructure vendors sell to the developers who configure pipelines, not to the writers who produce what those pipelines read.

Any of the three could build this in a sprint, so the opening is not technical. It is a gap in incentives, which is a sturdier thing to sit behind, and the same shape as the argument in my previous teardown about why Google will not fix Takeout's metadata. A gap that exists because nobody thought of it closes the moment somebody does. A gap that exists because closing it costs the incumbent money stays open.

Part 4

Found by elimination

This tool was not the first idea, it was the survivor. Around fourteen candidates were researched for how crowded they already were before any code was written, on the assumption that a free browser tool with no marketing budget cannot win a crowded space. Eleven were cut, and the verdict column repeats because the finding did.

The strongest product decision in this project is the eleven tools that don't exist.

The surviving space

The columns below are the six things the job needs at the same time. None of these products is bad; none of them is aimed at this person doing this task.

Both near misses are closer than a competitive table usually admits, and one got closer after I built this. The retrieval preview tools are free, take pasted text, and show the pieces a document breaks into, which is exactly the right raw material. This tool shows those pieces too now, so that is no longer a line between us. Two things still are. Their preview runs a generic splitter where this runs one named vendor's published algorithm, so the boundaries are the ones a real product would produce. And they stop at the boundaries: showing an author their article in fragments answers "what will the software store?", not "can an agent answer from this?" The visibility checkers score two of the same things, but for a marketer chasing citations on a public page. Neither asks whether a section still stands up once retrieval has pulled it out alone, which is the check carrying the most weight here.

Part 5

What I built

I built one web page. You paste in an article and get a score out of 100 for how well an agent could answer from it, across five checks: whether sections stand alone, whether the answer comes first, whether references point at something nearby, whether each section holds one idea, and whether the structure is clear. The checks are weighted 25/20/20/15/20 with 25 rules underneath, no single check may fail while the article is called agent-ready, every finding is marked in your own text, and every point lost is itemized. The report also draws the boundaries where one vendor's software would cut the article into pieces, and scores those pieces for size.

Marty Cagan's four product risks are the spine here: value (will anyone want it), usability (can they use it), feasibility (can it be built) and viability (does it work for the business). Each decision names the one it settles.

Kano classification

The one classification that changed anything: reading headings correctly is a must-have, not a feature. Get it wrong and every boundary is in the wrong place, and nobody reports that as a parsing bug, because they simply stop believing the score and leave.

Scope, made legible

Business viability, stated plainly

The business case is that there is no revenue model and none is planned. Willingness to pay exists, since enterprise platforms charge for this analysis as audits, but free with no strings is the position rather than a plan to charge later. What I am betting on is the judgment on display, in the public version of the work I do, which is organizing knowledge content so autonomous agents can resolve tickets.

What I got wrong, and what is still open

1. The scoring model certified articles it should have refused, and it did it two different ways. A check worth 15% could be driven to zero and the article still scored exactly 85.0, which read as agent-ready, while the same collapse on the 25% check gave 81.25 and failed. Whether a failed dimension sank an article depended on nothing but which dimension it was. Fixing that turned up the second door: the band was decided on the rounded composite, so 84.75 displayed as 85 and passed on a rounding artifact. Both are closed, by a floor at the 60 this page already called a fail and by banding on the unrounded average. Every number needed to spot the first one was printed on the scoring page from the day it shipped. The lesson is not "test the code", because the tests passed. It is that a scoring model needs its boundaries worked by hand before it is published, and that when one boundary bug turns up the question is how many ways there are to reach that boundary.
2. Two rules were each correct and together produced nonsense. The same table, in the same section, was celebrated as a strength and flagged as an answer the assistant cannot read out. Both readings are right: a table is the correct shape for a comparison, and a table nobody has summarized in prose is an answer that never gets spoken. Delivered together they read as a tool that does not know its own mind. Praise is now suppressed when a finding lands on the same block, and the reference article was rewritten to state its answer in a sentence and keep the table as the detail. Rules get unit tested in isolation; what they add up to does not.
3. The weights are judgment, not evidence. The 25/20/20/15/20 split is my ranking of what damages an answer most, with no dataset of failed articles behind it. Defensible, not validated.
4. Fixed rules misfire on good writing. The cap and the near-miss tests limit the damage, but the score is a strong hint rather than a verdict until it is calibrated against real production articles.
5. The demand evidence is vendor-sourced. Strong on the existence of the manual test, thin on what it costs to do it. Closing that is item three on the roadmap.
6. The rules only work properly in English. The tool warns when the text does not look like English, and a warning is not a fix.
7. This page fails its own tool, and that is the rubric working. It lands in the bottom band, with one idea per section at zero, because it would be cut into ten pieces and the largest runs about seven times over the limit. A teardown is an essay, read from the top by someone who chose to be here; a knowledge-base article is cut into pieces and read one piece at a time by software that chose nothing. The rubric scores the second thing, so it is right to fail the first, and the essay stays long rather than being chopped into fragments to flatter its own score. The exact composite is not quoted, because a page that reports its own score changes it with every edit, including this one. The failing check and the band survive an edit; a number does not.
8. The rubric can never be tuned from usage. No funnel, no drop-off, no spread of real scores to calibrate the bands against. That is the price of the privacy promise, paid knowingly.

Part 6

What I would do next

RICE scores reach times impact times confidence, divided by effort, and it suits this situation because reach punishes feature work on a tool nobody can find yet. Reach is a relative score out of 10 rather than a user count, since I have no traffic data. Effort is in person-days, and both effort and impact are my estimates.

Part 7

What I would cut

The Blue Ocean ERRC grid asks what to eliminate, reduce, raise and create against the norms of the category. It suits a cut list, because the plan is to compete where competitors are not looking rather than to out-feature them where they are.

Appendix

Method made visible

Deliberately left out

No personas, because there is one well-understood user here and inventing three archetypes of a person I already understand is box-ticking. No North Star metric or HEART, because both need usage data that decision 2 rules out, and a metric I cannot measure only invites false confidence. No OKRs, because this is a portfolio piece rather than an organization.

Naming what I left out, and why, is itself a position.