# ReAct agents explained: concepts & practical uses **Tagline:** News & Media | **Authors:** Jeff Mills | **Categories:** Tech DE | **Published:** 2026-08-18 | **Updated:** 2026-08-19 If you've watched an AI coding assistant hunt down a bug, run a test, read the failure, and adapt its next fix, you've watched Reasoning and Acting (ReAct)-like behavior at work. ReAct is a common pattern in production agent systems today. It's simple to build and surprisingly capable, which is exactly why it can get slow and expensive once it handles real traffic. This guide covers what a ReAct agent is, how the reasoning-and-acting loop works, how it compares to other [agent patterns](https://redis.io/blog/ai-agent-orchestration-platforms/), and what it takes to run these loops under production traffic. ## **What is a ReAct agent?** A ReAct agent is an AI system that works in a loop of thinking and doing. Instead of answering in a single step, it reasons about what the task needs, takes an action to get it (calling a tool, running a search, looking up a record), reads the result, and reasons again from there. That back-and-forth is what the name captures: the model plans its next move, acts to pull in real information, and uses what comes back to decide what to do next. The model reasons over its own internal representations without ever touching the outside world. ReAct grounds that reasoning in real feedback, which helps address the hallucination and error propagation that CoT can produce on its own. On ALFWorld, ReAct reported an absolute [success-rate gain of 34%](https://arxiv.org/pdf/2210.03629) over imitation and reinforcement learning methods. In production frameworks like LangChain and LangGraph, ReAct looks less like a research technique and more like a while loop. A while loop is a basic programming construct that keeps repeating the same block of code as long as a condition holds true, in this case "keep going until the model produces a final answer or hits a limit." Each time through, the model reasons about what it needs and picks a tool to call, then the framework runs that tool and feeds the result back in. This [agent execution pattern](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness) repeats until the agent has enough information to answer or hits a stopping condition. ## **How the reasoning & acting loop works** That while loop has a specific shape, and the easiest way to understand it is to see the prompt that drives it. LangChain's original create_react_agent [prompt](https://reference.langchain.com/python/langchain-classic/agents/react/agent/create_react_agent) instructs the model to follow this format: ``` Question: the input question to answer Thought: you should always think about what to do Action: the action to take, should be one of [{tool_names}] Action Input: the input to the action Observation: the result of the action ... (this Thought/Action/Action Input/Observation can repeat N times) Thought: I now know the final answer Final Answer: the final answer to the original input question ``` Each pass through the loop breaks down into four distinct moves: 1. **Thought:** the model writes a short reasoning trace that reviews earlier observations, updates the plan, and decides what to do next. 2. **Action:** the model picks a tool from the available set and specifies the input to send it, then hands control back to the app. 3. **Observation:** the app runs the tool, captures the result, and [injects the result](https://huggingface.co/blog/open-source-llms-as-agents) back into the prompt for the model to read. 4. **Repeat or finish:** the model reads the new observation and either starts another Thought-Action-Observation cycle or writes a final answer. Notice the division of labor: the model generates text, and your app code runs the tools and decides when to loop. Each turn ends in one of a few outcomes: another tool call, a final structured response, an error, or a maximum number of turns. Frameworks typically add a hard stop as a guardrail. LangGraph, for example, sets [a configurable recursion limit](https://langchain-ai.github.io/langgraph/troubleshooting/errors/GRAPH_RECURSION_LIMIT) before it raises an error. ## **ReAct vs other agent patterns** The loop above is one way to structure an agent, but it's not the only one. Other patterns keep the same basic idea of reasoning plus tool use, but they change when planning happens and how often the planner runs. ReAct has two documented downsides: it calls the LLM for every tool invocation, and it only plans one sub-problem at a time. The alternatives below each address one of those. Plan-and-execute patterns cut down on repeated planning calls by drafting a full plan upfront, then working through its steps. The Reasoning WithOut Observation (ReWOO) variant separates reasoning from observations, which can meaningfully improve [token efficiency](https://arxiv.org/pdf/2305.18323) over ReAct. The trade-off runs the other way for simple tasks, where ReAct starts executing immediately with no upfront planning call to pay for. Reflexion extends ReAct with self-critique. After a failed attempt, the model writes a natural-language reflection on what went wrong and retries with that critique in context. Reflection approaches trade extra compute for a shot at better output quality, so they tend to suit quality-sensitive tasks more than latency-sensitive ones. Multi-agent orchestration splits work across specialized agents, often with a lead agent delegating to subagents. It can be powerful for research-style tasks, but it comes with a real token cost. [Multi-agent systems](https://www.anthropic.com/engineering/multi-agent-research-system) can consume many times more tokens than a single-agent flow. The standard guidance is to start with the simplest approach and only add complexity when the task's value justifies it. That's a big part of why ReAct remains one of the widely adopted agent patterns today: it's simple to build and effective for a wide range of tasks. ## **Where a ReAct agent keeps its context between steps** Any of these patterns, ReAct included, only works if the agent can remember what it's already done from one step to the next. That memory lives in more places than most people expect. There are three tiers to know about, each with a different scope and lifetime. The first tier is the prompt itself. A scratchpad or message list accumulates the running conversation, tool calls, and observations, and the app re-sends that context to the model on each iteration. It's the fastest to access and the easiest to lose. When the loop ends, so does the memory. The second tier is thread-scoped persistence, which keeps a single conversation intact across sessions. Frameworks like LangGraph handle this with a checkpointer that saves a snapshot of the agent's state at every step, grouped under a thread identifier. Pass the same thread ID later and the conversation picks up where it left off, which also allows human-in-the-loop pauses and fault tolerance. The third tier is cross-thread long-term memory, which persists facts across separate conversations. This is where an agent recalls user preferences, past decisions, or learned facts even when the current thread is brand new. It typically lives in a durable store the agent can query by semantic similarity. Left alone, the in-prompt tier keeps growing until it hits a model or framework limit, which is why frameworks also offer trimming and summarization. Both help, but they come with a cost: trimming drops information, and summarization can lose details that turn out to matter later. Getting the balance right is what the next few sections are about. ## **Practical uses for ReAct agents** Memory tiers make the loop possible, but the more useful question is where teams actually put ReAct-style systems to work. Customer support is the most visible category today, with production agents handling millions of conversations for telecom, travel, and consumer services. These systems combine tool use (looking up account details, checking order status) with reasoning (deciding when to escalate) in exactly the pattern ReAct describes. Coding agents are the other headline category. Any tool that reads a stack trace, edits a file, runs a test, and adjusts based on the result is running a ReAct-shaped loop. Research assistants round out the picture: systems that plan a query, search, read results, and iterate until they have enough to answer. This category is still young, but it's growing fast. By the end of 2026, task-specific AI agents are projected to appear in [40% of enterprise apps](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025), up from under 5% in 2025. Most of those apps will run some version of the loop described above. ## **Why ReAct loops get slow & expensive as traffic grows** Those production wins can hide a cost curve that shows up as traffic grows, and it comes straight from the loop's design. Every iteration re-sends the full accumulated history: the original question, every prior thought, every tool call, every observation. Input length grows linearly per call, but cumulative billed input tokens can grow quadratically with the number of iterations. A ten-step task doesn't cost ten times a one-step task; it can cost far more. The composition of that context is worth pausing on. Most of the tokens in a running agent session aren't the user's messages. They're tool responses and tool definitions the model needs to see on every turn. That's why prompt hygiene (what you keep, trim, or retrieve on demand) matters more than raw context window size. More context doesn't just cost more; it can make the model worse. Practitioners have named four related failure modes worth knowing: - **Context poisoning:** a hallucination enters the context and gets repeatedly referenced in later steps. - **Context distraction:** a long context makes the model over-focus on its own history instead of synthesizing new plans. - **Context confusion:** the model uses superfluous information from the context, producing a lower-quality response. - **Context clash:** newly gathered information conflicts with what's already in the prompt. These risks compound as unmanaged context grows, which is why trimming and retrieval can be more effective than merely increasing the context window. Latency stacks the same way: a handful of LLM calls per task can push response times from under a second to tens of seconds. Most mitigations, whether caching, memory tiering, or summarization, aim to keep less in the context window and retrieve what you need fast. ## **Building ReAct agents on a real-time context layer** Trimming, tiered memory, and caching all put more weight on the data layer under the agent, and that's where Redis Iris fits. Iris is a [real-time context engine](https://redis.io/docs/latest/develop/ai/context-engine/) for AI agents: a set of managed services that give an agent fast, always-fresh context without running a vector database, a cache, and a session store as separate systems. For a ReAct loop that hits the data layer many times per task, keeping that context fast and consolidated is what holds cost and latency down. The services map cleanly onto the memory tiers from earlier. Redis Agent Memory gives an agent a [dual-tier memory](https://redis.io/docs/latest/develop/ai/context-engine/agent-memory/) layer: short-term memory holds the active session for fast access, while long-term memory stores extracted facts as text with vector embeddings the agent retrieves by semantic search across conversations. If you're building on LangGraph, the langgraph-checkpoint-redis package plugs straight in with RedisSaver for thread-level persistence and RedisStore for [cross-thread memory](https://redis.io/blog/langgraph-redis-build-smarter-ai-agents-with-memory-persistence). Semantic caching is where the cost curve bends. Instead of paying for another LLM call every time a user asks the same thing in different words, the app checks a cache of previous responses for one that means the same thing. Redis LangCache reported [up to 73% lower](https://redis.io/blog/llm-token-optimization-speed-up-apps/) LLM inference costs without code changes. On a cache hit, the agent skips the loop's most expensive step entirely. RedisVL, Redis' [Python client](https://github.com/redis/redis-vl-python) for AI apps, gives devs vector search, hybrid search, semantic routing, and LLM memory from code. ## **ReAct performance depends on its context layer** ReAct's iterative tool use suits customer support agents, coding assistants, and research systems in production today. But that same design gets expensive fast, because the loop re-sends a growing history on every step. How you manage the app's [context layer](https://university.redis.io/course/vsgabnbkd3f5cd?tab=details) shapes whether your agent stays fast and affordable. Managing that layer deliberately means keeping working memory small, persisting long-term memory outside the prompt, and caching answers you've already paid for. Redis Iris offers all three as managed services, so apps can run one context layer rather than operating three unrelated databases. [Try Redis Iris](https://redis.io/try-free/?rcplan=iris) to see how it fits your agent stack, or [talk to our team](https://redis.io/meeting/) about your AI infrastructure.