Production agents

A demo agent that works once is easy. An agent you'd let loose on real users and a real budget is a different animal, because an agent is a loop with tools — and loops with tools fail in ways a single model call never does: they spin forever, they crash on a tool error, they invent tool calls, and they quietly run up a bill. Every one of those has a specific guardrail.

agent loopguardrailsmax steps retrieshuman-in-the-loop

Four ways an agent fails — and the guardrail for each

The ReAct loop — think, act, observe, repeat — is powerful precisely because it's open-ended, and that open-endedness is the risk. Each failure mode below has a matching guardrail that contains it. Toggle the guardrails and watch which failures get caught:

Turn on the guardrails — which failures are contained?

Notice these aren't optional polish — an unguarded agent is a production incident waiting to happen. A missing step cap is an infinite loop billing you every iteration; an unhandled tool error takes the whole run down; an unvalidated tool call lets a hallucinated argument hit a real system; and no budget cap means one confused agent can spend a month's tokens in an afternoon.

A run that fails — and recovers

Guardrails aren't just about stopping; the good ones let the agent recover and keep going. Here's a run where a tool call fails: with retries and a fallback, the agent absorbs the error and still finishes. Step through it:

Tool error → retry → fallback → done — ▶ play it

The pattern under all of this is defensive by default: assume every tool call can fail, time out, or return garbage, and decide in advance what happens when it does — retry with backoff, fall back to a simpler path, or escalate to a human. And observability is not optional: log every thought, action and observation, because when an agent does something surprising in production, that trace is the only way you'll ever understand why.

⚠️ Traps & honesty: the "failures contained" meter counts which guardrails you've enabled — it is not a reliability score for a real agent, which also depends on the model, the tools and the task · guardrails have costs: a step cap set too low kills legitimate long tasks, aggressive retries add latency, and a human-in-the-loop gate defeats autonomy · validation catches malformed tool calls, not wrong-but-well-formed ones — those need evaluation and monitoring · real agents add sandboxing, permission scoping and rate limits on top of these · the recovery run here is a clean teaching example; real traces are messier.

Takeaways: an agent is a loop with tools, so it fails in loop-and-tool ways — infinite loops, tool crashes, hallucinated calls, runaway cost · each has a guardrail: a step cap, error handling with retry/fallback, tool-argument validation, and a budget cap · the best guardrails let the agent RECOVER (retry → fallback → escalate), not just stop · be defensive by default and log every step, because the trace is how you debug surprising behaviour. Next: ML system design frames the whole system around requirements.

Second opinion (taught here — these corroborate): Anthropic — Building Effective Agents · Hugging Face — Agents course.