Long-running agents are finally viable in production. They also fail in five predictable ways. Here's the map — and the cheapest guardrail for each one.
Something real happened in the last six months: AI agents stopped being a demo category and started being something you could actually ship. The combination of better instruction-following, longer context windows, and cheaper inference has pushed multi-step autonomous tasks from "impressive in a controlled environment" to "running in production at companies you've heard of."
That's good news. The less comfortable version of the same news is that agents fail in ways that are fundamentally different from how a single-turn model fails — and most teams find this out the hard way, usually involving a task that ran for twenty minutes and produced something confidently wrong.
The failures aren't random. After enough production exposure, a pattern emerges: there are roughly five ways agents break, and they happen in roughly the same order as a system becomes more ambitious. Here they are, with the cheapest fix for each.
Early in a long task, the agent makes a small mistake — misreads a file, uses the wrong variable name, draws an incorrect inference. In a single-turn interaction, that error sits in isolation. In an agent loop, it gets appended to the growing context and becomes the ground truth for every subsequent step. The model isn't correcting course; it's learning from its own bad output and compounding the error.
Cheapest fix: build explicit checkpoints into long tasks — moments where the agent pauses, summarizes what it knows so far against the original goal, and either confirms it's on track or flags a discrepancy before continuing. This is especially important after any tool call that returns a large or ambiguous result.
Give an agent a toolset and it will occasionally invent tools that don't exist, call real tools with parameters that don't exist, or confidently pass a string to a field that expects an integer. This is less a model problem than a schema problem: the agent is pattern-matching against what a reasonable tool call "should" look like, and it doesn't always get it right.
Cheapest fix: validate every tool call against a strict schema before executing it. This is one line of code if you're using a framework with structured output support; without it, you're letting hallucinations execute. Never pass a model's raw tool call directly to an API without validation in the middle.
An agent hits a failing step — an API returns an error, a search comes back empty, a file doesn't exist. It tries the same approach again. Gets the same result. Tries again. This is the AI equivalent of restarting the router — and without a circuit breaker, an agent will burn through your entire token budget retrying something that was never going to work.
Cheapest fix: a step counter with a hard ceiling. After N attempts at the same class of action, force a branch: either escalate to a human, try a materially different approach, or terminate with a structured failure report. The ceiling can be as low as two or three for destructive operations.
This one is the most surprising to encounter. Given any room for initiative, agents will do more than you asked — not out of malice, but because the training on "be helpful" generalizes broadly. An agent tasked with "summarize this meeting" will sometimes also draft the follow-up email. One tasked with "clean up the temp directory" may decide the Downloads folder also looks messy.
In low-stakes contexts this is an annoyance. In high-stakes contexts — anything touching files, APIs, or external services — it's a liability.
Cheapest fix: an explicit scope declaration in the system prompt ("your only job is X; do not take any action outside of X") plus confirmation gates before any action that is irreversible or external. Annoyingly verbose to write; genuinely necessary.
The agent finishes, reports success, and the thing that was supposed to happen didn't happen. No error was surfaced — the agent just quietly took a different path when its preferred path failed, ended up somewhere adjacent to the goal, and reported "done."
This is the hardest failure mode to catch because it looks like success until you check the actual output.
Cheapest fix: a structured final report that includes what was attempted, not just what succeeded. This week's prompt is a template for exactly this. Force the agent to tell you where it got stuck, what it skipped, and what it's uncertain about — and you'll catch silent failures before your users do.
Every one of these failures is loud once you know what to listen for. Build the logging first — before you build anything else. If you can trace exactly what every tool call was, what context the model had at each step, and what it reported at the end, all five failure modes become debuggable. Without tracing, agent debugging is guesswork in the dark.
LangSmith is LangChain's observability platform for LLM applications, and it earns its place in the stack the moment you start building anything with multiple steps. Every LLM call, every tool invocation, every prompt gets logged with full input/output and latency — and you can replay any trace to understand exactly what the model saw at each point.
I started using it specifically to debug silent agent failures (see the Signal above), and it's changed how I think about agent development. The workflow is now: instrument first, then build. Without a trace, debugging an agent that did something unexpected is a reconstruction problem. With a trace, it's just reading.
The part nobody tells you: it's also genuinely useful for cost tracking. The token count per run across your traces will tell you, faster than any other method, which steps in your agent are eating your budget — and where you can optimize before scale makes it urgent.
Most agent frameworks give a model tools and a goal, then let it run. Reflexion asks a different question: what if the agent could learn from its own failures within a single session, without any gradient updates or retraining?
The mechanism is elegant: when an agent fails a task, it doesn't just try again — it first generates a verbal reflection on why it failed, stores that reflection in a memory buffer, and carries it into the next attempt. The reflection acts as a self-generated instruction that the model wrote for itself. Across a range of coding, reasoning, and decision-making tasks, this significantly outperformed vanilla retry loops.
It also directly addresses failure mode 3 from this issue (stuck in a loop) — forced reflection breaks the repetition by changing the information available before the next attempt.
This week: an agent debrief template. Add this to the end of any agent's system prompt — or inject it as a final message — to force a structured report on what actually happened. It's the direct fix for silent failure (failure mode 5), and it makes every agent run debuggable by default.
When you have finished the task — or cannot continue — produce a debrief in this exact format: ## STATUS [One of: COMPLETE / PARTIAL / FAILED] ## WHAT I DID [Numbered list of the specific actions taken, in order. Be precise: which files, which APIs, which searches.] ## WHAT I SKIPPED OR COULD NOT DO [Anything you attempted and failed, anything you decided not to do and why, anything you are uncertain about in the output.] ## CONFIDENCE [High / Medium / Low — and one sentence on why.] ## WHAT TO CHECK [The one or two things a human should verify before trusting this output.] Do not skip any section. If a section has nothing to report, write "None." Do not summarize the task — report what you actually did.
The key line is the last one: "Do not summarize the task — report what you actually did." Without it, models will restate the assignment rather than account for their actions. With it, silent failures surface in the debrief instead of reaching your users.
New issue every weekday at 7am. Free forever.
No spam. Unsubscribe in one click.