
Key facts.
- Turpin's work shows chain-of-thought reasoning can be unfaithful, not reflecting the model's actual process, so you cannot debug an agent by trusting its stated reasoning. source
- Embers of Autoregression shows autoregressive models carry inherent biases, so agent failures are model-deep, not surface bugs to patch. source
Why is the old playbook insufficient?
The reasoning an agent shows is not the reasoning it used, per unfaithful chain-of-thought and the biases run model-deep; a more capable model fails late. (arXiv:2305.04388)
Classic reliability engineering assumes deterministic, inspectable systems: a failure is reproducible, the logs say what happened and the same input gives the same output. Agents violate every assumption. Failures are often semantic, a confident wrong answer with a 200 OK, not a crash. Behavior is probabilistic, so a failure may not reproduce. And the agent's own account of its reasoning may be unfaithful, as Turpin shows, so you cannot debug by reading the chain-of-thought and trusting it. The Embers result adds that the underlying failures are model-deep biases, not bugs you fix once. A reliability practice built for deterministic software will instrument uptime and latency and miss the failures that actually hurt an agent.
The new discipline keeps the spirit, measure, monitor, contain, recover and adds methods for these realities. Semantic monitoring that judges whether the answer was right, not just whether the run completed. Distribution-based testing that treats output as probabilistic. Trace capture that records what the agent did rather than relying on its self-report. Verification layers that check the output independently because the reasoning cannot be trusted. And system-level controls, limits, gates, fallbacks, because the model's failures are not patchable. This is recognizably reliability engineering, but it is a new branch of it, shaped by a system whose failures are semantic and probabilistic rather than deterministic and technical.

What does the new discipline add?
| Practice | Deterministic playbook | Agent reliability engineering |
|---|---|---|
| Monitoring | Uptime and latency | Semantic correctness |
| Testing | Reproducible cases | Distribution-based |
| Debugging | Trust the logs/reasoning | Captured traces, not self-report |
| Fixing | Patch the bug | System-level controls |
The new practices all depend on a clear notion of what correct behavior is for each situation, which is what the Pattern Intelligence Layer provides. VibeModel makes the agent's expected behavior explicit at the pattern level, giving the new reliability engineering its reference point, what to monitor against, what to test for, what a trace should show, so the discipline has something concrete to measure rather than the deterministic assumptions it can no longer rely on.
Frequently asked questions
Why can't I reuse my existing reliability practices?
They assume deterministic, inspectable systems. Agents fail semantically and probabilistically and their stated reasoning can be unfaithful, so the old instrumentation misses the failures that matter.
Can I debug from the chain-of-thought?
Not by trusting it. Turpin shows reasoning can be unfaithful, so debugging needs captured traces of what actually happened, not the agent's narrative.
Are these failures patchable?
Often not at the model level, since they stem from inherent biases. You contain them with system-level controls rather than a one-time fix.

