💬 NLP

Outcome Monitors: Recovery Affordances for Silent Tool Failures

This paper introduces Outcome Monitors, a mechanism that detects silent tool failures by verifying outcome contracts and issuing receipts with recovery tools, significantly improving task completion rates in agent evaluations while highlighting that current detection relies heavily on mined vocabulary.

Original authors: Sugam Panthi, Rabab Abdelfattah

Published 2026-08-21

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Sugam Panthi, Rabab Abdelfattah

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a digital assistant that can talk to other computer programs to get things done. It might ask a weather service for a forecast, check a store's inventory for a specific item, or book a flight. These assistants are powerful because they can reach far beyond their own memory, but they rely on a fragile trust: they assume the answers they receive are true. Usually, if a program fails to answer, the assistant knows something is wrong. But sometimes, the answer arrives looking perfectly normal, even though it is a lie. A computer might return a cached error page that looks like a valid response, or a price that is negative because of a glitch. The assistant, seeing a perfectly formatted number, accepts it as fact and builds its next steps on a foundation of sand. This is a silent failure, a mistake that happens without a sound, leading the assistant to confidently produce nonsense.

Researchers at the University of Southern Mississippi have developed a way to catch these silent lies without stopping the assistant in its tracks. They call their invention "Outcome Monitors." Instead of trying to force the assistant to be perfect or blocking its actions, the monitor acts like a quiet observer that checks the answers as they arrive. It compares the result against a set of expected rules, or "contracts," that were learned from watching the system work correctly in the past. If the answer breaks a rule—like a negative price for an item that should cost money—the monitor does not take control. It does not delete the bad answer or force the assistant to try again. Instead, it slips a note into the conversation. This note, called a receipt, points out the specific error and suggests a list of other tools the assistant could use to fix the problem. The assistant then decides what to do next, armed with the knowledge that the previous answer was broken and a map of how to recover.

The researchers tested this system on a series of challenging tasks where they intentionally injected these silent errors. They watched how different computer models performed when they were left to handle the mistakes on their own versus when they were given these helpful receipts. The results were clear: when the models received the receipts, they successfully finished far more tasks. In one set of difficult tests, the completion rate jumped from roughly eleven percent to twenty-eight percent. This improvement held true across several different types of computer models from various companies. The key to this success was not just knowing an error had occurred, but knowing exactly which other tools were available to solve it. When the researchers removed the list of recovery tools from the receipt, the improvement vanished, proving that the specific suggestion of what to do next was the most valuable part of the message.

However, the system is not a magic cure for every problem. The researchers found that the benefit was most pronounced when the error was severe enough to stop the task completely. If the error was minor or if the task could be finished despite the mistake, the receipt did not change the outcome much. In some cases, the system even flagged errors that were not actually there, which sometimes confused the assistant and led to worse results, though these instances were rare. The study also showed that the system works best when the errors it catches are similar to the ones it learned to recognize. When the researchers introduced a completely new type of error that the system had never seen before, its ability to detect the problem dropped significantly. This suggests that while the monitor is a powerful tool for spotting known types of glitches, it cannot yet recognize every possible way a computer might lie.

Ultimately, this work reframes how we think about fixing broken digital assistants. Rather than building a rigid wall to prevent mistakes, the researchers propose a system that highlights the problem and offers a path forward, leaving the final decision to the assistant itself. The study demonstrates that giving an agent a clear signal about what went wrong and a concrete list of alternatives can dramatically improve its ability to recover from silent failures. While the technology is not yet perfect and cannot catch every possible error, it offers a practical and effective way to make these intelligent systems more robust and reliable in the real world.

Technical Summary: Outcome Monitors for Silent Tool Failures

Problem Statement

Language agents that integrate external tool calls face a critical vulnerability: silent failures. While explicit errors (e.g., timeouts) are easily detected, agents often receive results that arrive in the expected format but contain semantically incorrect, stale, or physically impossible data (e.g., a cached error page or a negative price). In such cases, the agent consumes the faulty data as fact, leading to "confident fabrication" and task failure.

Current agent loops rely on the language model (LLM) to infer inconsistencies from raw observations, a process that often fails. Conversely, strict runtime guards that enforce repairs obscure whether improved behavior stems from better reasoning or the guard's intervention. There is a need for a mechanism that detects violations without restricting the agent's action space or performing the recovery itself.

Methodology

The authors introduce Outcome Monitors, a deterministic system that separates detection from recovery.

Core Components

