I broke a working agent seven ways. The metric I was watching caught two of them.

In September, I conducted two evaluations of a customer support agent model using the same 20 support tasks. Both evaluations scored a perfect 20 out of 20. Subsequently, I presented each model with two invalid refund requests - one against an unpaid invoice and another for double the invoice amount. Claude Haiku 4.5 successfully processed all six refunds across three distinct permission configurations, while Claude Sonnet 5 handled none.

While their initial success rates appeared identical, their behavior diverged significantly when it came to tasks that could cause financial harm. In October, I reran the evaluation harness and found that the smaller model refused all unauthorized refunds. At first, I attributed this difference to the order in which tasks were processed - the two trap tasks were located at the end of a 22-task queue instead of being isolated.

Upon further inspection, I discovered that the underlying model had been silently upgraded behind an unpinned alias. I only uncovered this discrepancy due to a script search that I nearly overlooked. An unlogged, uninitiated deployment had taken place. Despite the improved performance, the oversight of monitoring gaps was troubling: my metrics failed to alert me if performance were to degrade instead.

In an attempt to further assess the agent's functionality, I established a baseline evaluation using Claude Sonnet 5.5, which had full administrative privileges across three identical runs. To simulate potential production failure modes, I introduced eight specific regressions in the evaluation environment. These included weakening the model, reducing API calls, truncating documentation, revoking permissions, serving stale data, intercepting transient errors, and exposing a deprecated alias.

Six of these eight regressions were executed within the API itself, while the remaining two were injected externally. Upon analyzing the detection results, I found that tool-call counts and scope drift each identified four failures, while task success rates only detected two. Token costs flagged one failure, and the refund trap tasks did not detect any.

Task success rates only caught the two regressions that made task completion physically impossible. Interestingly, swapping the model, modifying system prompts, failing 25% of network calls, and serving stale data from replicas did not trigger any detection alerts. These findings highlight the importance of having comprehensive monitoring in place to catch even the most subtle changes in system behavior.