ReAct

How it works

ReAct runs the agent as a tight think–act–observe cycle rather than a one-shot plan. Each turn produces two things: a short reasoning trace ("what do I know, what do I need next") and a chosen action, usually a tool call. The tool result is fed back in as an observation, and the model reasons again over the updated state.

The loop typically looks like this:

1. Reason — the model writes a brief thought about the current goal and gap.
2. Act — it emits a structured tool call (search, read, run, fetch).
3. Observe — the tool's output is appended to the context as evidence.
4. Repeat — reasoning consumes that observation and picks the next action.
5. Finish — when the model judges the goal met, it emits a final answer instead of another action.

The defining property is interleaving. The model does not plan the whole trajectory before touching the world; it lets each observation revise the next decision. That makes ReAct good at tasks where the path is unknown until you look — debugging, retrieval, multi-step research — because the agent can correct course on real output rather than a guess. The cost is that reasoning and acting share the same generation, and the loop will keep going until the model decides to stop.

Why it matters in an agent harness

ReAct is where most of your harness lives, because every iteration is a place to intervene. The pattern gives you natural seams: before an action you can gate it, after an observation you can inspect it.

Concretely, the loop is what you instrument and bound:

• Permissions attach to the act step. Each tool call is a discrete decision you can allow, deny, or route through an approval gate — not a buried side effect of one giant plan.
• Observability comes from the trace. The reason/act/observe sequence is a readable trajectory. You can log it, replay it, and evaluate it turn by turn instead of judging only the final answer.
• Failure containment needs limits. Because the model owns the stop condition, a ReAct loop can churn — repeating a failing call or wandering. An iteration budget and a tool budget turn an open loop into a bounded one.
• Reversibility depends on step granularity. Small, discrete actions are far easier to checkpoint and roll back than a monolithic execution. ReAct's per-step structure is what makes that practical.

In short, ReAct doesn't make an agent controllable on its own — it makes control placeable. The harness supplies the budgets, gates, and logging the raw loop lacks.

ReAct vs plan-then-execute

Both turn a goal into tool actions; they differ on when the model commits.

Use ReAct when the path can't be known in advance and cheap course-correction matters. Prefer an explicit plan when the workflow is stable and you want to review the intended steps before anything runs. Many production systems blend them: plan a coarse outline, then run each phase as a bounded ReAct loop.

The Rifty take

We treat ReAct as a loop to be bounded, not a capability to be trusted. The interleaved trace is a feature because it is legible and interruptible — but an unbounded loop that decides its own stop condition is a liability, so we cap iterations and tool budgets and make the trajectory the primary artifact we review. We optimize for a loop an operator can read, pause, and reverse over one that finishes fastest.

Common failure modes

• No stop condition. The model never decides it's done and burns the iteration budget. Enforce a hard cap and a clear "finish" action.
• Reasoning drift. Long traces accumulate stale assumptions; the agent reasons over its own earlier speculation as if it were fact. Keep observations authoritative and prune context.
• Observation blindness. The model emits a plausible next step that ignores what the last tool actually returned. Watch for actions uncorrelated with the latest observation.
• Repeated failing calls. The same tool is retried with the same bad arguments. Detect loops and break them rather than trusting the model to notice.
• Unbounded side effects. A write action inside the loop can't be undone. Gate mutating tools behind approval and checkpoint before them.
• Prompt injection via observations. Tool output is untrusted input; treated as instruction, it hijacks the next reasoning step. Isolate and sanitize observations before they re-enter the loop.

Frequently asked questions

How is ReAct different from a plain agent loop?

ReAct is a specific agent-loop pattern that interleaves an explicit reasoning trace with each tool action. A generic agent loop just repeats act-observe; ReAct adds a visible think step before every action, which grounds the next decision in fresh evidence and makes the trajectory legible for review.

When should I not use ReAct?

Skip ReAct when the workflow is fixed and repeatable. If the steps are known in advance, a plan-then-execute or deterministic pipeline is cheaper, more predictable, and easier to review. ReAct earns its cost only when the path is genuinely unknown until the agent observes real output.

How do I stop a ReAct loop from running forever?

Bound it externally, because the model owns the stop condition. Enforce a hard iteration budget and a tool budget, add loop detection for repeated failing calls, and require an explicit finish action. Treat any run that hits the cap as a failure to inspect, not a success.

Is ReAct safe to give write access?

Not by default. Every action in a ReAct loop is a live decision, so mutating tools need gates. Put write or destructive actions behind an approval gate, checkpoint before them, and keep read and write scopes separate so a wandering loop can't cause irreversible side effects.

How do I evaluate a ReAct agent?

Judge the trajectory, not just the final answer. Because ReAct exposes each reason-act-observe turn, you can score whether actions follow from observations, whether reasoning drifted, and how many steps it took. Trajectory evaluation catches loops that reach the right answer through unsafe or wasteful paths.