What a silent failure is
A silent failure is a run that completes without any technical error but produces the wrong outcome. It is semantic: the problem is in what the output means, not in whether the system ran. Traditional monitoring was built for software that fails loudly. An LLM application fails quietly, confidently and often.
- No exception is thrown, so nothing is logged at error level.
- Latency and token counts look normal, so dashboards stay green.
- The response is well-formed, so schema validation passes.
- Users often don't report it. They stop trusting the product, or leave.
Examples
A refund the policy didn't allow
- What happened
- A support agent's instructions say annual plans are refundable only within 14 days. A customer cancels on day 40 and asks for a refund.
- What logs show
- 200 OK. One model call, one call to issue_refund, which succeeds. No errors.
- What went wrong
- The agent approved a refund its own instructions forbid. Only a check against the policy in the system prompt shows it.
An identifier the agent made up
- What happened
- An agent looks up an order, the lookup returns no rows, and the agent answers with a tracking number anyway.
- What logs show
- The lookup tool returned an empty list, which is a valid response. The final answer is well-formed.
- What went wrong
- The tracking number was invented. Only reading the tool result next to the answer shows it.
A workflow that finished without its outcome
- What happened
- An agent is meant to triage an email, create a ticket and assign it. It drafts a reply, decides the ticket was already handled, and ends.
- What logs show
- Every step returned successfully. The run is marked complete.
- What went wrong
- No ticket exists. The work is orphaned, and nobody finds out until the customer writes again.
A forgotten turn
- What happened
- In turn two a user says they're on the EU plan. In turn five the agent quotes US terms.
- What logs show
- Turn five, looked at alone, is a correct answer to its question.
- What went wrong
- The agent lost earlier context. Only a trace that links the turns of the conversation shows it.
Why logs and error alerts don't see them
Logs record events the code chose to log. Error alerts fire on counts of those events. Neither knows what the agent was asked to do, so neither can tell a correct answer from a confident wrong one. Sampling a few transcripts by hand helps, but a team cannot read every run, and silent failures are often rare per run and common across thousands.
Scoring outputs with a fixed rubric helps more, but only for the failures someone thought to write a rubric for. The refund example above is caught by a policy-adherence scorer only if someone wrote one for that policy.
What observability must capture to catch them
- The whole run as one trace: every model call, tool call with its arguments and result, and sub-agent step, nested in order.
- The conversation across turns, linked by a thread or session ID, so lost context is visible.
- What the agent was supposed to do: its instructions, policies and the task it was given, so the run can be checked against them.
- Analysis of every trace, or a large enough sample, that compares what happened with what was supposed to happen.
- Grouping, so one recurring failure becomes one issue with its evidence instead of hundreds of separate flags.
- A way back after the fix: an eval built from the real failure that tells you if it returns.
Every tool in our comparison captures full traces. They differ on the last three points. Lemma audits each trace against the agent's own instructions and groups recurring failures into issues, which is the most direct answer to silent failures. Braintrust and HoneyHive catch what your scorers and evaluators measure, and Laminar's Signals surface and cluster failure modes it finds in runs.