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 guidePlan-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...
Magentic Orchestration & Task Ledgers
For highly open-ended problems, Azure architecture recommends "Magentic Orchestration" (as seen in the Magentic-One framework). Instead of a fixed plan, a Manager Agent maintains two distinct records: a Task Ledger (the high-level project plan and established facts) and a Progress Ledger (the immediate step-by-step history). As sub-tasks are executed, these ledgers are updated, and the manager may dynamically re-order or delete remaining steps based on new insights.
Azure Magentic Orchestration Architecture
Loading diagram...
This "Ledger" approach is like a project manager's whiteboard that updates itself. If a research agent finds that a chosen path is a dead end, the Manager Agent wipes the "to-do" list in the Task Ledger and writes a new strategy based on the new information, preventing the system from getting stuck in a loop.
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 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.