The ReAct Pattern

This cover delivers the post's hard truth with a concrete horror story: an agent that worked in the demo loops twelve times in production, picks the wrong tool, and spends real money to conclude it cannot answer. The clever loop is the easy part; the guardrails are what determine whether it survives contact with reality.

The post is a field guide to the specific, repeatable ways ReAct agents fail — no step cap, brittle parsing, vague tool descriptions, context bloat, swallowed errors, and no graceful exit — paired with the concrete fix for each. These are the mistakes that turn a promising agent into an expensive liability.

The no-step-cap mistake is first because it is the most dangerous and the most common. Without a hard iteration limit, a confused agent does not fail — it loops, often re-running the exact same failing action, never converging, quietly draining tokens and dollars until something external kills it. There is no natural stopping point in a loop that keeps finding reasons to continue.

The fix is non-negotiable: set max_steps and a wall-clock timeout, and return a graceful failure when either trips. Treat the cap as a fuse you install before the agent ever runs, not a feature you add after the first runaway bill. Every robust ReAct implementation bounds its loop, period.

This mistake targets the text-format parser specifically. A regex tuned for Action: tool("x") shatters the moment the model writes single quotes, adds a newline, or rephrases the line slightly — and models drift in formatting constantly, especially across versions and temperatures. Text-format ReAct is brittle by its very nature because it depends on the model formatting prose exactly as your parser expects.

The fix is to stop scraping text. Use the model's native tool-calling API so the action arrives as structured, typed data that cannot drift out of format. Regex parsing is wonderful for understanding the pattern and unacceptable for production reliability. If your agent breaks intermittently for no clear reason, fragile parsing is the first suspect.

Vague tool descriptions are a quiet killer because the model selects and invokes tools using nothing but their descriptions. 'lookup: gets data' gives the model no basis to decide when the tool applies or what argument to pass, so it guesses — calling the wrong tool, passing malformed input, or ignoring a tool it should have used.

The fix is to write tool descriptions like real API documentation: state precisely what the tool does, when to use it versus alternatives, the exact format and meaning of each argument, and what it returns. The model is your only user of these docs, and it is a literal-minded one. Time spent sharpening tool descriptions buys more reliability than almost any other tweak.

The mindmap organizes the failure space into four buckets — Loop, Parsing, Tools, and Context — so the mistakes are memorable as categories rather than a flat list. Loop failures are missing step caps, repeating the same action, and no timeout. Parsing failures are brittle regex and format drift. Tool failures are vague descriptions and swallowed errors. Context failures are observation bloat and losing early facts.

This taxonomy is a diagnostic tool. When an agent misbehaves, walk the four branches: is the loop bounded, is the action parsed reliably, are the tools well-described and their errors visible, and is the context staying manageable? Most broken agents fail on at least one branch, and identifying the branch points you straight at the fix.

Context bloat is the failure that creeps up as tasks get longer. Every Observation is appended to the transcript, so a multi-step task with verbose tool output balloons the prompt. The agent slows, costs climb with every token, and — most insidiously — reasoning degrades as the early, important facts get buried under pages of raw tool output.

The fix is to manage what the model perceives. Summarize or truncate observations before appending them, keeping only what later steps actually need. A search tool that returns a full page should hand the agent a few relevant sentences, not the whole document. Remember the earlier insight: the model only sees the Observation text, so curating that text is curating the agent's mind.

The comparison puts a fragile agent beside a robust one trait by trait, as an auditable checklist. Fragile: no step limit, regex-parsed actions, vague tool docs, errors that crash the loop, raw observations piling up. Robust: max_steps plus timeout, native tool-calling, API-grade tool docs, errors fed back as observations, and observations summarized.

Use this as a self-audit. If your agent matches the left column on even one row, that is a thread to pull before you ship. The right column is not aspirational perfectionism — it is the minimum bar for a ReAct agent whose success in a demo predicts anything at all about its behavior under real traffic.

Swallowing tool errors is the mistake that prevents self-correction, ReAct's signature strength. When a tool throws, the wrong responses are to crash the whole loop or to silently hide the failure. Either way the model loses the chance to react to what went wrong. A network timeout, a bad argument, a missing record — these are information the agent could act on if it could see them.

The fix is to catch the exception and feed it back as an Observation. Now the model can read 'tool error: invalid date format' and reason about it — retry with a corrected argument, fall back to a different tool, or report the failure honestly. A caught error the agent can perceive becomes a recovery opportunity instead of a dead end. This is the loop's adaptability working as designed.

The no-give-up mistake is the one teams discover last. An agent with no explicit way to admit defeat will do one of two bad things when it cannot complete a task: fabricate a plausible answer, or loop until it hits the step cap and dies with a generic failure. Neither is honest, and the fabrication is actively dangerous because it looks like success.

The fix is to give the agent an explicit exit — a 'finish' or 'give up' action it can call to report that it could not complete the task, optionally with a reason. This makes failure a first-class, observable outcome rather than a hallucinated success or a silent timeout. An agent that can say 'I couldn't do this' is far more trustworthy than one that always produces an answer regardless of whether it found one.

The code operationalizes the most important guardrails in one function. It records a start time and, on every iteration, checks both the step count (via the bounded for-loop) and a wall-clock deadline, returning a graceful timeout message if either is exceeded. The tool call is wrapped in try/except so a throwing tool produces an Observation the model can see rather than an unhandled crash.

These few lines are the difference between a demo and a deployable agent. The deadline and step cap together guarantee the agent always terminates; the try/except guarantees a tool failure becomes a recoverable Observation instead of a stack trace. Make this guarded shape your default skeleton, then fill in the parsing and answer-detection logic. Robustness here is cheap and the absence of it is what produces surprise bills and silent failures.

The tips consolidate the post into a buildable checklist: cap steps and add a timeout, use native tool-calling instead of regex, write tool docs like real API docs, summarize observations to fight bloat, feed tool errors back instead of swallowing them, and give the agent an explicit way to give up. Each line is the direct antidote to one of the six mistakes.

The meta-lesson is that a trustworthy ReAct agent takes deliberate engineering — it does not emerge by default from the clever loop alone. The loop gives you capability; this checklist gives you capability you can deploy. The gap between those two is where most ReAct agents quietly fail in production.

The CTA closes the day and points to the next building block in the series. You have now seen what ReAct is, why it became the agent baseline, how the loop and prompt actually work, how to build the agent in code, and how the same agent fails without guardrails. That is a complete, defensible foundation for building reasoning-and-acting agents.

Save the day as a set. The concept anchors the Thought-Action-Observation model, the stakes explain why it won, the mechanics show the loop, the code makes it real, and these mistakes keep your agent honest and affordable when it finally meets real traffic.