Worked examples — ReAct (reasoning + acting) framework
This page is the practice ground for ReAct. The parent note gave you the loop — Thought → Action → Observation → repeat until Finish. Here we run that loop through every kind of situation it can meet, from the clean case to the broken, degenerate, and adversarial ones.
Before we start: three plain-English reminders so no symbol appears unexplained.
The symbol (Greek letter "tau") is just a name for that ordered list — think of it as the transcript. Nothing more.
Below, the picture of the loop we will run — memorise this shape; every example is just this diagram walked once.

Figure description (s02): a left-to-right chain of four rounded boxes — "Question Q" (pale purple) → "Thought: decide next move" (lavender) → "Action: fire tool" (butter yellow) → "Observation: world replies" (mint green) — each joined by a slate arrow. A curved coral arrow loops from the Observation box back up to the Thought box, labelled "loop back: observation refines the next thought." A separate coral box "Finish: return answer" hangs below the Thought box, reached by an arrow labelled "when done." Caption underneath: "T = how many times you go round before reaching Finish."
The scenario matrix
Every ReAct problem falls into one of these cells. The examples below are labelled with the cell they cover, so you can see the whole space is filled.
| Cell | Case class | What makes it tricky | Example |
|---|---|---|---|
| A | Single-hop, clean | One thought, one action, done | Ex 1 |
| B | Multi-hop dependent | Action 2 needs Observation 1's answer | Ex 2 |
| C | Bad / empty observation | Tool returns junk → must replan | Ex 3 |
| D | Contradiction between tools | Two observations disagree → tie-break | Ex 4 |
| E | Degenerate: answer already in question | Zero tool calls needed | Ex 5 |
| F | Numeric / calculator chaining | Order of operations matters | Ex 6 |
| G | Limiting behaviour: loop that could run forever | Must terminate safely | Ex 7 |
| H | Real-world word problem | Translate messy prose into moves | Ex 8 |
| I | Exam twist: trap in the observation | Right data, wrong interpretation | Ex 9 |
Think of these cells like the quadrants in trigonometry: the "clean first-quadrant" case (A) is where formulas look easy, and the trouble hides in the edge cells. To see why they group the way they do, here is the same nine cells laid out on two axes — how many tool calls (horizontal) versus how trustworthy the observation is (vertical):

Figure description (s03): a scatter map with a horizontal axis "more tool calls →" and a vertical axis "observation trust →". Coloured lettered circles sit at positions: A (mint) top-left = few calls + clean data ("clean corner"); B (lavender), F (butter), H (light purple) along the top = multi-call but still clean; E (coral) at the origin = zero calls; C and D (coral) in the low-trust middle band labelled "untrustworthy observations"; I (coral) lower-right = low-trust trap; G (rose) pushed to the far right at mid-height, labelled "calls → infinity, must cap." The map shows trouble growing as you move right (more calls) or down (less trustworthy data).
Look at the map: the easy cell A sits in the safe corner (few calls, clean data). As you move right (more calls, cells B, F, H) or down (untrustworthy data, cells C, D, I), the reasoning burden grows — and E sits at the origin (zero calls), while G is pushed to the far edge (calls threaten to run to infinity). We work every region of this map below.
Reading the Calculate[...] syntax
Cell A — Single-hop, clean
Forecast first: how many tool calls do you think this needs? Guess before reading.
Answer: exactly one. Here is why, step by step.
- Thought 1: "This is a single fact I don't hold reliably. One search will settle it." Why this step? The agent must first decide whether it even needs a tool. A single, atomic fact → one lookup. Reasoning before acting stops it firing three redundant searches.
- Action 1:
Search["ReAct reasoning acting framework paper year"]Why this step? The action must match the thought's intent — search the exact fact named, no more. - Observation 1:
"ReAct: Synergizing Reasoning and Acting in Language Models, published 2022 (arXiv Oct 2022)."Why this step? The world grounds the answer. The agent did not invent "2022" — it read it. - Thought 2: "The observation directly answers the question. Nothing left to do." Why this step? Before finishing, the agent must confirm the observation actually answers — this check is what stops a premature or a needless extra search.
- Action 2:
Finish["2022"]Why this step?Finishis the only way to exit the loop; firing it now avoids wasting tool budget once the answer is in hand.
Verify: Trajectory length triples (one search-round plus one finish-round), one real search, one Finish. The answer "2022" appears verbatim in Observation 1 — it is grounded, not hallucinated. ✓
Cell B — Multi-hop, dependent
Forecast: can you answer this with a single search? Try to phrase that one query… you can't, and that's the point.
- Thought 1: "Two unknowns chained: (a) which continent holds the Nile's source, then (b) the tallest mountain there. I must resolve (a) first." Why this step? You cannot search for the second fact until the first is known — the queries are dependent. This is the defining feature of multi-hop.
- Action 1:
Search["source of the Nile river continent"]Why this step? The first action must target unknown (a) alone — searching for the mountain now would be premature, since we don't yet know which continent. - Observation 1:
"The Nile's most distant source is in the Great Lakes region — Africa."Why this step? Grounds unknown (a) with a real fact the agent can now reuse. - Thought 2: "Africa. Now the tallest African mountain." Why this step? The agent plugs Observation 1 into the next query — the loop's feedback in action.
- Action 2:
Search["tallest mountain in Africa height"]Why this step? This action is only well-formed because Observation 1 supplied "Africa"; it is the second, dependent hop. - Observation 2:
"Mount Kilimanjaro, 5895 m."Why this step? Grounds unknown (b) — the actual height the question asked for. - Thought 3: "I now have the height. Finish." Why this step? The agent verifies both unknowns are resolved before exiting; no third hop is needed.
- Action 3:
Finish["Mount Kilimanjaro, 5895 metres."]Why this step? Exits the loop with the grounded height, synthesised from the two-hop chain.
The figure below draws this trajectory as two stacked rows. Look at the red arrow: it carries the word "AFRICA" out of Observation 1 and drops it into the Action-2 query box. That single red arrow is the multi-hop dependency — cut it, and Action 2 has nothing to search for. The green boxes (observations) come from the world; the yellow boxes (actions) are what the agent fires; the lavender boxes (thoughts) are the agent's private reasoning that decides each move.

