ReAct pattern

The loop you built has a name in the research lineage: ReAct — Reason, Act, Observe, interleaved. Before each action the model articulates why; after each observation it reconsiders. The pattern predates native tool use (it began as prompt scaffolding: 'Thought: … Action: … Observation: …'), but the idea survived because it targets the actual failure mode: models that act without articulating why act worse.

Why verbalized reasoning improves action choice

• Same mechanism as chain-of-thought (Prompt Engineering M3): tokens are compute. Writing 'the ticket mentions damage, so policy requires a photo — I should check whether one is attached before computing any refund' conditions the next tool call on that analysis.
• Reasoning text is your debugging record. A bare lookup_order(HL-1042) in a trajectory tells you what; the sentence before it tells you why — and wrong-why-right-action is a bug that hasn't fired yet.
• It's also the anchor against drift: each reasoning beat restates the goal in miniature, which is what keeps 15-turn trajectories from wandering.

ReAct in the native-tool-use era

With modern APIs you don't parse 'Action:' lines — the model emits text blocks (reasoning) alongside tool_use blocks (action) in the same turn, and extended-thinking models reason internally on top. Your job shifts from implementing the pattern to steering it: the system prompt line you already wrote ('think before each tool call: state what you need and why, briefly') is the modern ReAct scaffold. Two dials to tune:

• Depth by stakes: 'one sentence before read tools; full reasoning — facts, policy, amount — before any write tool.' Spend tokens where errors cost.
• Brevity everywhere else: un-steered agents drift into essays between calls, tripling cost and latency. 'Briefly' in the prompt, enforced by your Module 6 cost-per-task metric.