A few months ago, I watched a beautifully demoed AI agent go to production and quietly burn through a month's LLM budget in four days. It wasn't broken, exactly. It just never learned when to stop.
That gap — between an agent that impresses in a demo and one you can actually own in production — is where I've spent the last couple of months as an engineering leader. And after enough postmortems, the failure modes start to rhyme. Here are the five I see most often, and what actually fixes them.
1. No termination discipline in the control loop
Most tutorials show you the happy path: the agent reasons, calls a tool, gets a result, answers. What they skip is the harness — the code around the loop that decides when the agent is done, when it's stuck, and when it's spiraling.
Without hard limits on iterations, token spend, and wall-clock time, you don't have an agent. You have an unbounded while-loop with a credit card.
The fix: treat the control loop as first-class engineering. Max iterations, budget ceilings, and an explicit "give up and escalate" path are not optional extras — they're the difference between a system and a demo.
2. Using an agent when a prompt chain would do
The most expensive architecture mistake is reaching for autonomy you don't need. If the steps are known in advance, a fixed pipeline of LLM calls is cheaper, faster, more testable, and dramatically easier to debug than an agent deciding its own path.
The fix: ask one question before you build — does the system need to choose its next step at runtime? If not, you don't need an agent. Saying this out loud in a planning meeting has saved more projects than any framework choice.
3. Tools designed for humans, not models
An API that's perfectly clear to a developer can be a trap for a model: ambiguous parameter names, twelve optional arguments, error messages that say Error 500. The agent doesn't "misuse" tools — it uses exactly what your descriptions imply.
The fix: write tool descriptions like you're onboarding a very literal junior engineer. Fewer parameters, explicit examples, and error messages that tell the model what to do next, not just what went wrong.
4. No evals, so every prompt change is a gamble
Teams that would never ship code without tests routinely ship prompt changes with zero regression coverage. Then a "small tweak" silently breaks a workflow three steps downstream, and nobody notices until a customer does.
The fix: build an eval suite before you scale. Golden datasets for the critical paths, LLM-as-judge for the fuzzy ones (calibrated against human labels — uncalibrated judges are just vibes with extra steps), and traces on every run so you can actually diagnose regressions instead of guessing.
5. Guardrails as an afterthought
Prompt injection isn't a hypothetical. The moment your agent reads external content — web pages, emails, tickets — that content becomes a potential instruction channel. And one guardrail at the input isn't enough, because injections can arrive through tool results mid-run.
The fix: layered guardrails — input, tool-call, and output — plus human approval gates on irreversible actions. Design the blast radius before you design the features.
Why I wrote a book about this
Every one of these lessons came from experience, not a keynote. I kept looking for a resource that covered the engineering — the harness, the evals, the guardrails, the tradeoffs — instead of another "build a chatbot in 10 minutes" tutorial. I couldn't find one, so I wrote it.
The Agentic Engineer: Designing, Evaluating, and Operating Multi-Agent AI Systems in Production is a build-along guide. You start with a single graph node and one tool call, and over thirteen chapters build it into a complete production-shaped agent: search and reasoning, memory across sessions, subagent delegation, layered guardrails, human-in-the-loop approvals, and full tracing. The stack is LangGraph, Langfuse, and Python. Every chapter ends with the anti-patterns — because what breaks teaches faster than what works — and the final chapter walks two complete case studies, including what went wrong in production and why.
If you can write code and you've made a few LLM calls, you have everything you need. No ML background required.
📘 It's available now on Amazon: The Agentic Engineer
There's also a companion GitHub repository that tracks the book chapter by chapter, so you can build alongside the text.
I'd genuinely like to hear from you: what's the worst agent failure you've hit in production? Drop it in the comments — I'm collecting anti-patterns for the next edition, and the weirdest one I've heard so far involves an agent that scheduled 400 calendar invites before anyone noticed.
Top comments (0)