The ReAct Pattern

This cover deflates the mystique. ReAct looks like emergent intelligence in a demo, but mechanically it is a boring while-loop wrapped around one carefully written prompt. Seeing that plainly is what lets you build and debug it with confidence instead of treating the agent as a magic box.

The post walks the machinery in order: the control loop, the system prompt that defines the format, how actions get parsed and executed, how observations are fed back, and how the loop is made to stop. By the end the pattern should feel mundane in the best way — fully understood.

The loop is the heart of everything. You feed the running transcript to the LLM, read its next emission, and branch on what it produced. If the emission contains an Action, you execute the corresponding tool and append the result as an Observation. If it contains a final Answer, you return it. Otherwise you loop again with the grown transcript.

The reason to internalize this as 'just a loop' is that it demystifies failure. When a ReAct agent misbehaves, you are not debugging an inscrutable model — you are debugging a loop with a parse step and a dispatch step, each of which you can log and inspect. The intelligence is rented from the LLM; the control is ordinary code you fully own.

This slide locates the actual intelligence: the system prompt. It does three jobs. It enumerates the available tools with descriptions so the model knows its options. It shows the exact Thought, Action, Observation, Answer structure so the model emits parseable output. And it instructs the model to always reason before acting, which is what makes the reasoning happen at all.

The model's task then collapses to filling in that template one step at a time. This is why prompt quality dominates ReAct quality: a vague tool description or a fuzzy format spec degrades every subsequent step. The prompt is not boilerplate; it is the program the model is executing.

The flow diagram traces a single turn end to end: build the prompt from the transcript and tool list, call the LLM to emit the next step, parse whether that step is an Action or an Answer, run the tool if it is an Action to produce an Observation, then append and either loop or stop. Each box is a discrete, inspectable stage.

Reading it as a flow rather than a blob is what makes debugging tractable. A failure is always attributable to one box: the prompt was malformed, the LLM emitted garbage, the parser missed the action, the tool errored, or the stop logic misfired. Five small, testable stages instead of one opaque agent.

Parsing the action is where the text-format pattern shows its seams. The model emits something like Action: search("...") and the controller must extract the tool name and arguments. The classic approach is a regex over the text; the modern approach is the structured tool-calling API, where the model returns the call as machine-readable data instead of prose.

The contrast previews a major theme of the day. Regex parsing teaches you exactly what the loop does, which is why it is worth learning first, but it is brittle — any drift in the model's formatting breaks it. Native tool-calling removes the parsing problem entirely and is what you should use in production. Same loop, sturdier seam.

This slide highlights a subtle but crucial fact: the model never witnesses the tool execute. It only ever sees the Observation text you choose to append. That single line is the model's entire window into what the action accomplished, which means how you format and trim observations directly shapes the agent's next reasoning step.

The implication is leverage and responsibility. A clean, relevant Observation steers the model well; a giant dump of raw API output buries the signal and degrades the next Thought. You are the model's senses here, deciding what it gets to perceive about its own actions. That design choice matters as much as the prompt.

The trace diagram shows the transcript growing one line at a time as the loop runs: the question arrives, a Thought decides to query the database, an Action issues the SQL, an Observation returns the value, a final Thought concludes it can answer, and the Answer is emitted. Reading top to bottom is reading the agent's entire decision history.

This growing transcript is also the model's working memory. There is no hidden state — everything the model knows at step three is literally the text accumulated through steps one and two. That transparency is the source of ReAct's debuggability and, as later posts show, the source of its context-bloat problem when transcripts grow unchecked.

Stop conditions are where many naive implementations fail silently. The loop ends one of exactly two ways: the model emits a final Answer, or the loop hits a maximum-steps cap. The cap is not optional polish — without it, a confused agent that keeps re-issuing a failing action will loop forever, burning tokens and money.

Robust systems pair the step cap with a wall-clock timeout and a graceful failure message, so a stuck agent fails cleanly instead of hanging or spinning. Treat the cap as a safety fuse you always install. The mistakes post returns to this as the single most common production bug in ReAct agents.

The system prompt template makes the format contract concrete. It tells the model to always follow the Thought, Action, Observation, repeat structure, marks the Observation as system-filled so the model knows to stop and wait, and enumerates the tools with one-line descriptions. The model's entire job is to extend this template correctly, one step per call.

Two details carry real weight. The 'repeat as needed' instruction licenses multi-step reasoning rather than forcing a single hop. And the explicit final 'Thought: I now know the answer' before 'Answer:' gives the loop a clean, parseable signal that it is time to stop. Small wording choices here determine whether the loop runs smoothly or stalls.

The loop code shows how little glue ReAct actually requires. It seeds the transcript with the question, then loops up to max_steps times. Each iteration calls the LLM with a stop sequence on 'Observation:' so the model halts right after emitting its Action instead of hallucinating its own observation. If the step contains an Answer, it returns. Otherwise it parses the action, runs the tool, and appends the real Observation.

Two design choices are worth flagging. The stop token is what hands control back to your code at exactly the right moment — without it the model would invent fake observations and reason against fiction. And the max_steps bound on the for-loop is the infinite-loop fuse made literal. This twelve-line function is a complete, honest ReAct controller.

The recap distills the mechanics to five lines you can hold in your head. The loop is prompt, LLM, parse, tool, repeat. A system prompt defines the Thought/Action format. A stop token makes the LLM yield control after each Action. Each tool result is wrapped as an Observation. And you always cap max steps to prevent infinite loops.

These five points are the operational checklist for any ReAct implementation. If you can recite them, you can read any agent framework's source and recognize the same skeleton underneath, and you can build your own from scratch when a framework gets in your way.

The CTA moves from mechanics to a working build. You now understand the loop, the prompt, the parsing, the observation feedback, and the stop logic. The next post assembles all of it into a complete, runnable agent you can paste and point at your own tools.

Save this post as the reference you return to when an agent stalls or loops and you need to remember which of the five stages — prompt, call, parse, execute, stop — is the one that broke.