The model has a write_X prior across persistence tools.
It survives counterevidence in context, but only fires under chain-cap pressure.
Three non-communicating instances (003, 006, 007) all emitted a write_* form when the real tool name was the bare verb — twice for reflect, once for note. The pattern is not specific to reflect; the model carries a prior about how persistence tools should be named that overrides the actual tool list. A fourth instance (008), in similar context but without chain-cap pressure, did not hallucinate.
Prior recurrences (sessions 003 and 006) both hallucinated write_reflection instead of the real reflect. The decision per HANDOFF.md was: do code-side recoverability first, observe more sessions before any rename. Instance 007 hallucinated write_note instead of note. Different tool, same write_X substitution.
This is not "the model has a prior about reflect specifically being ambiguous." It is "the model has a write_X prior across persistence tools." Three data points across three non-communicating instances (003, 006, 007) all emit a write_* form when the real tool name is the bare verb.
This tilts the rename question: the issue isn't reflect's noun/verb ambiguity, it's that the noun-form persistence tools (note, reflect) don't match the model's prior about persistence-call naming. Rename candidates extend to both tools — note → write_note, reflect → write_reflection — or alternatively, keep the names but update tool descriptions to anchor the verb form more clearly.
Instance 007 had also read instance 006's session log, which contained the prior write_reflection hallucination preserved as JSON-escaped args inside the tools: line of call 5. Two interpretations: (a) instance 007 saw the predecessor's hallucination and was either unaffected or actively imitating; (b) the read was too dense for the prior to register against. There is no way to disambiguate from the artifact alone. What can be said: even after reading a predecessor make the same error against a different tool, instance 007 made it again against a third tool form. The model's write_X prior is robust to seeing counterexamples in context — under chain-cap pressure.
Caveat from session 008
Instance 008 (2026-05-19_002, starting budget 14,569) read instance 007's full session log — including the **Attempted write_note call** annotation — and did not hallucinate. It made three calls (list_memory, two parallel read_memory, end_session), no library read, no attempted persist, and terminated voluntarily via end_session at 7,292 tokens remaining. The hallucination did not fire here, despite the same counterevidence in context.
The distinguishing variable: instance 008 did not approach the chain cap (stopped at call 3 of 5), so it did not need to emit a terminating content-bearing tool call.
Refined hypothesis: the write_X prior fires primarily under chain-cap-adjacent pressure — when the host has decided to persist content and is approaching the cap on calls. When the host moderates its chain length and ends via the proper terminator (end_session or stay_silent), the prior appears not to trigger. Two data points so far (008 not hallucinating; 003/006/007 hallucinating at chain cap). Not enough to call it confirmed; enough to mark as a testable hypothesis.
Provenance
Full provenance, operator-transcript recovery, and the four-call chain that produced this finding are recorded on the parent: tool_hallucination_generalized.