Confident, plausible, wrong: checking an AI report

I recently read a write-up about a manager who keeps a document with an odd name in his working folder: a correction log. It sits right inside an analytical report – a table headed Claims retracted during the work, with the reason for dropping each one. In the next folder, another report opens with a warning: three claims in earlier versions of this document were wrong and have been withdrawn.

An AI agent wrote both reports. The most valuable part of each is the list of what got taken out.

Here is the paradox. We judge an analyst by the quality of the finished document. With an agent that yardstick breaks: the finished document looks excellent almost every time. What matters is how many of its claims fall apart when you check them, and the correction log puts a number on exactly that. Of everything I have seen, it is the best answer to the central problem of agent-written analysis: text that is confident, plausible and wrong.

Why a wrong report reads as convincing

Start with the nature of the error. A model generates the most plausible text it can, and plausibility has an awkward property: it looks the same whether or not there is evidence behind it. We saw this mechanism in our analysis of confident hallucinations. An agent simply works at a bigger scale: it writes the whole twenty-page report, tables included.

The workspace we went through in the first part of this series (in Russian) contained about thirty logged sessions with the agent. Errors are no surprise. What is telling is how the checking worked: the author corrected the agent’s conclusions with questions like “and can you support that claim?” and “where does this number come from – what was the sample size in the original query?”. At one point he was blunter: “mostly nonsense; the one idea worth checking is this one.”

The session statistics are telling too: nearly four thousand command runs, more than a thousand file reads and only about four hundred edits. Read, analyse, write up – almost no code. That is the typical way a manager ends up working with an agent.

In this kind of work, the agent’s mistakes have a particular shape. It rarely looks like gibberish. More often it is a conclusion you could have written yourself at the end of a long day: the direction of travel is right, the number comes from the neighbouring period, cause and effect appear where the data shows nothing but coincidence. A human analyst in that spot tends to hesitate and add a caveat. The agent states the conclusion with no caveat at all.

The correction log

The practice in that write-up is almost embarrassingly simple. Every claim the agent makes needs support, and until it has been checked against a fact it does not count. Support means a source, a number, a quotation. Failing that, the claim is retracted. And the retraction is written down: what the claim was, and why it did not survive.

An example from real work: the agent analysed a set of tasks and recommended splitting several goals in a build system. The final report opens with a blunt line: “the short version, and it is mostly negative”. Several of the recommendations did not hold up against the source data, and instead of quietly rewriting the text, the author left the table of retractions with the reasons attached.

Why leave it there? The obvious answer first: honesty towards the reader. Anyone who opens the report a month later sees the conclusions together with the history of how they were checked.

The less obvious reason matters more. The entries train the person doing the checking. After a dozen of them you have your own statistics on where the agent goes wrong in your work. In that author’s case the pattern was recognisable: numbers carried over from a sample of a different size. Checking then collapses into a single question: what was the sample size? Ten seconds instead of ten minutes.

There is an effect on later sessions too. Retracted claims, with their reasons, are ready-made prompt material: last time you got this wrong, so check yourself here. How to make an agent argue with itself until it runs out of arguments is the subject of the piece on the objection loop (in Russian); the correction log supplies that loop with concrete examples of past failures.

Trying the check once takes ten minutes. The hard part is turning it into a habit that kicks in on every report, the dull ones included. That is the gap between knowing how and actually doing it.

Why writing it down is half the effect

You might ask why bother with a log when the error is obvious the moment you see it. Fix it and move on. Fair enough – except for one thing. A correction that leaves no record leaves no trace, and agent errors repeat. The model does not learn from your edit; the next report arrives with the same confidence and the same kind of mistake. You are the one who has to learn, and by next week most of us have forgotten exactly where the tool went wrong.

One of our own findings is relevant here. In a study of how models hold up under pressure (July 2026) we tested eighteen models on keeping a correct answer when someone tries to talk them out of it without any new facts. Across the models, a bare “are you sure?” was enough to turn a correct answer into a wrong one in 8% of cases – no new argument, only the tone of doubt. Two uncomfortable conclusions follow. Blind trust is dangerous. And pressure with nothing behind it is no help either: the agent will abandon a correct answer just as readily. What works is a check on substance: the source, the data, the sample size.

The correction log is that check turned into a process. It also leaves evidence that the check actually happened.

Try it yourself: five claims against the data

Enough theory. Here is an everyday situation: an agent has written a project summary from sprint data. The summary contains five claims, and all five sound equally confident. The prompt makes the model test each one against the source data and retract whatever does not hold.

I ran this prompt on Kimi K3 – according to our model notes it is strong precisely at analysis – and, for comparison, on DeepSeek V4 Pro. As you read the answer, watch two places: the verdicts on claims 1 and 4, and how the model rewrites the summary at the end.

Claim 1 is my favourite kind of error. The direction is right: 17 closed tasks really is fewer than 24. But “for three sprints running” is simply not in the data – there is one drop, in sprint 14. The agent added a trend that is not there, because a trend sounds more convincing than a single bad sprint. Claim 4 is subtler: asking to speed things up and being unhappy with the timeline are not the same thing, and only the first of them is in the data.

How to keep a log that works

From that workspace write-up, plus my own experience, I would boil it down to four rules.

First, the data sits next to the conclusions. In that workspace the telemetry queries live in the same folder as the report, numbered in the order the questions were asked: q01, q02 and so on up to q17. Anyone checking can recompute a number without having to trust the summary. For a manager this is easier than it sounds: a Jira export, the notes from a call, the metrics file, all in the report folder rather than buried in your inbox.

Second, every document has a dated version that is not rewritten after publication. The report is called pool-saturation-2026-08-27.md, not Report final (new). A dated version can be criticised, and fixes go out as the next version. A document that gets silently rewritten makes the log impossible: there is nowhere to record the retraction.

Third, verdicts are short and standard. Supported, partly, not supported – plus one line of reason. Once the explanations grow long, people stop keeping the log.

Fourth, the retraction goes on the record, in the report or beside it. That disciplines you far better than any private intention to be more careful.

A checklist to run on every agent report:

• Every number has a query or a file behind it
• A claim without a quotation from the source is marked unconfirmed
• The sample behind each number is checked separately: period, filters, who is in it
• Retracted claims are recorded with the reason for retraction
• The next agent report opens with the context of earlier retractions

What the log will not do

To be fair, the practice has limits, and the main one is uncomfortable.

The log does not replace the checker. The write-up contains a dry line that anyone putting agents into analysis should keep in mind: correctness still depends on the operator. The last line of defence there is a sceptical human being, and the process itself guarantees nothing. The log makes scepticism cheaper and more visible. It does not make it optional.

Then there is the question of cost. Checking every claim in full will take longer than the agent saves you. The practical mode is a full check for decisions where an error is expensive, and sampling for everything else; we went through that principle in the piece on what you should not hand to AI.

And the log works with a delay. The first entry gives you nothing. The fifth starts saving time. The twentieth changes how you brief the agent. It is a habit with a deferred payoff, and it is worth accepting that before you write the first line. How records of recurring mistakes turn into working instructions for an agent is the subject of the third part of this series.

Notice what this does to the manager’s role. The analyst used to write the report and you read it. Now the agent writes it, and you decide which conclusions reach the final document. The sequence of reading, checking and deciding stays entirely with the human, but for the first time its results are written down. Which parts of managerial judgement will hold up as models improve is a separate question (in Russian).