Outcome Contracts: These are invariants defining expected relationships between tool calls and their results. They are derived from two sources:
- Mined Contracts: Extracted from nominal (clean) task-disjoint traces using a conservative acceptance algorithm (e.g., checking for positivity, categorical domains, and affine conservation relations).
- Public Schemas: Derived from public API response schemas (used in AppWorld).
The Detector: A runtime checker that evaluates a tool result $(y_t)$ against the relevant contract. If a violation is found, it generates a set of violation records $V_t$ .
The Advisory Receipt: Upon a violation, the system appends a non-binding receipt to the agent's context. This receipt contains:
- A diagnostic witness (e.g., "expected $\ge 0$ , observed $-3$").
- A list of recovery affordances: Public recovery tools (substitutes or alternative paths) available to the agent.
- Crucially, the receipt does not restrict actions, execute repairs, reveal benchmark labels, or consult an evaluator. The agent remains free to ignore the receipt or choose any action.

System Architecture

The interface follows a "Detect and Advise" pattern (Figure 1).

Input: Tool call $a_t$ , result $y_t$ .
Process: The checker $C$ maps $(a_t, y_t)$ to violations $V_t$ . If $V_t$ is non-empty, an encoder $E_s$ generates a receipt $\rho_t$ containing $V_t$ and a set of recovery tools $R_t$ (derived from public tool mappings, not task solutions).
Output: The agent receives the original result $y_t$ augmented with $\rho_t$ . The action set $A_t$ remains unchanged.

Key Contributions

Novel Interface Design: The paper proposes an interface that signals violations via an advisory receipt containing recovery affordances, rather than enforcing a specific repair or blocking execution. This preserves the agent's agency while providing structured guidance.
Non-Oracle Construction: Contracts are mined from disjoint clean traces or public schemas, ensuring the system does not rely on task solutions, gold sequences, or hidden recovery paths during construction or runtime.
Empirical Validation: The study evaluates the approach across three provider families (DeepSeek, Qwen, MiniMax) and two environments (ToolMaze, $\tau$ -bench), using frozen, task-disjoint workflows to ensure rigorous evaluation.

Results

The study reports significant improvements in task completion rates when Outcome Monitors are active, specifically in scenarios where faults block baseline completion.

ToolMaze Confirmation: Across four models (DeepSeek V4 Flash/Pro, Qwen 3.7 Plus/Max), completion rates increased from 10.9% (baseline) to 28.1% (advisory), a gain of +17.2 percentage points ( $p < .00001$ ). A separate replication with MiniMax M3 showed a similar gain (+18.75 points).
$\tau$ -bench Retail: In a stateful retail environment, completion improved by +14.0 points (DeepSeek V4 Flash) and +12.0 points (DeepSeek V4 Pro). Gains were concentrated on categorical status violations (+28.0 points) but showed no significant effect on affine conservation violations where baseline completion was already high.
Mechanism of Action: Ablation studies revealed that the list of recovery tools is the active component driving the gain. Removing the tool list eliminated the improvement, while adding generic warnings or diagnostic details without the tool list produced no measurable benefit.
Comparison to Reviewers: The Outcome Monitor outperformed a mechanism-faithful port of a "Reinforced Agent" (which uses a separate LLM reviewer) in both completion rates and cost (adding ~7% cost vs. ~498% for the reviewer).
Limitations of Detection:
- Vocabulary Boundaries: When tested on incident-derived faults authored blind to the contract vocabulary, detection rates dropped to 46%, particularly for corruptions within plausible strings.
- Clean Traffic: In clean (unperturbed) workflows, the system emitted false-positive receipts in ~1.4% of cases, resulting in a net-zero effect on completion (rescues balanced by harms).
- High-Baseline Scenarios: In environments where the baseline already completed most tasks despite faults (e.g., AppWorld held-out test), the net gain was negligible.

Significance and Claims

The paper claims that Outcome Monitors frame silent-failure recovery as an observability problem. The results suggest that viable recovery actions often already exist within the agent's tool repertoire but are not "legible" to the model without explicit signaling.

Modest Claims: The authors emphasize that the system is non-binding; it does not guarantee safety or prevent all harms (paired losses were observed). The gains are concentrated where faults actively block completion; the system is not universally beneficial in all contexts.
Open Challenges: The paper explicitly states that extending detection beyond the mined contract vocabulary remains an open problem. The current system relies on the alignment between the injected faults and the mined invariants; recovery from naturally occurring, unanticipated failures is not yet solved.
Design Philosophy: By separating detection from recovery, the approach allows the language agent to utilize its own reasoning capabilities to select the best recovery path, rather than relying on a rigid runtime guard.

In summary, Outcome Monitors provide a training-free, deterministic mechanism to improve agent robustness against silent tool failures by surfacing contract violations and available recovery tools, achieving significant completion gains in fault-heavy scenarios without compromising the agent's autonomy.