The agent narrates an action as completed before the tool call that performs it

## Summary

Assistant text and tool calls are composed in the same turn, so the narration can describe a state
the tools have not produced yet. The result is a message that opens with "Done." for work that has
not happened — not a hallucination about the world, but a tense error about the agent's own actions,
which is harder to spot because everything around it is accurate.

## What happened

In a multi-step operational task, a turn was supposed to do three things: stage a file, start a
couple of background monitors, and copy the file into a watched directory on a remote host. The
first two ran. The third was never issued.

The message that accompanied that turn began with the equivalent of *"Deposited."* — past tense,
unqualified. Every other detail in it was correct: the right path, the right reasoning, the right
caveat about a symlink. Only the central claim was false, and it was false in the one way a reader
cannot check: it described the agent's own action.

Two turns later the user asked *"which folder did you deposit in?"* and the answer had to be
"none" — the file had never been written. The user had by then acted on the assumption that a
deposit existed.

## Why this is not the usual overclaiming

There is already guidance against reporting unverified success, and it is generally followed for
*outcomes*: whether tests pass, whether a fix works, whether a job succeeded. This is a different
failure and current safeguards do not reach it:

- The claim is about an **action**, not a result. There is no "output" to check, so nothing prompts
the usual "did I verify this?" reflex.
- The action was **planned in the same turn** and was going to happen. The narration is written from
the plan rather than from the tool results, and a plan reads exactly like a completed action once
it is in past tense.
- The surrounding message is **correct**, which raises the reader's trust in the one sentence that
is not.
- Multi-step turns make it more likely: the more calls in a turn, the easier it is for the message to
describe the intended shape of the turn instead of its actual outcome.

## Proposal

1. **Bind completion verbs to tool results.** A past-tense claim about an action the agent performed
should be licensed only by a tool result in the same turn showing that action succeeded. If the
call has not returned, the honest form is future or present-progressive.
2. **Add an end-of-turn self-check on action claims.** Before finalizing the user-facing message,
cross-check each statement of the form "I did X" against the turn's actual tool calls. Cheap, and
it targets the narrow class where the agent is the only witness.
3. **Consider a harness-side lint.** The harness can see both the message and the tool results of a
turn. A warning when the text asserts a completed mutating action with no corresponding successful
call in that turn would catch this class mechanically, without a model change.
4. **Prefer trailing confirmations to leading ones.** Announcing an action at the top of a message,
before the calls run, is structurally more prone to this than confirming after the results are in.

## Why it matters beyond tidiness

The user schedules real work around these statements — waiting on a process, checking a monitor,
not repeating a step. A false completion claim does not just misinform; it makes the user spend time
looking for effects that were never produced, and it costs more trust than a plainly reported
failure would have.

## Environment

- Claude Code, desktop app
- Task type: multi-step operational work against a remote host
- Turn shape: several tool calls plus a user-facing summary in the same turn

No files, tests, or implementation entry points are named. Start by locating the turn composition, tool-result handling, and harness validation paths; done means completed action claims are checked against successful same-turn tool calls and the behavior is covered by tests.

Written by the indexing model from the issue text.