The ReAct pattern: reasoning and acting interleaved
ReAct (Reasoning and Acting) is the foundational pattern for single-agent systems. It enables an agent to generate a "Reasoning Trace" or "Chain of Thought" (CoT)—an internal monologue where the agent verbalizes its plan and rationale before executing an action. Instead of generating a complete response upfront, the agent alternates between producing "thoughts" and "actions" (calling tools). Each action produces an observation, which informs the next thought. This iterative loop continues until the agent concludes it has sufficient information to provide a final answer.
ReAct Loop: Reasoning and Acting
Loading diagram...
ReAct Compared to Pure Reasoning and Pure Acting Approaches
| Approach | Tool Use | Adaptability | Best For |
|---|---|---|---|
| Pure Reasoning (Zero-shot) | None | Low—cannot gather new information | Knowledge retrieval, creative writing, simple Q&A |
| Pure Acting (Function-only) | Direct tool calls without reasoning | Medium—can act but cannot adjust strategy | Deterministic workflows, fixed-step processes |
| ReAct (Interleaved) | Reasoning-directed tool calls | High—adjusts based on observations | Complex tasks requiring information gathering and iterative refinement |
When ReAct Adds Unnecessary Latency
The ReAct loop introduces latency with each thought-action-observation cycle. For simple queries answerable from training data, or for deterministic workflows where the optimal sequence is known upfront, a single-shot or pure-acting approach is faster and more cost-effective. Reserve ReAct for tasks requiring genuine exploration or where intermediate observations inform strategy.
Enterprise Agentic Architecture and Design Patterns
Salesforce Architect guide presenting a pattern-based methodology for agentic solutions, including the ReAct loop, plan-and-execute, and the full taxonomy of Interaction, Specialist, Utility, and Long-Running patterns.
Read the Salesforce design patterns guideAWS frames single-agent capability as a ladder from reasoning to orchestration
AWS Prescriptive Guidance usefully separates single-agent patterns by the kind of action boundary they cross. The progression is not just "smarter prompts." It moves from stateless reasoning, to tool selection, to delegated execution on tool servers, and then to workflow orchestration that coordinates subagents and long-running state.
AWS single-agent pattern progression
| Pattern | What it adds | Good fit | Operational watch-out |
|---|---|---|---|
| Basic reasoning agent | Structured prompting without tools, memory, or state | Classification, summarization, guidance, lightweight Q&A | Cannot verify or fetch new facts beyond the prompt and model knowledge |
| Function-calling agent | Dynamic tool selection from schemas and tool metadata | Assistants that need API lookups, calculations, or controlled side effects | Weak tool contracts and missing allowlists quickly become security and reliability problems |
| Tool-server agent | Delegated execution to isolated runtimes, logic chains, or subagents | Stateful, multimodal, or resource-intensive tools that need retries and isolation | You now need runtime governance, audit logs, dependency management, and failure recovery |
| Workflow orchestration agent | Agent selection, state tracking, retries, and long-running coordination | Supervisor-style flows, scheduled jobs, escalation, and cross-domain automation | Higher latency and complexity require explicit checkpointing, fallback paths, and cost controls |
This ladder is useful for architecture decisions because it discourages teams from jumping straight to orchestration. If a job is answerable with a basic reasoning agent or one tool-calling loop, adding a supervisor and worker fleet usually creates more failure modes than value. The AWS pattern set is explicit that orchestration is for long-running, multi-agent, or cross-domain work where context retrieval, retries, and state tracking are part of the problem.
AWS: Basic reasoning agents
Defines the stateless reasoning baseline and explains when a lightweight agent is enough before adding tools or memory.
Read the basic reasoning patternAWS: Tool-based agents for calling functions
Covers schema-based tool selection, structured function calls, and the shift from pure reasoning to controlled action.
Read the function-calling patternAWS: Tool-based agents for servers
Explains when tool execution should move into isolated runtimes that can chain logic, host subagents, or manage retries.
Read the tool-server patternAWS: Workflow orchestration agents
Shows how AWS frames supervisor-style agents that select workers, preserve context, and coordinate multistep execution over time.
Read the workflow orchestration patternAWS distinguishes inline function calling from server-hosted tool execution
The AWS pattern guide makes a useful architectural distinction that many teams skip: some agents should call functions inline, while others should delegate execution to server-hosted tools. The difference is not cosmetic. It changes how you isolate failures, manage side effects, observe execution, and control multistep work.
Function-calling vs server-hosted tools on AWS
| Decision point | Function-calling agent | Server-hosted tool agent |
|---|---|---|
| Execution scope | One bounded capability with structured arguments and direct return values | A richer execution surface that can chain tools, run workflows, or host specialized logic |
| Best fit | Lookup, calculation, mutation, or API calls with a stable schema | Browser or shell tasks, multistep operations, multimodal flows, or policy-heavy integrations |
| Governance need | Schema validation, allowlists, and least-privilege invocation | Isolation boundaries, runtime observability, retries, and more explicit blast-radius control |
| Failure mode | Wrong tool choice or malformed arguments | Long-running step failure, state drift, or hidden side effects inside the server workflow |
A good rule is to start with inline function calling when the business action is narrow and inspectable. Move to server-hosted tools when the capability needs its own lifecycle: isolated runtime dependencies, retries, internal sequencing, multimodal perception, or a controlled subagent surface. AWS is explicit that this second pattern is not just a bigger function. It is a different execution boundary.
AWS: Tool-based agents for calling functions
Explains schema-based tool selection, argument construction, and direct tool invocation inside the reasoning loop.
Read the function-calling pageAWS: Tool-based agents for servers
Explains when execution should move to a server-hosted surface that can chain tools, isolate side effects, and expose richer capabilities.
Read the server-hosted tools pageSpecialized AWS agent archetypes
Beyond function calling and basic execution, AWS defines specialized single-agent archetypes tailored for specific domains. These specialized agents combine reasoning with dedicated architectures, such as persistent memory, visual understanding, and telemetry ingestion.
The Computer-use agent simulates or controls digital environments like browsers and terminals. It combines LLM reasoning, visual language models (VLMs) to analyze screen states, and tool servers to execute commands.
The Memory-augmented agent bridges session continuity by retrieving and reasoning over short-term (context) and long-term (vector databases) memory. This allows it to persist goals and adapt to user preferences across interactions.
The Observer and monitoring agent passively ingests telemetry (logs, metrics, events), reasons through an LLM to identify anomalies or compliance issues, and triggers alerts without directly acting on the environment.
Other specialized AWS archetypes include Coding agents (optimized for IDE integration, codebase tracking, and iterative compilation loops), Speech and voice agents (incorporating speech-to-text and text-to-speech for conversational AI), and Simulation and test-bed agents (for running synthetic workflows and exploring hypotheticals).
AWS Prescriptive Guidance: Agent Patterns
Comprehensive guide to AWS agentic patterns including specialized agents.
Read the AWS agent patterns overviewPlan-and-Execute: decomposing complex tasks
The Plan-and-Execute pattern separates task decomposition from execution. The agent first analyzes the request and generates a structured plan—a sequence of steps or subtasks. It then executes each step sequentially, with the option to revisit and revise the plan if execution fails or conditions change. This two-phase approach reduces error cascading by establishing a coherent strategy before committing to actions.
Plan-and-Execute Flow with Replanning
Loading diagram...
Replanning occurs when execution fails or intermediate results reveal that the current plan is suboptimal. In dynamic environments—such as interacting with external APIs, querying databases that may change, or coordinating with other systems—conditions may shift mid-execution. The Plan-and-Execute pattern allows the agent to pause, reassess, and generate an updated plan rather than blindly continuing with an obsolete strategy.
When Plan-and-Execute Shines
This pattern excels for multi-step workflows where upfront planning reduces error cascading. Examples include: (1) Data analysis pipelines with dependencies between queries; (2) Code generation with multiple files and imports; (3) Research tasks requiring structured investigation; (4) Multi-stage API workflows. The planning phase catches impossible sequences early, while the execution phase focuses on correct implementation.
Reflection and self-critique
The Reflection pattern introduces a self-critique loop: after generating output, the agent evaluates its own work against a rubric, checklist, or set of criteria. If the evaluation identifies deficiencies, the agent revises the output and repeats the cycle. This process continues until a quality threshold is met or a maximum iteration limit is reached.
Evaluator-Optimizer (Maker-Checker) Pattern
Loading diagram...
Reflection Pattern Tradeoffs
| Aspect | Benefit | Risk / Limitation |
|---|---|---|
| Output Quality | Self-correction catches factual errors, logic gaps, and style issues | Over-correction may introduce new errors or excessive caution |
| Performance | Fewer hallucinations and higher reliability | Each reflection cycle adds latency and token cost |
| Practical Limits | Improves with explicit rubrics and structured evaluation | Model cannot reliably detect errors beyond its training or knowledge cutoff |
| Implementation | Can be combined with external validation (tests, linting) | Complex to set termination criteria; may loop indefinitely on subjective tasks |
Self-critique has practical limits. A model can only evaluate output against criteria it understands; it cannot reliably detect factual errors beyond its knowledge cutoff, nor can it identify subtle logical flaws it missed in generation. For critical applications, pair reflection with external validation: automated tests, code linters, factual verification against databases, or human review for high-stakes decisions.
Reflexion: Language Agents with Verbal Reinforcement Learning
The foundational paper proposing Reflexion, an approach where agents reflect on task feedback to maintain their own episodic memory and improve future actions.
Read the Reflexion paperTool-Use composition: building capability through tools
Tools are the primary mechanism by which agents interact with the world beyond their training data. A tool is a structured function—defined with a name, description, and parameter schema—that an agent can invoke. Good tool design follows API best practices: clear contracts, comprehensive error handling, idempotency where possible, rate limits, and permission scoping. By composing tools together, agents build complex capabilities from simple, reliable primitives.
Tool-Use Architecture (Thought-Action-Observation Loop)
Loading diagram...
Anthropic: Tool Use (Function Calling)
Comprehensive guide from Anthropic on how agents construct, execute, and observe tool calls to accomplish multi-step goals.
Read the Anthropic Tool Use guideTool Design Considerations
| Consideration | Best Practice | Rationale |
|---|---|---|
| Contract Clarity | Detailed descriptions, explicit parameter types, examples in docstrings | Agents rely on tool metadata to decide when and how to call; ambiguity causes misuse |
| Error Handling | Return structured errors with recovery hints, not raw exceptions | Agents need actionable feedback to retry or adjust strategy |
| Idempotency | Design tools so repeated calls with same inputs produce same results | Agents may retry on failures; idempotency prevents unintended side effects |
| Rate Limiting | Implement per-tool and per-agent limits with backoff strategies | Prevents runaway cost from tool loops or agent confusion |
| Permission Scoping | Least-privilege access; tools expose minimal necessary capabilities | Reduces blast radius if an agent is tricked or hallucinates malicious calls |
Tool Allowlists Are Your Primary Security Boundary
Agents cannot access tools you do not expose. Implement strict allowlists: only include tools the agent requires for its designated task. For high-risk operations (file writes, API mutations, data deletion), require explicit human approval or separate safety checks. Never grant an agent unrestricted access to a system—tools should be scoped, logged, and auditable.
Tool composition follows the UNIX philosophy: small tools that do one thing well, combined to accomplish complex tasks. A data analysis agent might compose a "query database" tool, a "visualize results" tool, and a "export report" tool. Each tool is independently testable and debuggable. The agent orchestrates them, but the tools remain stable, reusable primitives. This modularity simplifies maintenance: updating a tool improves all agents that use it.
Specialist and Utility Patterns
In enterprise agentic architecture, specific single-agent roles are defined to perform targeted functions. These patterns act as specialists with deep knowledge or utilities handling repetitive tasks.
The Answerbot pattern uses GenAI to interpret natural language for knowledge retrieval. It is effective for self-service applications.
The Domain SME pattern encapsulates a specific business domain (e.g., Orders, Claims), providing a natural language interface to that domain's data and processes.
The Interrogator pattern connects concepts across a body of content to answer questions comprehensively, avoiding manual swivel-chair integration.
The Data Steward pattern is an autonomous, background pattern that introduces an agentic step into data operations to ensure consistent data quality and enrichment.
The Zen Data Gardener pattern is a scheduled background agent used to validate, enrich, and conform data across domains periodically.
The Prioritizer pattern orders a set of tasks or work objects based on a defined objective. It leverages GenAI for qualitative analysis, unstructured data analysis, or integrative analysis across multiple data domains to create a responsive "Next Best Action" in the flow of work.
The Generator pattern creates new content (e.g., case summaries, email drafts, knowledge articles) from existing inputs and standards. It is often implemented as a prompt and may be embedded within other agents as a utility.
The Judge & Jury pattern minimizes hallucinations by using an ensemble of "juror" agents and a "judge" agent that assesses the congruence of responses to ensure they are materially consistent and grounded. For best results, each juror should use a different foundation model (e.g., one from OpenAI, another from Anthropic).
The Configurer pattern generates configuration artifacts (e.g., SQL/SOQL, JSON, CSVs) from natural language requirements and can run in reverse to validate an existing configuration against requirements. It is a Level 4 maturity pattern suited for complex product configuration and contract validation.
Knowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.