When Agents Break

The loop that makes an agent powerful also gives it new ways to fail. Here are those failure modes — and the guards that make an agent you can trust.

Building with AI · Lesson 20 · 12 min read

Your flight agent from last lesson hits a snag: the flight search returns an error (the API is down). Instead of handling it, the agent calls search again… and again… 40 times — burning money and never stopping. A different day, it misreads “$640” as a date, books the wrong flight, and every later step faithfully builds on that mistake. The very loop that made the agent powerful is now the thing failing. How do you build an agent you can actually trust to run on its own?

New power, new failure modes

A single tool call has one input and one output — limited ways to fail. The loop adds three new ones. (1) Runaway / no progress: it can repeat the same action forever, or loop without getting closer to the goal. (2) Compounding errors: because each step’s output becomes the next step’s input, one wrong early observation quietly poisons everything after it. (3) Tool failures: real APIs time out and return errors, and an agent that doesn’t expect that gets stuck or crashes. More autonomy means more surface area for things to go wrong.

The runaway case, concretely:
• Step 1: search_flights → ERROR “API timeout.”
• Step 2: the agent, with no error handling, plans… search_flights again → ERROR.
• Steps 3–40: same call, same error, no progress — until you notice the bill.
Nothing here is “the model being dumb.” It’s an unguarded loop meeting an unreliable world.

Guardrails that make the loop safe

Each failure mode has a standard defense. Against runaway: a step budget (a max number of iterations) plus no-progress detection (stop or escalate if the same action keeps repeating). Against tool failures: validate each tool call against its schema before running it, and feed errors back as observations so the agent can adapt — try once more, switch tactics, or stop and report — instead of blindly repeating. Against drift in long runs: keep the goal salient and summarize history so it doesn’t scroll out of view. And before any irreversible action (sending money, deleting data), require confirmation. These are cheap to add and turn a fragile loop into a dependable one.

Trust comes from testing, not hope

You don’t make an agent reliable by wishing it were smart — you test it like any other system. Remember evals (Module 3): run the agent over representative tasks, watch where it loops, mis-calls a tool, or compounds an error, and add a guard for each failure you find. Reliability is engineered one fixed failure at a time. And design for graceful failure: even a well-guarded agent will sometimes get stuck, so the right end state is “stop and ask a human,” not “fail silently.” (Module 6 goes deeper on guardrails and safety.)

Fixing the infinite-retry agent, guard by guard:
1. Symptom: search_flights errors; the agent repeats it 40 times.
2. Step budget: cap the loop at ~8 steps — it can no longer run away.
3. Observe the error: feed “search failed: API timeout” back as an observation, so the agent can choose a different action instead of blindly repeating.
4. No-progress detection: if the same action+arguments repeats with the same failure, stop.
5. Graceful failure: escalate — “I couldn’t reach flight search after 2 tries; here’s what I attempted.”
Same agent, same world — but now it fails loudly and safely instead of silently and expensively.