Prompt Engineering Mastery

Course Content

Prompt Engineering Mastery

6 sections · 32 lessons

What is the difference between Chain of Thought and ReAct prompting?

Reasoning alone against reasoning with toolsChain of thought• Uses only what is in the prompt• One model call• Cannot check a single fact• Guessed the refund was on its wayReAct via tool calling• Fetches order and refund data• A loop of calls, capped at 6• Grounds each step in a result• Found the refundfailed on a closed UPI ID
When the answer lives in a database, more reasoning only produces a more convincing guess.

What you need to know

Chain of thought

  • Thinks with what is already in the prompt
  • One model call
  • Cannot check facts or fetch data
  • Risk: a wrong assumption spreads

ReAct

  • Thinks, then acts through tools, then reads results
  • Many calls in a loop
  • Grounds each step in real observations
  • Risk: bad tool calls, loops, cost

How ReAct is built in 2026

The original paper had the model write Action: search[...] as plain text, which the program parsed. Today you use the API's native tool calling: you declare tools with JSON schemas, the model returns a structured tool call, your code runs it and sends back the result. Reasoning models think between tool calls on their own, so you rarely write "Thought:" lines into the prompt. The loop is the same; the text format is outdated.

Choosing between them

SituationUse
All facts are in the prompt (a clause, an invoice)CoT, or just a reasoning model
Needs live data (order status, stock, prices)ReAct / tool calling
Needs exact computationTool calling with a calculator or code
Needs to change something (issue refund)Tool calling with permissions and confirmation

Guardrails ReAct needs

  • A maximum number of steps so loops end.
  • Typed tool schemas and validation of every argument.
  • Permissions — read tools freely, write tools only with checks or human approval.
  • Error results the model can see ("order not found") instead of silent empties.

A real-life example

A customer writes: "Where is my refund for order 88213? It's been 10 days."

With CoT alone, the model reasons about typical refund timelines and replies "refunds take 5–7 business days, so it should arrive soon" — plausible and wrong, because it never checked.

With ReAct via tool calling:

Text
Tools: get_order(order_id), get_refund(order_id)[model]  calls get_order(order_id="88213")[tool]   {"status": "returned", "returned_on": "2026-09-12"}[model]  calls get_refund(order_id="88213")[tool]   {"status": "failed", "reason": "UPI ID closed"}[model]  Your refund of Rs 1,299 failed because the UPI ID on file is         closed. Please add a new UPI ID and I will retry it.

The answer is specific and true. The team caps the loop at 6 tool calls, and the retry_refund tool requires the customer's confirmation before it runs.

Follow-up questions to expect

  • "Can you combine them?" — Yes; ReAct already contains reasoning. Reasoning models now reason before and between tool calls automatically.
  • "What goes wrong with ReAct?" — Tool loops, wrong arguments, trusting tool output that contains injected instructions, and runaway cost. Step limits and validation handle most of it.
  • "Is ReAct still a prompting technique?" — The pattern is; the implementation is now tool-calling APIs and agent frameworks rather than a text template.