ReAct (Reasoning + Acting)

Observe, reason, act, observe again. There is no upfront plan; every action is informed by what actually happened, and a failed step is simply re-reasoned. The plan emerges from execution. The price: unpredictable token consumption, added latency, a path that is harder to audit.

The working tradeoff, seen from the other side: adaptability and embedded failure recovery against unpredictable cost and weaker governability. The same hybrid applies: a plan where the world is stable, re-reasoning checkpoints where it is not.

The mechanics

This architecture allows the agent to interleave thinking and doing in a tight loop where it observes the current state, reasons about what to do next, acts, and then observes the result in order to reason again. There is no upfront plan and every action is informed by what happened previously. In practice the agent receives a goal and takes one step. Once it examines what came back it decides the next step based on that result and repeats until the task is done. If one of the steps fails or returns something unexpected the agent re-reasons and adjusts. The plan emerges from execution, not before it.

Strengths

This architecture shines when adaptability is a hard requirement, because the agent responds to what is actually happening and not to what it predicted would happen. The approach also has failure recovery embedded, which means that a failed step is not fatal and the agent can reason about the failure and try another path. Lastly the approach has an exploratory character which fits tasks where the solution path is not known upfront and a discovered approach is far more preferable than a rigid plan.

Weaknesses

One downside of this approach is the token consumption, which can be high since the agent needs to execute multiple reasoning cycles. That also means the cost is unpredictable, because it is not known how many cycles the agent will need. Latency is another area where this approach falls short, since sequential reasoning loops add up, making it not viable when sub-second latency is required. Lastly, there is unpredictability: it cannot be forecast when the agent will finish or what path it will take. This also means that it is an architecture that is harder to audit and harder to govern.

Where it fits

Use cases that would benefit from ReAct include dynamic environments, exploratory tasks and in general situations where the world changes while the agent works. It is also a great approach for research tasks and debugging workflows. It should be avoided, however, when cost control, latency or auditability are primary concerns.