Figure description (s01): two stacked rows of rounded boxes. Top row: "Thought 1: which continent?" (lavender) → "Action 1: Search source of Nile" (butter) → "Observation 1: AFRICA" (mint), joined by slate arrows. A bold coral curved arrow labelled "AFRICA plugged into next query" sweeps from Observation 1 down into the second row's Action box. Bottom row: "Thought 2: tallest mtn there" (lavender) → "Action 2: Search tallest in Africa" (butter) → "Observation 2: Kilimanjaro 5895 m" (mint) → "Finish: 5895 m" (coral). Caption: "The RED arrow is what makes it 'multi-hop': step 2 cannot start until step 1's world-answer arrives."
Verify: Two searches, output of search 1 (Africa) is literally the input driving search 2. Remove step 4's substitution and the chain breaks — confirming this is cell B, not two independent lookups. Answer 5895 m grounded in Observation 2. ✓
Compare this with Self-Consistency, which samples many independent chains and votes — here the chain is serial and dependent, so voting wouldn't help; you need the real intermediate observation.
Cell C — Bad or empty observation (replanning)
Forecast: what happens if the first search comes back useless? A CoT-only model would be stuck. ReAct is not — watch.
- Thought 1: "Boiling point depends on pressure. I'll search directly." Why this step? The agent reasons about what physically drives the answer (pressure/altitude) before searching, so it can recognise a useful clue if the direct hit fails.
- Action 1:
Search["boiling point water Everest summit"]Why this step? Try the most direct query first — cheapest path to the answer if it works. - Observation 1:
"No exact match. Related: Everest summit elevation 8849 m."Why this step? This is a degenerate observation — not the answer, but a clue. The whole value of reasoning traces shows up now. - Thought 2: "The direct search failed, but I got elevation 8849 m. Boiling point falls ~1 °C per ~285 m of altitude near sea level; better, I'll look up the standard figure for that elevation."
Why this step? Error recovery — the agent notices the miss (a pure-action agent would blindly
Finishon junk) and pivots using the partial clue. - Action 2:
Search["water boiling point at 8848 m altitude"]Why this step? The reformulated query uses the salvaged clue (elevation) instead of repeating the failed one — a genuinely new search, not a retry. - Observation 2:
"Approximately 71 °C at the summit of Mount Everest."Why this step? Grounds the answer the first search missed. - Thought 3: "Now I have it." Why this step? Confirms the recovered observation answers before exiting.
- Action 3:
Finish["About 71 °C."]Why this step? Exits with the grounded, recovered figure.
Verify: Trajectory shows a failed observation (O1) followed by a replanning thought (T2) — exactly the branch a CoT-only model lacks. Final "71 °C" grounded in O2. Note because of the recovery hop, not the ideal . ✓ (See also Reflexion, which stores such failures across whole episodes rather than fixing them within one.)
Cell D — Contradicting tools (tie-break)
Forecast: what should the agent do if two searches give different numbers? Neither is a "junk" observation — both are real. Guess the fix.
- Thought 1: "Population figures often differ by definition. I'll search." Why this step? Anticipating that "population" is ambiguous before searching primes the agent to interpret, not blindly accept, the first number.
- Action 1:
Search["Paris population"]Why this step? Get the first concrete figure on the table so we have something to interpret. - Observation 1:
"Paris: 2.1 million."Why this step? A real datum — but its definition (city vs metro) is still unknown. - Thought 2: "That looks like city limits. Let me confirm the metro figure so I don't mislead." Why this step? The agent suspects an ambiguity of definition — a smart reader-catch.
- Action 2:
Search["Paris metropolitan area population"]Why this step? Deliberately fetch the other definition so both meanings are on the table before deciding. - Observation 2:
"Paris metro area: about 12.4 million."Why this step? Supplies the second figure; now the "disagreement" can be examined. - Thought 3: "The numbers don't contradict — they measure different things. I'll report both with labels rather than picking one." Why this step? Tie-break by disambiguation: when observations differ, don't average blindly — decide what each measures and answer honestly.
- Action 3:
Finish["City limits: 2.1 million; metropolitan area: 12.4 million."]Why this step? Exits with both labelled figures, which is more truthful than forcing one number.
Verify: Both numbers survive to the final answer with labels. The apparent "contradiction" was a definition clash, resolved by reasoning, not by discarding data. ✓
Cell E — Degenerate: answer already in the question
Forecast: how many searches? This is the zero-input edge case, the ReAct equivalent of "the angle is already given, don't call arctan."
- Thought 1: "The arrival time is stated in the question itself: 5 PM. No external tool can add anything. Acting here would be wasted." Why this step? The most-missed skill: recognising that the right number of actions is sometimes zero. Firing a tool anyway wastes budget and risks contradicting a fact you already hold.
- Action 1:
Finish["5 PM."]Why this step? With the answer already in hand,Finishis the correct first and only move — no observation is needed to justify it.
Verify: , a single Finish, no Search/Calculate. Cross-check: agrees with the handed schedule — the degenerate answer is self-consistent. ✓
Cell F — Numeric chaining (order matters)
Forecast: what goes wrong if you compute the percentage before the square? Predict the two different results.
- Thought 1: "'Square of 23' binds first, then take 15% of that, then round. Three ordered steps." Why this step? Establishing operation order up front prevents the classic slip of computing first.
- Action 1:
Calculate[23 ** 2](recall:**means "to the power of", so this is ) Why this step? Execute the innermost operation first; a real calculator eliminates arithmetic error the LM might make. - Observation 1:
529Why this step? Grounds the intermediate value so the next step builds on a verified number. - Thought 2: "Now 15% of 529." Why this step? Chains the result of step 3 into the next operation — the numeric analogue of multi-hop.
- Action 2:
Calculate[0.15 * 529]Why this step? Applies the percentage to the grounded square, in the correct order. - Observation 2:
79.35Why this step? Grounds the pre-rounding figure. - Thought 3: "Round 79.35 to nearest whole → 79." Why this step? The final requested operation (rounding) is simple enough to do in a thought, no tool needed.
- Action 3:
Finish["79"]Why this step? Exits with the rounded whole number the question demanded.
Verify: ; ; rounded . Wrong order would give , then — a completely different (and wrong) number, confirming order matters. ✓
Cell G — Limiting behaviour: the loop that could run forever
Forecast: the loop has no natural end here. What stops an infinite loop? This is the limiting case — where unless we intervene.
- Thought 1: "This may have no exact answer. I'll try once." Why this step? Deciding in advance to attempt only a single probe sets up the termination test — the agent commits to judging, not endlessly retrying.
- Action 1:
Search["exact number of grains of sand on Earth"]Why this step? One honest attempt is required before concluding the figure is unavailable — otherwise the agent would be guessing. - Observation 1:
"Only estimates exist (~7.5 × 10^18); no exact count."Why this step? The world reports the kind of answer available (estimate only) — the crucial signal for the stop decision. - Thought 2: "The observation says an exact figure is impossible. Searching again will just return the same class of result — repeating is pointless." Why this step? Loop-termination reasoning: the agent must detect a fixed point — when a new action can't change the observation, it must stop. Without this, ReAct spins forever.
- Action 2:
Finish["No exact count exists; the best estimate is roughly 7.5 × 10^18 grains."]Why this step? Exits honestly with the available answer (an estimate) instead of chasing an impossible exact one — the safe termination.
Verify: The trajectory terminates at despite an unanswerable question. Termination rule: if a repeated action would yield an observation of the same kind, stop and report the honest limit. This is the ReAct analogue of a maximum-step budget (real systems cap , e.g. ). ✓
Cell H — Real-world word problem
Forecast: which facts must come from a tool, and which are already given? Sort them before computing.
- Thought 1: "Given: departure logic (6 PM NY, 14 h flight). Needed from a tool: possibly the NY↔Tokyo offset to sanity-check the stated 8 AM landing. First compute the raw elapsed answer, which only uses given numbers." Why this step? Separate given data from tool-required data — the real-world skill. Don't search for what you were told.
- Action 1:
Calculate[14](hours until landing = flight duration, since "now" is departure) Why this step? The asked quantity ("hours until landing") equals the flight duration because "now" coincides with departure — a trivial calculation that pins the answer before any distraction. - Observation 1:
14Why this step? Grounds the elapsed-time answer so later sanity checks can't accidentally overwrite it. - Thought 2: "14 hours from 6 PM NY is 8 AM NY next day. Let me verify the Tokyo local claim with the offset." Why this step? Having the raw elapsed answer, the agent now uses a second tool as an independent sanity check — not to change the answer, but to confirm the stated landing time is plausible before committing.
- Action 2:
Search["New York to Tokyo time difference hours"]Why this step? Fetching the offset lets the agent test the ticket's "8 AM Tokyo" claim without altering the elapsed-hours answer. - Observation 2:
"Tokyo is 13 or 14 hours ahead of New York depending on daylight saving."Why this step? Supplies the offset needed for the plausibility check. - Thought 3: "6 PM NY + 14 h = 8 AM NY; +13 h offset ≈ 9 PM Tokyo — but the ticket says 8 AM Tokyo, so the offset/DST detail affects local display, not the hours until landing the user asked for. The asked quantity is simply 14 hours." Why this step? Answer the question actually asked — "hours until landing" — not the tempting side-quest of timezone conversion.
- Action 3:
Finish["14 hours until you land."]Why this step? Exits with the quantity the user requested, having confirmed no tool result overrides it.
Verify: Question asks elapsed hours, which equals the flight duration (14) because "now" is departure. Units check: hours in, hours out. The timezone search was a sanity check, not the answer path. ✓
Cell I — Exam twist: the trap in the observation
Forecast: the search will return a real, correct fact — and the trap is misreading it. Spot the trap before you read on.
- Thought 1: "Closest planet to the Sun is Mercury. Then I need Mercury's moon count." Why this step? Resolve the description ("closest planet") into a name before searching the property. Skipping this is how agents answer about the wrong planet.
- Action 1:
Search["number of moons of Mercury"]Why this step? Search the resolved entity (Mercury) directly, so the observation is about the right planet. - Observation 1:
"Mercury has 0 moons. (Note: the closest planet is sometimes confused with the closest to Earth.)"Why this step? The zero case — the honest answer is 0, and a careless agent might see "moons" plus a big number on the page (say, another planet's tally) and grab the wrong figure. - Thought 2: "The observation clearly states 0 for Mercury. I must not substitute a number from the distractor note. The answer is 0." Why this step? Trap avoidance: read the observation for the exact quantity asked, and ignore adjacent distractor numbers. The reasoning trace is what lets the agent resist the trap — an action-only agent would have no place to notice it.
- Action 2:
Finish["Zero. Mercury has no moons."]Why this step? Exits with the correct zero, deliberately not the tempting distractor number.
Verify: Correct chain: closest-to-Sun → Mercury → 0 moons. The zero is a legitimate answer, not a failure. Any nonzero output would mean the agent grabbed the distractor. . ✓
Wrap-up: the matrix is full
Every cell A–I now has a worked trajectory. Notice the pattern across them — all nine are just the one loop, walked with different exits:
Recall Self-test
What does count? ::: The number of Thought–Action–Observation triples in the trajectory (the final Finish counts as one).
How many tool calls does the degenerate case (answer in question) need? ::: Zero — a single Finish, cell E.
When two tools give different numbers, what is the first question to ask? ::: "Do they measure the same quantity?" — usually not (cell D).
What stops the ReAct loop in an unanswerable case? ::: A termination rule / step budget: if a repeated action can't change the observation, Finish with the honest limit (cell G).
In Ex 6, what is then of it? ::: , then , rounded .
Why can't Ex 2 be done in one search? ::: The second query depends on the first observation (Africa) — multi-hop, cell B.
In Calculate[23 ** 2], what does ** mean? ::: "Raise to the power of" — so it computes .
Related tooling: the actions here assume a working tool layer — see Tool Use in LLMs and MRKL for how those tools are wired; Retrieval-Augmented Generation (RAG) is the special case where the only tool is a document retriever; Agent Architectures frames where ReAct sits among agent designs.