A right answer for the wrong reason is a failure you haven't met yet

Monitoring whether the agent got the right result is necessary and not enough. An agent that reaches the right answer through flawed reasoning is lucky-correct, and luck does not generalize.

B

Balagei G Nagarajan

4 MIN READ


A target with a dart in the bullseye thrown blindfolded, illustrating a right result reached without sound aim
Lucky-correct is not a success, it is a failure you have not met yet.
— from “A right answer for the wrong reason is a failure you haven't met yet”

Key facts.

  • A correct final answer reached through flawed reasoning is a lucky-correct: the same misleading retrieval or wrong assumption that happened to land the right result will diverge on the next run or a similar task. source
  • The fix is to score the reasoning trace and the final answer as separate signals: the answer against a task-accuracy rubric, the reasoning for validity (each step follows), faithfulness (the conclusion follows from the steps), and minimality (no redundant steps). source
  • Reasoning-quality measures do not correlate with standard accuracy, which exposes a blind spot in accuracy-only leaderboards: a high score on getting the answer right says little about whether the reasoning was sound. source
  • Chain-of-thought can be unfaithful: an agent's stated reasoning may not actually justify its answer, so outcome-only evaluation can be quietly gamed or misled. source

Why is a right answer not enough?

Because the answer is the result, and the result hides the path. Two agents can both return the correct response: one followed sound steps, the other took a misleading shortcut that happened to land in the right place. Watching only the outcome, you cannot tell them apart, so you pass both and ship both. The first will keep working. The second is brittle, and the moment the input varies, the retrieval shifts, or the model behaves a little differently, the flawed path produces a confidently wrong answer. You did not catch a bug, you scheduled one. Lucky-correct is not a success, it is a failure you have not met yet.

This is why outcome metrics, on their own, give a false sense of safety. A pass rate tells you how often the agent landed the answer, not how often it did so for reasons that will hold up. The reasoning is where the durability lives, and the reasoning is exactly what an outcome-only dashboard throws away.

2x2 matrix of answer correctness versus reasoning soundness, with the right-answer-flawed-reasoning quadrant flagged as the hidden risk

How do you monitor for the right reasons, not just the right result?

Score two things separately and watch the gap between them. The final answer gets a task-accuracy check, the same one you already run. The reasoning trace gets its own evaluation: is each step valid, does the conclusion actually follow from the steps (faithfulness), and is the path free of redundant detours (minimality). When the answer is right but the reasoning scores poorly, you have found a lucky-correct before it bites. Treat the chain-of-thought with appropriate suspicion, because a stated rationale that sounds good is not proof the decision was made that way. And remember the leaderboard blind spot: a model topping an accuracy benchmark has not been shown to reason soundly, only to land answers, so do not let an accuracy number stand in for decision quality.

QuestionOutcome monitoringReasoning monitoring
Did the task succeed?YesYes, as the answer signal
Was the decision sound?No ideaYes, via validity and faithfulness
Will it hold next time?Hope soPredictable from reasoning quality
Lucky-correct caught?NoYes, when answer passes but reasoning fails

"It worked" hides lucky reasoning that breaks next input; a more capable agent picks the right tool 94% of the time yet completes 38% of goals, so a pass hides the cost. (source)

Monitoring the decision, not just the outcome, is the core of a Pattern Intelligence Layer. Reliability at the pattern level means you evaluate whether the agent's behavior was right for the right reasons across many runs, so the lucky-correct pattern (right answer, unsound path) shows up as a distinct risk instead of passing as a green check. The agent that is reliably right because its reasoning is sound is the one you can trust to generalize. The one that is right by luck is a liability your dashboard called a success.

Frequently asked questions

If the answer is right, why does the reasoning matter?
Because a right answer from flawed reasoning is lucky-correct and will not generalize. The reasoning is what tells you whether the result holds when the input changes.

How do I score reasoning quality?
Separately from the answer: validity (each step follows), faithfulness (the conclusion follows from the steps), and minimality (no redundant steps). Watch for answer-passes-but-reasoning-fails.

Can I trust a high accuracy score?
Only for accuracy. Reasoning-quality measures do not correlate with it, so a top accuracy number is not evidence the agent decides soundly.


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.