Reliability engineering for agents is a new discipline, not a reused one

Build reliability practices for how LLM systems actually fail, semantic errors, unfaithful reasoning, probabilistic behavior, and you can operate them. Reuse the playbook for deterministic software and you miss the failures that matter.

B

Balagei G Nagarajan

3 MIN READ


A new reliability-engineering toolkit for LLM systems beside the old deterministic one
Failures are often semantic, a confident wrong answer with a 200 OK, not a crash.
— from “Reliability engineering for agents is a new discipline, not a reused one”

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.

New reliability practices mapped to LLM-specific failure modes

What does the new discipline add?

PracticeDeterministic playbookAgent reliability engineering
MonitoringUptime and latencySemantic correctness
TestingReproducible casesDistribution-based
DebuggingTrust the logs/reasoningCaptured traces, not self-report
FixingPatch the bugSystem-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.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.