Agent ReliabilityThe Agent That Survives Review
A task-specific support agent shipped with the envelope that keeps agent projects from being cancelled: an FMEA, a perturbation eval suite, drift monitoring, a cost kill switch, versioned configs, and one-command rollback.
Headline results
- Mock vs real
- 98.3% → 80.0%
- Suite
- 12 tickets × 5 classes
- Cost
- $0.0027/task vs $0.02 ceiling
- FMEA coverage
- 9 of 10 probed
System architecture
Problem
Gartner expects 40% of enterprise applications to embed task-specific agents by the end of 2026, and over 40% of agentic projects to be cancelled by the end of 2027. The difference between those two populations is not the model. It is whether anyone in the review meeting can answer four questions: what can it break, how would we know, what does it cost, and how do we undo it.
Approach
Take one deliberately ordinary agent, customer-support ops reading a ticket and drafting a resolution against an order database, and build the reliability envelope around it. Ten failure modes enumerated in an FMEA, each scored on severity, likelihood and detection, and each linked to an eval that actually probes it. A perturbation suite runs the golden tickets under paraphrase, noise, adversarial injection, and tool-error injection. PSI plus rolling task success watch for drift. A hard per-task token, dollar and step ceiling backs a kill switch. Agent versions are pinned as YAML and any candidate is canaried against stable before it can replace it.
Impact
The real Bedrock run is the finding. The scripted mock agent scores 98.3% task success across 60 runs; the same suite against real Claude Haiku 4.5 scores 80.0%, an 18-point gap that a mock-only portfolio would never have reported. Refund drafting stays gated in code rather than in the prompt, so it refuses ineligible orders no matter what the model asks. Real spend was $0.16 across the suite against a $0.02 per-task ceiling, and the canary correctly refused to promote v2 after its tool-error robustness collapsed from 100% to 33.3%.
Decisions & tradeoffs
Publish the mock-to-real gap instead of the better number
The scripted agent's 98.3% is a regression baseline, not a capability claim. Real Haiku scores 80.0% on the identical suite. Reporting both is the whole point: an eval harness validated only against its own mock tells you nothing about the model you ship.
Gate the dangerous tool in code, not in the prompt
Refund drafting refuses ineligible orders and over-limit amounts in Python, before the model's request is honoured. Prompt-level guardrails are advisory; a tool that can move money needs a check the model cannot argue with.
Name the failure mode you did not test
FMEA coverage is reported as 9 of 10 with input-drift listed as not probed. A coverage number that rounds itself up to complete is the exact failure the report exists to prevent.
Build spec
- Failure modes
- 10 enumerated, 9 probed, 1 declared open
- Perturbation suite
- 12 golden tickets × 5 classes = 60 runs
- Mock vs real
- 98.3% scripted → 80.0% real Claude Haiku 4.5
- Cost
- $0.0027 mean/task · $0.16 suite · $0.02 hard ceiling
- Rollback
- YAML-pinned versions, one command
System notes
- Every failure mode in the FMEA is linked to an eval that probes it, and the report names the one it did not probe rather than claiming full coverage
- The refund tool is dry-run only and gated in code: it refuses amounts above the order total regardless of what the model requests
- Canary caught a candidate that looked flat overall (73.3% vs 73.3%) but had lost tool-error robustness entirely
- 9 of 10 failure modes probed, and the unprobed one is listed as an open risk in the generated survival report
What this does not show
- The scripted mock's 98.3% is a regression baseline, not a capability claim; the real Claude Haiku number is 80.0%.
- Input drift is the one failure mode the suite does not probe, and the report says so rather than rounding coverage up.
Stack
Claude on Bedrock · FMEA · Perturbation eval · PSI drift · Canary + rollback · pytest