AI AI Agents in Production

Shipping AI agents to production: the unglamorous work nobody demos

LLM-driven agents demo brilliantly and fail in production for the same five reasons. Here's the reliability work that actually matters once a customer is on the other end.

LNOKS Team Updated May 2, 2026 2 min read
shipping-ai-agents-to-production-the-unglamorous-work-hero

TL;DR

Key takeaways

  • AI agents fail in production for five repeatable reasons. None of them are about model quality.
  • Plan 3–5 weeks of reliability work after the agent demos well. Skipping that window is what causes the 30-day rollback.
  • The single highest-leverage investment is an evaluation harness that runs the same 50 cases on every prompt change. Without it, every change is a vibe-check.
  • Observability must capture reasoning, not just latency. If you can't replay why the agent took an action, you can't debug it.
  • Tool calling is more failure-prone than the LLM itself. Validate every parameter at the tool boundary, not in the prompt.

Overview

AI agents demo brilliantly. They fail in production for five repeatable reasons: tool calls that hallucinate parameters, prompts that work for the engineer who wrote them and nobody else, evaluation harnesses that test the happy path only, observability that captures latency but not reasoning, and rollback that doesn't exist. Across six agent deployments at LNOKS in 2024 and early 2025 covering customer support triage, sales research, code review, and operations dispatch the production-readiness gap is reliably 3–5 weeks of unglamorous reliability work after the demo lands. The teams that skip it ship something flaky and roll it back within 30 days. The teams that invest in it ship agents that hold up at 95%+ task completion under real customer load.

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

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.

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.”
Engineering Lead · Customer support triage agent, 2024 deployment

Sources

  1. [1]
  2. [2]
    Anthropic on building effective agents — patterns and anti-patterns

    Anthropic anthropic.com

Frequently Asked Questions

Frequently asked questions

Two filters. First: is the workflow well-bounded with clear success criteria? Open-ended tasks ("be helpful") don't produce reliable agents; bounded tasks ("triage incoming support email into one of 12 categories and draft a reply") do. Second: is the cost of an error survivable? An agent that mis-tags a support ticket is fine; one that issues a refund without review is not.

Start with a frontier model (Claude Opus, GPT-5) to establish a ceiling, then test whether a faster/cheaper model meets the bar. We've shipped production agents on smaller models more often than the discourse would suggest, but the harness has to confirm parity before the switch.

Same as code: git, pull request, code review, deploy through the same pipeline. The harness runs on every change and blocks merges that drop key metrics. Treating prompts as configuration data instead of code is one of the most reliable ways to ship a regression.

Two engineers (one with LLM experience, one strong on infra and observability), one product person who can write evaluation cases, and a domain SME who validates outputs. The SME is non-negotiable; the harness is only as good as the cases in it, and the cases are only as good as the SME's judgment.

Year-one for a focused agent deployment is $80–180K all-in: 8–14 weeks of build, 6–12 months of monitoring and prompt iteration. Inference cost is a smaller line than most teams expect — usually under 15% of total in the first year — but it grows nonlinearly with usage.

Need help with ai agents development?

Tell us where you are. We respond within one business day with a fit assessment, indicative timeline, and a price band.