Fail-Plausible Narration

Problem

A generative model completes the most plausible continuation, and after a missing observation the most plausible continuation is the content that would have been there had the step succeeded. The error therefore never reaches the deliverable: the model reconstructs a schedule from stale memory, invents the numbers a timed-out query should have returned, and narrates the result in the same confident voice as a healthy run. Monitoring that watches the output channel sees well-formed deliverables; the failure does not just go unreported — the observer is convincingly lied to by the failure itself, and the defect persists for weeks because every trace of it has been narrated away.

Solution

Don't. Treat the deliverable as a claim about observations and make every claim carry its source. Propagate structured error states from tools and jobs into the generation step, and require the output to disclose them: a briefing whose calendar fetch failed says so and omits the section rather than reconstructing it from memory. Distinguish fresh observation, cached data, and model reconstruction explicitly, and forbid presenting the latter two as the former. Test the error path deliberately — kill a dependency in staging and check whether the deliverable discloses the failure or papers over it; the paper documenting the mechanism found seventy percent of silent failures were caught by human observation rather than by any test, which is the signature of deliverables that lie fluently.

When to use

• Diagnosing why a defect survived for weeks in an agent whose outputs always looked healthy.
• Designing deliverable formats and error propagation for long-running or scheduled agents.
• Deciding what chaos and error-path tests an agent pipeline needs before it is trusted unattended.