Why agents fail in production
After six agent deployments in 2024 and early 2025, the failure modes are shockingly consistent. Tool calls hallucinate parameters because the prompt didn't make required types non-negotiable. Prompts that worked for the engineer fail for end users because end users don't speak in the same shape. Evaluation harnesses cover the happy path because that's what the eng team thought of. Observability captures latency but not the model's reasoning trace. And rollback doesn't exist because "it's just a prompt change, what could go wrong."
The five failure modes
- Tool-call parameter hallucination — model calls function with malformed args.
- Prompt brittleness — works for the developer, fails for real users.
- Happy-path-only evaluation — no test for the messy 20%.
- Reasoning-blind observability — you see latency, not why.
- No rollback plan for prompt changes.
The reliability investment that pays for itself
3–5 weeks
Production-readiness window after a working agent demo. Skipping it is the most reliable way to ship a flaky agent.
The reliability work is unglamorous because it doesn't produce a demo. It produces an agent that works on Tuesday at 3am for the customer who phrased their request like nobody at the company would. That's the bar.
Evaluation harness
The single highest-leverage investment. A harness that runs the same 50–200 evaluation cases on every prompt or tool change, with pass/fail criteria expressed as both deterministic checks and LLM-judged rubrics. Without it, every prompt change is a vibe-check; with it, you can ship prompt changes the way you ship code changes.
Build the harness before you tune the prompt
The temptation is to ship a working prompt first and wire evals after. We've learned this is reversed. The evaluation harness is what lets you tune the prompt safely. Build it on day three of the engagement, not day forty.
Observability that captures reasoning
Latency dashboards aren't enough. You need every agent run to capture: input, system prompt version, every tool call with parameters and result, every model output with tokens, and the final action. When something goes wrong at 3am, you need to replay the run, not guess at it. We've standardized on Langfuse for this; OpenTelemetry traces with custom spans work too.
Tool boundary validation
Tool calling is the failure surface, not the model. Treat the tool boundary like an API: validate every parameter, reject malformed calls with structured errors the model can recover from, and log rejections as first-class events. We've seen agents with 99% prompt fidelity and 60% tool-call success rate; the model is only as good as the tool layer beneath it.
What 95% task completion actually means
The threshold for retention-positive agent deployment lands around 95% task completion under real customer load. Below that, customers learn the agent is unreliable and route around it. Above it, the agent earns trust and absorbs more workload. Hitting 95% requires the harness, the observability, the tool validation, and a non-trivial amount of prompt iteration. It's reachable in 6–10 weeks for a focused use case; not reachable on a 2-week build.
“We thought the model was the bottleneck. After three weeks of evaluation work, the model wasn't the bottleneck — our prompt was. Two weeks of prompt iteration backed by the harness took us from 71% to 94% completion.”