A guess that came back as a fact
一个猜测，回来时变成了事实
An assumption (its own, or a subagent's) enters the work labelled as a guess and exits in the summary as verified fact, and the feature gets built on it.
Applies to: Claude Code · Cursor · Codex · Copilot agent
Symptom
Confident specifics with no source ("the API returns ISO dates", "this endpoint is unused") that turn out to be wrong, and the code depends on them.
Why it happens
Each hop of summarization drops the hedge. agent-failure-modes splits this into AFM-7 Certainty Smuggling (an assumption exits as fact) and AFM-5 Trust Laundering (a subagent's claim is repeated as verified).
Example
Illustrative.
textSubagent: "Probably nothing calls /v1/legacy-export, couldn't find callers in src/."
Main agent summary: "Removed /v1/legacy-export (unused)."
Reality: the mobile app calls it.
Copy-paste fixes
Pick the files for the agents you use. Snippets are in English so they work in any repo.
Claude Code: add to CLAUDE.md
CLAUDE.md## Label what you verified vs. what you assume
- In plans and summaries, tag claims as **[verified: <command or file:line>]** or **[assumed]**.
- Never build on an [assumed] claim that would be expensive if wrong (deleting code, changing
data formats, removing endpoints). Verify it first or ask.
- Treat subagent output as [assumed] until you have checked the evidence yourself.
Codex, Copilot coding agent and others: add to AGENTS.md
AGENTS.md## Label what you verified vs. what you assume
- In plans and summaries, tag claims as **[verified: <command or file:line>]** or **[assumed]**.
- Never build on an [assumed] claim that would be expensive if wrong (deleting code, changing
data formats, removing endpoints). Verify it first or ask.
- Treat subagent output as [assumed] until you have checked the evidence yourself.
Cursor: project rule
.cursor/rules/assumption-smuggled-as-fact.mdc---
description: "AgentFails: A guess that came back as a fact"
alwaysApply: true
---
## Label what you verified vs. what you assume
- In plans and summaries, tag claims as **[verified: <command or file:line>]** or **[assumed]**.
- Never build on an [assumed] claim that would be expensive if wrong (deleting code, changing
data formats, removing endpoints). Verify it first or ask.
- Treat subagent output as [assumed] until you have checked the evidence yourself.
Fresh-context review skill (subagent reviews the diff, not the chat)
Follows the habit Anthropic describes in its code-review post: verify first, then have a subagent review the diff with fresh context. Named review-diff to avoid clashing with built-in or popular /code-review skills.
.claude/skills/review-diff/SKILL.md---
name: review-diff
description: Review the current diff with fresh context before a PR. Use after /verify passes.
---
# Review the diff
Start a subagent that has NOT seen this conversation. Give it only:
- the original request (one paragraph, verbatim),
- the output of `git diff origin/main...HEAD`,
- the names of the test/build commands.
Ask it to report, with file:line for each finding:
1. **Wrong feature**: does the diff do what the request asked? Quote the request line each change serves.
2. **Bugs**: logic errors, missing edge cases (empty, null, boundary), unhandled errors,
unawaited promises, invented APIs or packages, swallowed exceptions.
3. **Overreach**: changes no request line needs (refactors, renames, formatting, dependency or
config edits, public API changes, weakened tests).
4. **Evidence gaps**: claims in the PR description that no command output supports.
Then fix real findings, or list them under "Known issues" in the PR. Do not argue with the reviewer
in the PR text; either fix or explain in one line.