Running AI Agents in Production: Why Building Was the Easy Part

Every guide to running ai agents in production I've read this year opens the same way: "most autonomous agents stall at prototype." Then it lists reasons — hallucination, cost, latency — and closes with a framework diagram. None of it comes from anyone who has actually kept an agent alive past the demo.

I have 325 agents running right now. Not as a benchmark number — as a fleet I'm accountable for, doing real work: shipping code, running trading bots against live capital, managing content pipelines, executing crons at 3am when nobody's watching. Here's what building 325 of them taught me that no enterprise guide will: the build is the easy 20%. The other 80% is operations, and almost nobody writes about that part because almost nobody has done it at scale.

The Demo Problem vs. the Operations Problem of Running AI Agents in Production

Building an agent is a weekend project now. Give it a system prompt, wire up tool calling, point it at a task, watch it work. It's genuinely impressive the first time. It's also completely disconnected from what happens when that same agent has to run every day for six months without you standing over its shoulder.

The demo problem is: can this agent complete this task once, while I'm watching, with a clean input?

The operations problem is: can this agent complete this task 10,000 times, unattended, when the input is malformed, the API is down, the cost curve is climbing, and something upstream silently changed shape three days ago?

That second mindset is what I make the case for in AI Agents in Production: The Operator's Handbook — the operational layer is the actual product, not the model call underneath it. This post is the mythkill: I want to walk through exactly why the build-only mindset breaks, using the failure modes I've actually hit running a fleet, not hypothetical enterprise risk categories.

Guardrails Aren't a Feature, They're the Job

The first thing that breaks when you move an agent from demo to production is scope. A demo agent has one job and a clean lane. A production agent lives next to dozens of other agents, touching shared state, shared repos, shared infrastructure — and it will, eventually, try to do something outside its lane. Not maliciously. Just because nobody told it not to.

Guardrails are the fence around what an agent is allowed to touch, not a suggestion in a system prompt. In practice that means: file territory boundaries so two agents can't collide on the same code, branch protection so nothing lands on main without review, scoped credentials so an agent doing content work can't reach trading infrastructure, and human-in-the-loop gates on anything irreversible — force-pushes, database migrations, closing a PR with unmerged work still on it. I hold trading agents to a stricter version of this fence than anything else in the fleet; the decision-under-uncertainty framework behind that isolation is the same one behind indecision.io — the tighter the blast radius, the fewer guardrails you need to get exactly right.

None of that is exciting to build. All of it is the difference between a fleet you can leave running and a fleet you have to babysit.

Cost Control Is a Design Constraint, Not a Line Item

Every enterprise guide mentions cost as a bullet point. Running 325 agents taught me it's closer to a load-bearing wall. An agent that loops on a failing tool call, or re-reads a large file on every turn, or spawns sub-agents without a cap, doesn't fail loudly — it just burns budget quietly until someone notices the bill.

The fix isn't "monitor spend." It's building cost ceilings into the agent's operating envelope before it runs: hard iteration caps, token budgets per task class, and a kill condition that fires on cost velocity, not just cost total — because a slow leak and a runaway loop look identical on a daily total and very different on a per-minute one.

The shape of that diagram is the whole post. Build is a point. Run is a graph.

Drift Is the Failure Mode Nobody Budgets For

A model provider ships an update. A dependency changes its response shape. A source site you scrape restructures its HTML. None of these are "the agent broke" — they're "the world under the agent moved, and the agent didn't notice." I call this drift, and it's the hardest failure mode to catch because the agent doesn't error out. It keeps running. It just starts being wrong in ways that look plausible.

The only defense is comparing current behavior against a known-good baseline on a schedule, not waiting for someone to notice bad output downstream. That's a big enough topic I gave it its own post — Why AI Agents Fail in Production: 7 Failure Modes From a Live Fleet goes through drift and six other ways a fleet degrades quietly. The short version here: if you're not actively checking for drift, you're finding out about it from a customer, a trade loss, or a broken build — never from the agent itself.

The Discipline of Not Trusting "It's Done"

This is the one that took me the longest to internalize, and it's the one I'd tell a new operator first: an agent's self-report that it finished is not evidence. It's a claim.

Agents are trained to be helpful and to sound confident. That combination means an agent under time or context pressure will report success even when the underlying work is incomplete — not out of malice, out of the same optimization that makes it good at everything else. It generates the text that a finished task's summary would look like, because that's what a finished task's summary is supposed to look like.

The operational fix is boring and non-negotiable: independent verification, every time, no exceptions for agents that have been reliable before. Re-run the build yourself. Check the diff. Confirm the file that was supposed to change actually changed. I keep a verify skill in rotation specifically for this — it runs the build, lint, and test loop and produces a pass/fail report that doesn't take the agent's word for anything. It's one of 7 free skills at jeremyknox.ai/skills-library, no signup, because this single habit prevents more production incidents in my fleet than any other guardrail combined.

I wrote about the sharpest version of this lesson in Deployed Is Not Operational: The Session That Made 24 Agents Actually Talk — 430 passing tests and 98% coverage, and the fleet still couldn't make a single cross-service request, because "tests pass" and "system works" are different claims that happen to correlate most of the time. Most of the time is exactly the gap that gets you.

Graceful Failure Beats Clever Recovery

A lot of agent-framework marketing leans on self-healing: the agent detects its own error and recovers automatically. That's a real capability and it's genuinely useful in narrow cases. It is not a substitute for an agent that fails loudly and safely when it hits something it can't handle.

I've written before about what parallel dispatch across this fleet looks like from the throughput side — 53 Hours a Day: What AI Agent Orchestration Actually Looks Like covers the commander's-eye view. This post is the other half of that ledger: throughput without operational discipline is just a faster way to generate incidents. At fleet scale, a "smart" recovery that silently retries a bad state five times before giving up costs you five times the resources and five times the ambiguity about what actually happened. A dumb failure that stops immediately, logs the exact state it choked on, and escalates to a human is worth more than a clever one that muddies the trail trying to fix itself. Optimize for legible failure before you optimize for automatic recovery — you can't observe a fleet you can't reason about, and you can't reason about a fleet whose agents paper over their own mistakes.

That legibility requirement is why observability for agents looks different from observability for services — a service either returns 200 or it doesn't, but an agent can return 200 while having done the wrong thing entirely. I go deep on how to watch 325 agents without manually reading every transcript in AI Agent Observability: Monitoring 325 Agents Without Watching Them.

Every Piece of Operations Is Downstream of One Decision

Guardrails, cost caps, drift detection, verification discipline, graceful failure — none of these are separable features you bolt on after the agent works. They're all downstream of one decision: do you trust the agent's account of itself, or do you verify?

Everything else in this post is a specific answer to that question in a specific domain. Guardrails answer it for scope. Cost caps answer it for spend. Drift detection answers it for correctness over time. The verification habit answers it for task completion. Get that one decision right and the rest of agent operations is mechanical. Get it wrong and no framework choice, no model upgrade, and no amount of clever prompting will save you — I've watched teams swap frameworks three times chasing a reliability problem that was actually a trust-the-self-report problem the whole way down.

I built the equivalent of a 24-hour trading desk out of 325 agents that I did not personally supervise line by line. It works because the operations layer — not the agent's raw capability — is what I actually engineered. Running AI agents in production is a different job than building them, and 20 minutes of guide-reading from someone who's never kept a fleet alive won't teach it to you. Running the fleet does.

If you take one thing from this post, take this: the practice of running ai agents in production is measured in incidents avoided, not demos completed.

Start with the 7 free skills at jeremyknox.ai/skills-library — no signup. verify is the one to install first.