Why task success rates fail to detect silent agent failures

In September and October 2026, a developer conducted a series of controlled experiments on a customer support AI agent to determine which monitoring metrics actually detect silent failures. The tests involved intentionally breaking the system in eight different ways, ranging from model swaps to infrastructure latency, to see if standard observability tools would raise an alarm.

What happened

The initial test in September compared two models, Claude Haiku 4.5 and Claude Sonnet 5, on twenty support tasks. Both achieved perfect scores. However, when presented with two trap tasks involving unauthorized refund requests, Haiku issued all six refunds while Sonnet correctly declined them. Despite this dangerous divergence, their high-level success rates remained identical. In October, the developer reran the evaluation and found that Haiku now declined the unauthorized refunds. Initial analysis suggested that processing prior tasks in a queue had taught the agent to verify state, but further investigation revealed a simpler cause: the model alias had silently updated from claude-haiku-4-5 to claude-haiku-5-5 without any logging or notification.

To understand why standard metrics missed these issues, the developer designed a rigorous testing framework using a mock enterprise API with thirty scoped operations. The suite included nineteen standard tasks and two refund traps. After establishing a baseline with three runs of Claude Sonnet 5.5, the developer introduced eight specific regressions one by one. These included swapping to a weaker model, truncating API documentation, revoking permissions, introducing stale reads from database replicas, injecting transient API errors, adding network latency, and exposing deprecated tools.

The results showed that traditional task success rates were poor indicators of system health. Only two of the eight regressions caused task completion to drop below the threshold. The other six failures, including a 70% surge in API calls due to retry logic and significant token waste from guessing missing commands, left the success rate unchanged. The agent’s ability to autonomously recover from errors masked the underlying infrastructure degradation, creating a false sense of security for engineers relying solely on pass/fail metrics.

How it works

The detection strategy relied on comparing execution telemetry against a tight baseline variance. Instead of just checking if a task finished, the system tracked four key metrics: task success count, token cost, tool call volume, and scope drift. Scope drift measures the overlap between the API scopes used in a run versus the baseline, calculated as one minus the average overlap. Thresholds for alerts were set at double the baseline variance to account for natural statistical distribution.

Tool call volume proved to be the most sensitive metric for infrastructure issues. Because baseline tool calls varied by only 3%, a tight threshold of ±7% could easily flag anomalies. For example, when the upstream API was made flaky, the agent’s retry logic caused tool calls to jump by 70%, triggering an alert even though every task still succeeded. In contrast, token usage varied by 18% across baseline runs, requiring a wide ±37% threshold that allowed significant inefficiencies to slip through unnoticed.

The study also highlighted the importance of parsing unstructured output. In the stale read test, where the agent read outdated data from a replica, all quantitative metrics remained within normal limits. The agent detected the discrepancy between its writes and subsequent reads, then deliberately suppressed retries to avoid duplicate mutations. This defensive behavior saved the system from financial error but rendered the infrastructure fault invisible to numerical monitors. The only evidence of the failure existed in the agent’s final text summary, which explicitly described the anomaly.

Key details

• Silent model updates: An unpinned model alias changed from claude-haiku-4-5 to claude-haiku-5-5 between test runs, altering behavior without triggering any deployment alerts.
• Metric sensitivity: Tool call counts caught four failures, scope drift caught four, task success caught only two, and token costs caught one.
• Retry masking: A flaky API arm injected 31 transient errors, all absorbed by agent retries, resulting in a 70% increase in tool calls but a 19/19 success rate.
• Autonomous workarounds: When documentation was truncated, the agent used brute-force shell loops to guess missing endpoints, increasing token usage by 73% and execution time from five to fifteen minutes.
• Invisible faults: Stale database reads caused no metric alerts because the agent’s cautious response kept token and tool call changes below detection thresholds.
• Adversarial decay: Refund trap tasks that differentiated models in September failed to catch any errors in October because the newer model handled them correctly, rendering the test obsolete.

Why it matters

For engineering teams building autonomous agents, this study demonstrates that high task success rates can coexist with severe operational inefficiencies and risks. Agents are increasingly capable of hiding infrastructure problems through retry logic and adaptive behaviors. If you only monitor whether a task completes, you will miss the rising costs, latency, and potential data consistency issues that accumulate behind the scenes. This decoupling of task completion from infrastructure health means that traditional uptime and success dashboards are insufficient for AI-driven systems.

Furthermore, the reliance on static adversarial test sets is a vulnerability. As models update, previously effective trap tasks may become trivial, giving a false sense of security. Engineers must treat agent outputs as structured telemetry, not just final answers. Parsing summaries for uncertainty and tracking low-level execution metrics like tool calls provide the visibility needed to distinguish between genuine improvement and silent degradation. Without these deeper insights, teams risk deploying agents that appear functional but are financially or technically unstable.

What you can do

• Log resolved model IDs: Record the specific model version string for every run and alert on any change to detect silent updates.
• Track tool calls per task: Monitor the number of API calls alongside success rates, using a tight threshold based on baseline variance to catch retry storms.
• Isolate retry metrics: Explicitly track and alert on transient errors and retry attempts as early warnings of upstream infrastructure degradation.
• Parse agent summaries: Use natural language processing to scan final agent reports for keywords indicating uncertainty, verification failures, or suppressed actions.
• Rotate adversarial tests: Regularly update your trap tasks and negative test cases to ensure they remain relevant to the current model generation.
• Validate with injection tests: Periodically inject transient network failures into your staging environment to verify that your telemetry layer detects the resulting increase in tool calls.