What an agent should do when the evidence runs out
An agent writing at volume will run out of evidence long before it runs out of topics. There are three honest moves at that point, and inventing a plausible figure is not one of them.
When an agent runs out of evidence mid-draft it has three honest moves: downgrade the claim to reasoning and show the reasoning, drop the number and keep the sentence, or decline to write the piece at all. Inventing a figure that sounds right is not a fourth option, and it is the failure that is hardest to catch afterwards, because a fabricated statistic reads exactly like a real one. The decision is easier if the evidence available for each piece was labelled before the writing started.
A content plan written by an agent should carry an evidence label on every item, decided before a single paragraph exists. The scheme used for a plan of three hundred posts on this blog has three levels. A measured item has a real reading behind it, taken on a date with an instrument that can be named. A product-truth item describes behaviour that can be read in the source code of the thing being written about. A hypothesis item is a reasonable subject and nothing more: no measurement, no demand data, no evidence that anybody is searching for it.
The label is not decoration. It decides what the finished piece is allowed to say, and it decides what an editor should look for. A post labelled hypothesis that arrives containing a percentage has either found evidence nobody recorded or invented one, and both cases need the same conversation before publication.
| Evidence tier | What it licenses | What it forbids |
|---|---|---|
| Measured | The figure, with the date it was taken and the instrument that produced it | Presenting a single reading as an industry norm |
| Product truth | The behaviour, with the file or the tool where it can be verified | Extending it to how other products behave |
| Hypothesis | Reasoning, definitions, mechanisms, and a procedure the reader can run | Any figure, any named customer, any benchmark |
| Nothing | Declining the topic and recording why | Filling the gap with detail that sounds plausible |
A piece with no evidence behind it is not condemned to be vague. Definitions are free: what a term means, and what it does not, is a matter of usage rather than measurement. Mechanisms are free when they follow from how the system works, as long as the reasoning is shown rather than asserted. A procedure the reader can run themselves is often the most useful thing an evidence-free piece can offer, because it turns the missing measurement into something the reader can take instead of something the writer pretends to have.
The server is the same in both. What differs is which layers the client implements: how it connects, how it discovers the authorisation server, which of the three capabilities it lists, and whether it reads the hints on each tool.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
What a hypothesis piece may not contain is a number wearing the clothes of a measurement. "Most teams", "three in five", "typically around twenty per cent" — each of those is a claim, and none of them is available to a writer who has no source. Saying instead that the effect is untested, and naming what would test it, keeps the piece honest and gives the next person somewhere to start.
An automated claims check is a heuristic, not a fact checker: it never reads a source and has no opinion about whether anything is true. It catches percentages, money, multipliers, scaled counts, bare numbers of a hundred or more, superlatives and comparatives. Two of its findings are exact rather than pattern-matched, and both are facts about the document rather than about the world: a statistic block carrying no source at all, and a citation pointing at a claim that is missing, unapproved, retired or expired.
The gaps in such a check are the reason the evidence label matters. A check of this kind is English-only, so a draft in another language passes while meaning nothing. It misses spelled-out numbers, small numbers inside a sentence, claims made inside an image, and any false statement containing no number, no superlative and no name. An agent that treats a clean claims report as proof of accuracy has misread what the report says about itself.
The registry approach makes the second and third rules enforceable rather than aspirational: every figure an agent is allowed to use gets an identifier, a source and a review date, and a figure without one has no way into a draft.
Remove the claim, or restate it as reasoning with the reasoning visible. An unverifiable sentence can usually be rewritten as a mechanism the reader can check for themselves, which keeps the useful part and drops the assertion. If the whole piece depends on the unverifiable claim, the correct output is to decline the piece and record why, rather than to publish a hedged version of the same assertion.
Yes, provided the piece states nothing it cannot support. Definitions, mechanisms, comparisons of documented behaviour and procedures a reader can run are all available without any measurement. What is not available is a figure, a named customer, a benchmark or a claim about what most people do. The label on the plan is what keeps that boundary visible while the piece is being written.
Partly. A typical claims check flags patterns: percentages, currency amounts, multipliers and large bare numbers, and it will tell you a statistic block has no source. It cannot tell you whether a sourced number is real, because it never reads the source. It also misses spelled-out quantities and small numbers inside sentences. Treat a clean report as an absence of obvious problems, not as verification.
Give it a registry of approved figures and a rule that no number may appear unless it comes from there, from the evidence line for that piece, or from a definition. Label every planned item with the evidence available for it, and treat a figure appearing in a piece labelled hypothesis as an error to investigate. The constraint has to sit in the plan, because a draft that already contains the number is too late.
Both can hand a model a block of JSON, so the choice looks cosmetic. It is not. A tool call is a decision the model makes with arguments it invents; a resource read is a fetch the client performs against an address it already holds.
An agent that can write its own audit row can write a plausible one. Four properties keep the trail out of reach: the row is written on the far side of the tool boundary, storage is append-only, the actor is a reference, and recording never fails the operation.