ReAct Prompting: Combining Reasoning with Action

Most prompting frameworks focus on generating a single response. ReAct (Reasoning + Acting) is different—it creates a loop where the AI reasons about what to do, takes an action, observes the result, and then reasons again based on what it learned.

This makes ReAct the foundation for AI agents that can accomplish complex, multi-step tasks in the real world.

What is ReAct?

ReAct follows a repeating cycle:

1. Thought: Reason about the current situation and what to do next
2. Action: Take a specific action based on the reasoning
3. Observation: Note what happened as a result
4. Repeat: Use the observation to inform the next thought

This loop continues until the task is complete.

The Power of ReAct

Traditional prompting: "Research competitors and summarize findings" → AI generates a response based only on its training data

ReAct prompting: Same task, but with action capability → AI thinks about what information it needs, searches for it, evaluates results, searches again with refined queries, synthesizes findings

The difference is that ReAct can:

• Gather information it doesn't have
• Adjust strategy based on what it finds
• Handle unexpected results
• Build up to complex conclusions step by step

ReAct Format

Here's the basic structure:

TASK: [What needs to be accomplished]

Thought 1: [Reasoning about the task and first step]
Action 1: [Specific action to take]
Observation 1: [Result of the action]

Thought 2: [Reasoning based on observation, what to do next]
Action 2: [Next action]
Observation 2: [Result]

[Continue until task is complete]

Final Answer: [Synthesis of everything learned]

ReAct in Practice

Example 1: Research Task

TASK: Determine whether we should integrate Stripe or Paddle for our SaaS billing. We're a small team, selling to customers globally, price point $29-199/month.

Use ReAct reasoning to research this and provide a recommendation.

Thought 1: I need to understand the key differences between Stripe and Paddle for SaaS billing. The main factors for a global SaaS with that price point would be: global payment support, tax handling, pricing, and complexity. Let me start by outlining what I know about each.

Action 1: List key characteristics of Stripe and Paddle for SaaS billing
Observation 1:
- Stripe: Payment processor, you handle taxes, more control, lower base fees
- Paddle: Merchant of Record, handles taxes/compliance, simpler, higher fees

Thought 2: The "Merchant of Record" distinction seems crucial. For a small team selling globally, tax compliance could be a major burden. Let me explore what being a Merchant of Record means practically.

Action 2: Explain Merchant of Record implications for a small SaaS team
Observation 2: As MoR, Paddle is the legal seller. They handle all sales tax, VAT, and compliance globally. With Stripe, you must register for VAT in EU countries, collect appropriate taxes, and file returns—or use an additional service like TaxJar.

Thought 3: So Paddle saves significant operational overhead. But what's the cost difference? With our price points ($29-199), the percentage differences could matter.

Action 3: Compare Stripe vs Paddle fees for a $99/month subscription
Observation 3:
- Stripe: ~2.9% + $0.30 = ~$3.17 per transaction
- Paddle: ~5% + $0.50 = ~$5.45 per transaction
- Difference: ~$2.28 per transaction, or ~$27/year per customer

Thought 4: $27/year per customer is meaningful but not prohibitive. For 1000 customers, that's $27k/year—roughly equal to hiring someone part-time for tax compliance. But at 100 customers, the extra $2.7k/year might be worth the simplicity.

Action 4: Consider what else Paddle includes that might add value
Observation 4: Paddle includes: checkout UI, subscription management, dunning (failed payment recovery), license key generation, invoicing. With Stripe, you'd build these or buy separately.

Thought 5: For a small team, that bundling is valuable. Time spent building billing infrastructure is time not spent on the product. Let me consider the counterarguments for Stripe.

Action 5: Identify scenarios where Stripe would be better
Observation 5: Stripe advantages: More control over checkout UX, lower fees at scale, more payment method options, better for complex billing (usage-based, hybrid models), easier to switch processors later, larger ecosystem of tools.

Thought 6: The lock-in risk with Paddle is real—switching MoR is painful. And if we eventually need usage-based billing, Stripe's flexibility matters. But "eventually" could be years away for a small team.

Final Answer:
**Recommendation: Start with Paddle, plan to evaluate at 500+ customers**

For a small team selling globally at $29-199/month:
- Paddle's MoR model eliminates tax compliance burden (easily 10+ hours/month saved)
- The fee difference (~$27/customer/year) is less than the value of your time at this stage
- Bundled features (checkout, subscription management) accelerate development

The main risk is lock-in. Mitigate by:
- Documenting all integrations clearly
- Keeping customer data in your own systems
- Setting a trigger (500 customers or $50k MRR) to re-evaluate

