Course Content
Agents & Tools Interview Prep
6 sections · 40 lessons
How does the ReAct framework combine reasoning and actions in agents?
What you need to know
The classic format
Thought: I need the user's current plan before quoting an upgrade.Action: get_subscription[customer_id=C-2291]Observation: {"plan": "team", "seats": 12}Thought: Team to Enterprise at 12 seats. I need enterprise pricing.Action: get_pricing[plan=enterprise]Observation: {"per_seat_inr": 1800}Thought: 12 × 1800 = 21,600 per month. I can answer.Answer: Upgrading 12 seats to Enterprise costs ₹21,600 per month.The harness stopped generation after each Action: line, ran the tool, and pasted the result as Observation:.
Why it works
- Grounding. Facts come from observations, not from what the model half-remembers.
- Adaptivity. After each observation the model can change plan — search again, try another tool, or stop.
- Traceability. The thoughts explain why each action was taken, which helps debugging.
What changed since 2022
| Then | Now (2026) |
|---|---|
| Actions written as text, parsed with regex | Native tool_use blocks with JSON arguments |
| Thoughts written in the visible output | Built-in thinking (e.g. adaptive thinking) that can run between tool calls |
| Parse errors when the model broke the format | Schema-valid calls, optionally guaranteed with strict mode |
So when someone says "we use a ReAct agent" today, they usually mean a tool-calling loop. ReAct is the mental model; the string format is legacy.
Weaknesses
- Greedy. It picks the best next step, not the best overall plan, so it can wander on long tasks.
- Cost. Every step is a full model call over the growing history.
- Error carry-over. A wrong observation, accepted as true, poisons later thoughts.
For long tasks with a stable shape, plan-and-execute is often better; for short, adaptive tasks, ReAct is the default.
A real-life example
A SQL analytics agent answers "Why did Bengaluru orders drop last Tuesday?" for a food-delivery company. It has read-only tools list_tables, describe_table and run_query.
It thinks it needs order counts by hour, runs a query, and sees orders fell 38% between 7 pm and 10 pm only. That observation changes the plan: it now checks restaurant_status and finds 210 restaurants in Koramangala marked offline from 6:50 pm. It then queries incidents and finds a payment-gateway outage in that zone. Final answer: the drop was a 3-hour regional gateway outage, not falling demand.
A fixed workflow ("run the weekly drop report") would have shown the drop but never followed the clue to restaurants and incidents. The adaptivity is the value — and the 10-query cap keeps it from exploring forever.
Follow-up questions to expect
- "How is ReAct different from chain-of-thought?" — Chain-of-thought reasons only from what the model knows. ReAct adds actions, so reasoning is corrected by real observations.
- "Do you still write Thought/Action prompts?" — Rarely. Use native tool calling; if you want visible reasoning for logs, enable thinking summaries or ask for a one-line reason before each call.
- "How do you stop a ReAct agent from wandering?" — Step and budget caps, a repetition detector, and sometimes a planning step first.