The agent loop is now infrastructure. Someone still has to pay for it.
ReAct went from a 2022 paper to enterprise infrastructure. The part nobody prices is what the loop costs to run.
In 2022, ReAct was a paper. In 2026 it is the default reasoning architecture for the native agents in IBM watsonx Orchestrate, the platform IBM sells to run autonomous agents across HR, finance, procurement, and customer service. A research loop became enterprise infrastructure in under four years. That is the headline. The part that does not make the slide is what the loop costs to keep running, and that is the part I work on.
The useful thing to notice is that the strength of ReAct and the operational hazard of ReAct are the same sentence. IBM’s own docs describe it as a single model that interleaves reasoning and action in a continuous loop without upfront planning. No upfront planning is what makes the agent flexible. It is also what makes it a loop with no stop condition tied to cost. Every turn of the loop is another model call, another line on the invoice, and, if you are careless, another chance to run a side effect twice.
What ReAct actually got right
The ReAct paper (Yao et al., submitted October 2022, published at ICLR 2023) did something real. Before it, you could make a model reason step by step, or make it call a tool, but reasoning on its own let errors compound: the model would argue itself confidently toward a wrong answer with nothing outside its own head to check against. ReAct interleaves the two. The model writes a short reasoning trace, takes an action against an external source, observes the result, and revises its plan. The grounding is the whole point. The authors report that this “overcomes issues of hallucination and error propagation prevalent in chain-of-thought reasoning” by letting the model consult something real between thoughts. On two interactive benchmarks, ALFWorld and WebShop, it beat imitation-learning and reinforcement-learning baselines by 34 and 10 absolute points of success rate, prompted with only one or two examples. That is a strong result. I am not here to argue with it. The loop works.
I do not publish papers, so I will leave the benchmark debate alone and talk about the part I do own: what this loop turns into when you run it in production instead of on a test set.
Read the same sentence as an operator
“A continuous loop without upfront planning” is a fine research property and, left unmodified, an operational liability.
Look at what the loop is made of. Reason, act, observe, repeat, until the model decides it is finished. The stop condition lives inside the model’s judgment. Most frameworks bolt on a maximum step count so it cannot spin forever, and that helps, but a step count is not a cost ceiling. One iteration that pulls a long document into context can cost a hundred times what the last one did, so bounding the number of loops tells you almost nothing about the bill at the end of them. On a benchmark none of this matters, because the task is small and the harness ends it. In production, “until the model decides it is finished” is closer to a blank check. A confused agent does not crash. It keeps reasoning, keeps calling tools, keeps spending, and usually keeps looking busy while it does. I have watched a loop work through a real budget doing nothing but talking itself in circles, and the demo version of that same agent looked flawless the day before.
Two things follow, and neither is a complaint about the paper. ReAct was answering whether interleaving reasoning and acting makes a model more capable. It does. It was not answering what happens when ten thousand of those loops run against your API bill on a Tuesday. That second question belongs to whoever operates the thing, and it has concrete answers.
The layer the paper does not write
Running the reason-act loop for real means adding three things it does not ship with.
First, a spend ceiling. Each iteration is a model call with a price, and the loop has no internal accountant. So you put one on the outside. That is what leash is: the token and compute spend governor I maintain for agent loops, a hard budget the loop cannot exceed no matter what the model decides. The choice to stop spending should not be delegated to the thing doing the spending.
Second, durable recovery, and this is the one that quietly hurts. The “act” step is usually a side effect. It books the meeting, files the ticket, moves the money. When a loop dies halfway and you restart it, a naive retry runs those actions again. Real durability means resuming from where it failed without repeating what already happened, which means every action has to be idempotent. That is the discipline behind rerun, the durable execution library I built on journal-based crash recovery. Exactly-once is a story you cannot tell honestly unless your steps are idempotent, and reason-act steps are usually not, until you make them so.
Third, a budget you can read per run, not just per month. drover, a budgeted agent runner, exists because “where did the spend go” is a question you want answered at the level of a single task, before the invoice arrives, not after.
None of this is exotic. It is the same discipline platform teams already apply to anything that runs unattended and costs money: bound it, make it resumable, meter it. The only new part is that the unattended thing is now a language model in a loop instead of a nightly batch job.
The power and the cost are the same property
Here is the opinion, marked as opinion. The industry is going to spend the next few years relearning, on agent loops, what it already learned on cron jobs and payment systems: unbounded automation is a liability, retries need idempotency, and anything autonomous needs a meter and a way to stop it. watsonx Orchestrate putting ReAct in front of enterprise buyers is not a mistake. It is the right default, and IBM also ships Plan-Act and deterministic orchestration for the cases where you do not want an open-ended loop. The mistake is buying the loop and assuming the governance comes in the box.
ReAct earned its place. The reason-act loop is genuinely how capable agents work, and it belongs in infrastructure. But infrastructure is defined by the dull layer wrapped around it: the limits, the recovery, the meter. The paper wrote the loop. The invoice is the part you own.
I take on a small number of agent-infrastructure engagements through Syltech. If your team is running agent loops in production and the token bill or the failure modes are starting to bite, book a discovery call: https://calendly.com/syltechai/discovery-call