At scale, the economics may shift toward Stripe + specialized tools. But the 0-500 customer phase should prioritize simplicity and speed.

Example 2: Debugging with ReAct

TASK: Debug why our user registration emails aren't being delivered to some users.

Thought 1: Email delivery issues usually fall into a few categories: sender reputation, spam filtering, configuration errors, or the actual sending failing. Let me start by establishing what we know about the pattern.

Action 1: Ask clarifying questions about the pattern
Observation 1: The issue affects about 15% of registrations, seems random, no pattern by email provider (affects Gmail, Outlook, etc. equally), started about 2 weeks ago.

Thought 2: "Started 2 weeks ago" suggests something changed. And 15% being affected randomly across providers suggests it's not a spam filter issue (that would likely be provider-specific). Let me think about what could cause random 15% failures.

Action 2: Check what changes were made 2-3 weeks ago
Observation 2: Changes: 1) Upgraded email service SDK, 2) Added rate limiting to signup endpoint, 3) Changed email template design

Thought 3: The rate limiting is interesting. If it's dropping requests, that would cause random failures. Let me investigate that path.

Action 3: Review rate limiting implementation for registration endpoint
Observation 3: Rate limit is 100 requests per IP per hour. In the logs, some requests are being dropped with 429 errors—these are proxy/VPN users who share IPs.

Thought 4: 15% could plausibly be VPN/proxy users sharing IPs. But wait—are the 429 errors preventing registration entirely, or just the email? If registration succeeds but email fails, that's a different issue.

Action 4: Check if 429 errors correlate with missing emails
Observation 4: Found the bug! When a 429 error occurs, the registration still succeeds (because we moved email sending after the rate limit check), but the email sending code path includes "return early on rate limit" that was added with the SDK upgrade. Users are registered but never emailed.

Thought 5: The fix is straightforward: email sending should not be affected by the rate limit, or rate limiting should happen before any processing.

Final Answer:
**Bug Found: Rate limiting logic affecting email delivery**

Root cause: When the registration endpoint hits a rate limit, we return 429 but still complete registration (on purpose, for UX). However, the new SDK's email sending code has an early return when it detects a rate-limited context, so emails are silently skipped.

Fix options:
1. (Quick) Remove the rate limit context check from email sending path
2. (Better) Move rate limiting before any registration processing
3. (Best) Decouple email sending into a background job queue that's not affected by request rate limits

Recommend option 3 for reliability. Option 1 as immediate hotfix.

Test: Verify emails send when X-RateLimit-Remaining header is 0.

When to Use ReAct

Strong use cases:

• Research tasks requiring information gathering
• Debugging and troubleshooting
• Multi-step workflows with dependencies
• Tasks where early results inform later steps
• Planning that requires validation

Less suitable:

• Simple Q&A
• Creative writing (usually doesn't need action loops)
• Tasks with no external information needs

Building ReAct Prompts

Template

TASK: [Clear description of what needs to be accomplished]

AVAILABLE ACTIONS:
- Search [query]: Look up information
- Analyze [data]: Perform analysis on provided data
- Compare [A] vs [B]: Compare two options
- Calculate [expression]: Do math
- Summarize [topic]: Condense information
- Ask [question]: Request clarification

Use the Thought/Action/Observation cycle to work through this task systematically. Continue until you have enough information to provide a complete answer.

Format:
Thought [n]: Your reasoning about what to do next
Action [n]: The specific action you're taking
Observation [n]: What you learned from the action

When complete, provide:
Final Answer: [Your conclusion with supporting reasoning]

Tips for Better ReAct Prompts

1. Define available actions: Be explicit about what the AI can "do"
2. Encourage iteration: "Continue until you have enough information"
3. Allow course correction: "If an approach isn't working, try a different one"
4. Require synthesis: End with a "Final Answer" that pulls everything together

ReAct in AI Agents

ReAct is the conceptual foundation for AI agents that can:

• Browse the web
• Execute code
• Call APIs
• Manage files
• Interact with tools

When you use an AI agent that can take actions in the world, it's likely using some form of ReAct under the hood.

Limitations of ReAct

• Speed: The iterative loop takes longer than single-shot prompts
• Token usage: Each iteration uses tokens
• Action definition: Only as good as the actions available
• Error propagation: Early mistakes can compound

Next Steps

ReAct combines well with other frameworks:

• Chain of Thought for the "Thought" phase
• Tree of Thought when multiple action paths exist

Explore all frameworks in our Complete Guide.

---

Marcus Johnson is a Developer Advocate at PromptWizz, specializing in agentic AI and complex workflow automation.