ReAct Prompting: Reasoning and Acting Together

Before: The Weak Prompt

Why do AI agents given access to tools so often use them in the wrong order, or skip checking whether a tool call actually worked before moving on to the next step? That's the exact question react prompting technique was built to answer, and it comes up constantly for anyone building an AI system that needs to take actions, not just generate text for a person to read.

Here's a weak version of an agent prompt for a system that can search a knowledge base and send emails on someone's behalf:

You have access to a search tool and an email tool. Help the user find information and send emails when they ask you to.

This gives the model access to tools without any structure for how to reason about when and why to use them, or how to verify a tool actually worked before proceeding to the next step. In practice, this produces agents that sometimes skip searching when they should, sometimes send emails based on unverified information, and rarely explain their own reasoning in a way you could actually audit after the fact when something goes wrong.

Why It Fails

Without an explicit structure connecting reasoning to action, models tend to either over-rely on their own general knowledge instead of using available tools, or use tools reflexively without a clear reason tied to the actual task at hand. Neither failure mode is obvious from the outside — the agent still produces a response, it's just not grounded in verified information or built on a clear justification for the actions it actually took along the way.

⚠️ Common mistake: Giving an AI agent access to tools without asking it to state its reasoning before each action. Without this, you lose the ability to audit why the agent did what it did, which matters enormously when something goes wrong and you need to understand the actual failure point rather than just the final incorrect outcome.

After: The Improved Prompt

ReAct — reasoning and acting — structures the interaction so the model explicitly alternates between thinking and doing, making each individual step visible and checkable by anyone reviewing the agent's behavior later:

You have access to: search_knowledge_base(query), send_email(to, subject, body).

For each step, follow this pattern:
Thought: [reason about what you need to do next and why]
Action: [the specific tool call to make]
Observation: [what the tool returned]

Repeat Thought/Action/Observation until you have enough information to complete the task, then provide a final response summarizing what you did and why.

Do not send an email until you have verified the relevant information via search_knowledge_base first.

What this does: forcing an explicit Thought before every Action means the model has to articulate its reasoning before committing to a step, which catches a lot of impulsive or unjustified tool use before it actually happens in a live interaction. The "do not send an email until verified" constraint is a hard guardrail on top of the general structure, specifically targeting the most consequential action available to this particular agent's toolset.

⚡ Pro tip: Add explicit hard constraints on top of the general ReAct structure for any action with real consequences — sending communications, making purchases, modifying records. The Thought/Action pattern improves reasoning quality generally, but a hard rule for your highest-stakes action is worth adding on top, not instead of the general reasoning structure.

⚡ Pro tip: When designing the tool descriptions an agent sees, be as explicit about failure conditions as about success conditions. An agent that only knows what a successful tool call looks like may not recognize a failed one clearly enough to trigger the kind of careful Observation step this entire technique depends on.

Breaking Down Each Element

The Thought step is what makes this technique fundamentally different from just giving a model tool access and hoping for the best. It forces the model to commit to a reason before acting, which means you can actually read the agent's reasoning afterward and identify exactly where things went wrong if the final outcome wasn't right, rather than trying to reverse-engineer intent from a sequence of tool calls alone after the fact.

The Observation step matters more than it might seem at first glance. Without explicitly capturing what a tool actually returned, models sometimes proceed as if a tool call succeeded even when it returned an error or empty result. Making the observation an explicit, visible step forces the model to actually process what happened before deciding on the next action, rather than assuming success by default.

An engineer building an internal support ticket triage agent found that adding explicit observation logging surfaced a recurring issue where a search tool was returning empty results for a specific ticket category, and the agent had been quietly proceeding as though it had found relevant information anyway. That bug had been completely invisible without the Thought/Observation structure making each step legible and reviewable after the fact.

⚡ Pro tip: Log the full Thought/Action/Observation sequence for every agent run, even in production, not just during testing. When something goes wrong, this log is the difference between a quick diagnosis and a frustrating guessing game about what the agent was actually doing at each step of the process.

⚡ Pro tip: If an agent's Thought steps consistently feel like an afterthought — brief, generic justifications that don't actually reflect real reasoning — that's often a sign the underlying task needs to be broken down further into smaller pieces, not that the ReAct structure itself has failed somehow.

Variations for Different Contexts

For agents handling genuinely open-ended tasks with many possible tool sequences, add an explicit instruction to state a brief plan before starting the Thought/Action loop: "Before your first action, briefly outline your planned approach for the full task." This gives you an early checkpoint to catch a fundamentally wrong approach before the agent has already taken several actions based on it, which is much cheaper to fix at the planning stage than after several tool calls have already happened and need to be undone.

For agents where speed matters more than a fully verbose audit trail, consider a lighter-weight version that only requires explicit Thought steps before higher-stakes actions, while allowing more routine, low-risk actions to proceed without the full verbose reasoning step every single time they occur. A customer support agent handling routine lookups might only need the full Thought/Action/Observation pattern before actions like issuing a refund or escalating a ticket, while simple information retrieval can move faster without carrying the same overhead.

⚠️ Common mistake: Building a ReAct-structured agent but never actually reviewing the Thought/Action/Observation logs it generates over time. The entire value of this structure comes from being able to audit what happened; skipping that review defeats much of the purpose of building the structure in the first place, and it's a surprisingly common mistake for teams that treat the structure as a one-time setup rather than an ongoing source of insight into the system's behavior.

There's a middle-ground variation worth knowing about for agents that need occasional human input mid-task, especially in situations where full autonomy carries meaningful risk: build in an explicit "Ask" step alongside Thought, Action, and Observation, used specifically when the agent's confidence in its next action is low enough to warrant checking with a human before proceeding further. This keeps the agent mostly autonomous while adding a safety valve for exactly the situations where autonomous action carries real risk to the business or the user.

Save and Reuse This

The engineer who found the empty-search-result bug now treats reviewing a sample of agent logs as a regular part of maintaining any ReAct-structured system, not just a one-time debugging exercise done when something visibly breaks in production. New failure patterns tend to surface this way well before they become visible complaints from actual users interacting with the system.

He also started tagging Thought steps that led to unexpected or incorrect actions, building a small internal library of "reasoning failures" his team reviews periodically, similar to a post-mortem process but focused specifically on the agent's decision-making rather than just the final outcome alone. This has helped his team distinguish between failures caused by a genuinely bad tool result and failures caused by the agent misinterpreting a perfectly good tool result, which call for very different kinds of fixes depending on the root cause.

It's worth building this review habit early, even for a very simple agent with just one or two tools connected to it. The habit of actually reading through Thought/Action/Observation sequences, rather than just checking whether the final output looked right on the surface, is what turns this technique from a nice structural idea into something that actually catches real problems before they compound into user-facing failures down the line.

If you're building multiple agents with different tool sets across your organization, the core ReAct structure — Thought, Action, Observation, repeat — is worth saving as a reusable template you adapt per tool set, rather than rebuilding the reasoning-action pattern from scratch each time. PromptABCD is useful here for versioning these agent prompt structures alongside the specific hard constraints you've added for each one's highest-stakes actions, so lessons learned building one agent transfer cleanly to the next.