Shipping AI agents to production: what survives contact with real users

There’s a graveyard of AI agent projects that were one great demo followed by six months of “almost ready.” The gap between an agent that impresses in a meeting and one that runs unattended against real users is where most of the engineering actually lives.

Here’s what we’ve learned shipping agents into production.

Evals before features

The single biggest predictor of whether an agent project ships: does the team measure quality, or argue about it?

Before building the agent, build the exam. Collect 50–200 real examples of the task — actual support tickets, actual documents, actual queries — with what a good response looks like for each. Every change to prompts, tools, or models runs against this suite.

Without evals, every improvement is anecdotal and every regression is invisible. With them, the project turns from vibes into engineering: “that prompt change moved task success from 81% to 88% but doubled tokens” is a decision you can make.

Tools are the product

An agent is only as good as the tools you give it. Most quality problems we debug turn out to be tool-design problems:

Tools that return too much. Dumping a 4,000-row query result into context doesn’t help the model — pagination, filtering, and summarized views do.
Tools with ambiguous contracts. If a human developer would need to ask what a parameter means, the model will guess wrong too. Descriptions are API documentation; write them like it.
Missing “escape hatch” tools. Agents need a way to say “I can’t do this” that routes to a human. Without one, they improvise. You don’t want improvisation in your refund flow.

Guardrails are boring and essential

Production agents run inside fences:

Permission scoping. The agent acts as a user with that user’s permissions — never as a superuser with a prompt telling it to behave.
Validation on the way out. Outputs that trigger actions (emails, records, payments) get schema-validated and, where the stakes justify it, human-approved.
Spending and iteration limits. Caps on tool calls, tokens, and wall-clock time per task. Runaway loops should hit a wall, not a credit card.

None of this is exciting. All of it is the difference between a pilot and a product.

Design for the failure modes

LLMs fail differently than normal software: confidently, plausibly, and without stack traces. The system around the agent has to assume this:

Log every step — prompts, tool calls, outputs — so failures are debuggable after the fact.
Make retries safe: idempotent tools, or explicit confirmation before repeating side effects.
Give users a visible path to escalate to a human, and treat every escalation as eval data for the next iteration.

Costs: measure per task, not per token

Token prices keep falling, but agent workloads keep growing to fill the budget. The metric that matters is cost per completed task, tracked in the same dashboard as success rate. Caching, model routing (small models for classification, frontier models for judgment), and tighter context management routinely cut task costs by half or more without touching quality.

Start smaller than feels impressive

The successful pattern we see: one workflow, clearly bounded, with a measurable outcome — triage these tickets, extract these fields, draft these responses for review. Prove it, instrument it, then widen. The teams that try to ship a “do everything” assistant first usually ship nothing.

Have a workflow you suspect an agent could own? Talk to us — we’ll scope a pilot with success metrics attached.