ReAct in Production: When the Loop Earns Its Cost

The engagement that first made us sit down and rebuild our agent-pattern playbook was a customer-support workflow we'd inherited from a regional bank in the Gulf. The previous integrator had built it as a six-step ReAct loop running on a 70B model. The bank's monthly LLM bill had reached the point where the CIO asked us to do a cost review. When we traced it back, every single one of those six steps was deterministic — verify customer identity, look up account, retrieve last three transactions, check for disputes, suggest next action, log the interaction. A workflow engine with the model embedded at the two points where reasoning was actually required produced identical output at 22% of the inference cost. That experience generalised. ReAct is the foundational agent loop, introduced in a 2022 paper from Yao et al. Three years later it's the most widely-implemented and most over-applied agent pattern in enterprise AI. The pattern is genuinely valuable; it's also 4–6× more expensive than a single completion at the same task quality. The question we end up asking in every enterprise engagement is "does this workflow actually need ReAct, or would a chain or a structured prompt produce the same outcome at a quarter of the cost."

What ReAct actually buys you

Three distinct capabilities. First, dynamic planning — the model can pick its next action based on what it learned from the previous one, rather than executing a fixed sequence. This matters for workflows where the right next step genuinely depends on intermediate observations (multi-hop research questions, exception cases in workflows, anything where the path isn't predictable upfront). Second, interpretability — the Thought/Action/Observation triples are human-readable, which makes debugging and audit substantially easier than reasoning hidden inside a single forward pass. Third, recovery — when the model takes an action that fails, the next Thought step can incorporate the failure and try a different approach, which produces graceful degradation rather than hard failure. Each of these is real; none of them are needed for every workflow.

Where ReAct is the wrong pattern

If the workflow is a known sequence of steps with predictable branching, ReAct is overkill. A KYC pipeline that does ID capture, OCR, screening, decisioning in a fixed order doesn't need a model planning each step — it needs a chain or a workflow engine that executes the steps with the model embedded at the points where reasoning is required. We've remediated multiple customer deployments where the team adopted ReAct because the framework defaulted to it, then spent token budget proportional to the loop count for capability they didn't use. Switching to a chain produced identical output at 20–30% of the inference cost.

The verbosity tax

ReAct's Thought tokens are payload — they're the model reasoning about what to do, captured in the conversation, and re-fed into context on the next iteration. A 6-step ReAct loop typically consumes 8–14× the input tokens of a single-completion equivalent because every step replays the full Thought/Action/Observation history. For a production workload at 10M completions/month that's a multi-thousand-dollar-per-month difference at hosted-LLM prices. The mitigation isn't "shorter prompts" — it's structural: compress the Thought history between steps (summarise the salient outcomes, drop the verbatim reasoning), or use ReAct only for the planning phase and a tighter format for execution.

Pattern one — ReAct for planning, function-call format for execution

The pattern we deploy most often. A planning agent uses ReAct verbosely to decompose the user's goal into a structured plan (list of steps with dependencies). The execution layer then runs the steps in a tight function-call format — each step is a single Action emission and Observation pair, no Thought verbosity. The planner has the interpretability benefit ReAct exists for; the executor doesn't pay the cost for capability it doesn't need. Average production cost: 40–55% of pure-ReAct at equivalent task quality.

Pattern two — bounded ReAct with hard step + token budgets

ReAct loops can run away. The model gets stuck trying alternative approaches, reaches no conclusion, and consumes inference budget while doing it. The architectural fix is enforcement: the agent runtime tracks step count and cumulative tokens per workflow, and forcibly terminates when either crosses a configured threshold. The agent's runtime instructions include "if you cannot complete in N steps, escalate to human with summary." This converts the failure mode from silent budget drain to clean human escalation with traceable reasoning. Every production agent we ship has bounded budgets; none of the prototype agents do.

Pattern three — tool-use allow-list at every step

The Action half of each Thought/Action/Observation triple is a function call. Production ReAct restricts the set of available functions per agent, per user role, per workflow phase. The agent runtime enforces the allow-list — if the model emits a call to a function not on the current list, the runtime rejects it and feeds the rejection back as an Observation. This is Article 14 human oversight applied at the architecture layer rather than at runtime. The combination of bounded budgets + allow-list tool use is what makes a ReAct agent deployable in regulated production. See /agentic-ai for the full pattern catalogue.

Pattern four — full ReAct trace persisted for audit

Every Thought, Action and Observation goes into the audit log with the workflow ID, user ID, model version, and timestamp. Langfuse self-hosted is our default substrate. The audit log is the difference between "we used an agent for this decision" being an acceptable answer to a regulator and being an unacceptable one. The replay capability is non-negotiable for any Annex III workload under the EU AI Act, and is increasingly expected by RBI Master Direction reviewers and SAMA cyber-resilience auditors as well. /agentic-ai documents the full architecture.