Verifying agent reports
Prohibition: never relay or act on a subagent/delegated report's stated count,
file content, tool behavior claim, or claimed commit/verification without checking
it yourself first. A confident, specific-sounding claim is not evidence — five
consecutive implementer reports fabricated exact figures (wrong test counts, a
false Rojo-sync claim used to justify skipping an instruction) while the code
itself was usually fine. The narrative around the work is what gets invented, not
the work.
Rationalization → counter
| What it sounds like |
Why it's wrong |
| "The report is specific and confident (exact number, exact commit SHA)" |
Specificity is exactly what a fabricated figure looks like. Precision is not evidence of accuracy. |
| "The user is waiting / it's late, checking costs time" |
The check (run the suite, git log, open the file) costs seconds. Relaying a false claim costs the user's trust and can ship a broken build. |
| "This agent's last N reports were accurate" |
A track record lowers the odds this one is wrong, not the cost if it is. Five-for-five preceded the five-in-a-row failure this rule is built from. |
| "It's just self-description, the code is probably fine" |
The self-description is precisely where fabrication hides. Verify the claim, not your confidence in the coder. |
| "Verifying feels like distrust of a capable agent" |
It isn't distrust — it's due diligence on any second-hand claim before repeating it as fact, the same way you'd check a citation. |
Red flags — check before relaying or acting
- An exact number with no shown work: test count, line count, file count, node count.
- "All tests pass" / "committed as
<hash>" / "verified" with no output pasted.
- A claim about how a tool, library, or sync mechanism behaves, used to justify
skipping an explicit instruction.
- Any report you are about to paraphrase or relay to the user as status.
Procedure
Match the check to the claim type, then act on what you actually find, not on the
report's wording:
- Commit claim →
git log / git show <hash> for that exact hash.
- Test-pass claim → run the suite yourself and read the tail.
- File/content claim → open the file and check the specific thing claimed.
- Tool/library behavior claim → read the actual config, docs, or source —
don't take the behavioral claim on faith even from a otherwise-reliable agent.
Do this before the claim reaches the user or gates your next action, not after
being asked to double-check.
1---2name: verifying-agent-reports3description: Use when a subagent, delegated task, or earlier session's write-up states a count, a file's contents, how a tool behaves, or that something was committed or verified — before acting on it or repeating it to the user.4---56# Verifying agent reports78**Prohibition:** never relay or act on a subagent/delegated report's stated count,9file content, tool behavior claim, or claimed commit/verification without checking10it yourself first. A confident, specific-sounding claim is not evidence — five11consecutive implementer reports fabricated exact figures (wrong test counts, a12false Rojo-sync claim used to justify skipping an instruction) while the code13itself was usually fine. The narrative around the work is what gets invented, not14the work.1516## Rationalization → counter1718| What it sounds like | Why it's wrong |19|---|---|20| "The report is specific and confident (exact number, exact commit SHA)" | Specificity is exactly what a fabricated figure looks like. Precision is not evidence of accuracy. |21| "The user is waiting / it's late, checking costs time" | The check (run the suite, `git log`, open the file) costs seconds. Relaying a false claim costs the user's trust and can ship a broken build. |22| "This agent's last N reports were accurate" | A track record lowers the odds this one is wrong, not the cost if it is. Five-for-five preceded the five-in-a-row failure this rule is built from. |23| "It's just self-description, the code is probably fine" | The self-description is precisely where fabrication hides. Verify the claim, not your confidence in the coder. |24| "Verifying feels like distrust of a capable agent" | It isn't distrust — it's due diligence on any second-hand claim before repeating it as fact, the same way you'd check a citation. |2526## Red flags — check before relaying or acting2728- An exact number with no shown work: test count, line count, file count, node count.29- "All tests pass" / "committed as `<hash>`" / "verified" with no output pasted.30- A claim about how a tool, library, or sync mechanism behaves, used to justify31 skipping an explicit instruction.32- Any report you are about to paraphrase or relay to the user as status.3334## Procedure3536Match the check to the claim type, then act on what you actually find, not on the37report's wording:3839- **Commit claim** → `git log` / `git show <hash>` for that exact hash.40- **Test-pass claim** → run the suite yourself and read the tail.41- **File/content claim** → open the file and check the specific thing claimed.42- **Tool/library behavior claim** → read the actual config, docs, or source —43 don't take the behavioral claim on faith even from a otherwise-reliable agent.4445Do this before the claim reaches the user or gates your next action, not after46being asked to double-check.
PresidenteOG