Agentic Design Patterns for Multi-Step Workflow Orchestration

A prompt chain is not an agent. A substantial portion of enterprise "AI agent" deployments are, upon inspection, prompt chains wrapped in marketing language, and the distinction is not semantic. An agentic workflow involves a reasoning core that selects its own actions, retains context across multiple turns, and can revise its plan mid-execution in response to new evidence. A chain executes a fixed sequence. An agent navigates — and if a prompt chain is a train running on fixed rails, an agent is the driver who reads the road.

Production agents are built from six components, and skipping any one of them is why demos fail to survive contact with real traffic. The language model handles reasoning. A memory system manages three distinct functions: working memory for the current task, episodic memory for past interactions, and procedural memory for learned routines. A tool and plugin layer lets the agent act rather than simply generate text about acting. A planner decomposes high-level goals into executable steps. An orchestration runtime manages state, retries, and handoffs. Finally, an observability and evaluation layer captures every action, scores outputs, and enforces guardrails. That sixth component is the one most commonly cut in early builds. It is also the one that determines whether the system is governable at all.

Agentic design patterns are reusable structures operating across these six components. They are not academic abstractions; they are blueprints for how reasoning, action, and coordination get sequenced in systems that are actually running. The patterns fall into three families: cognitive and reasoning patterns that govern how a single agent thinks and self-corrects, execution patterns that structure how a single agent sequences actions over time, and orchestration patterns that determine how multiple agents divide labor and coordinate results. Each family produces a different footprint of decisions and handoffs, and each requires different monitoring to be meaningfully auditable. Conflating them produces systems that are miserable to debug and nearly impossible to govern.

ReAct: The Interleaved Loop That Grounds Agent Reasoning in Real-World Evidence

ReAct, formalized by Yao et al. (2022), is the foundational cognitive pattern for agents that need to act on current external information rather than on what was baked into training weights. The loop is straightforward: think, act, observe, repeat. Before each action, the agent produces a reasoning trace. After each action, it reads the observation and updates its plan.

The practical consequence of this structure is that agents built on ReAct can call APIs, query live databases, execute code, and interact with third-party services, grounding their decisions in evidence rather than supposition. On interactive decision-making benchmarks including ALFWorld and WebShop, Yao et al. (2022) reported that ReAct outperformed both imitation learning and reinforcement learning baselines. The paper attributes this to reasoning structure, not additional training.

The production value of the reasoning trace extends well beyond benchmark performance. Every action is preceded by a logged rationale. You can reconstruct not just what the agent did, but why it decided to do it at that moment. This is the structural prerequisite for a meaningful audit log. Without the trace, a tool call is opaque; with it, the call is defensible, correctable, and explicable to a compliance team that was not in the room.

The failure mode here is subtle enough that it catches people who know better. If the agent misreads an observation, the error propagates directly into the next reasoning step, and the loop amplifies a bad premise as readily as a good one — garbage in, garbage compounded. A secondary failure: raw error logs fed back into the reasoning scratchpad degrade model coherence downstream. Effective implementations summarize observations before they re-enter the loop. Context hygiene is an active discipline, not a default.

Reflection: How Agents Evaluate and Revise Their Own Outputs Before Committing

Reflection is the pattern where an agent pauses, critiques its own output against a quality criterion, and iterates until a threshold is met. The performance numbers are striking. Shinn et al. (2023) reported that on HumanEval, a Python coding benchmark, a single-attempt GPT-3.5 baseline scores 67.0%, while three-attempt Reflexion reaches 91.0% from the same base model. Madaan et al. (2023) reported roughly 20-percentage-point improvements over single-pass baselines on dialogue and mathematical reasoning tasks using self-refinement methods. No weight updates. No fine-tuning. The gains come entirely from structured critique and revision, which is either elegant or alarming depending on how you feel about the amount of performance left on the table by single-pass inference.

The failure mode is under-discussed and genuinely hazardous. Reflection amplifies errors when the self-evaluator is wrong. An incorrect diagnosis of a flaw compounds across iterations: the agent revises something that was working correctly, or doubles down on a flawed approach with escalating confidence. Reflection without an external check is a closed loop, and closed loops drift. This surfaces in production when agents are given vague quality criteria and left to define "good" for themselves.

Two refinements address this problem directly. ThinkPRM, introduced by Lightman et al. (2025), operates as a thinking verifier, generating a verification chain-of-thought for each reasoning step and achieving strong accuracy with substantially fewer training labels than discriminative verification approaches. AgentPRM extends process rewards to tool-using agents, evaluating not just reasoning steps but tool selection and parameter appropriateness. Both approaches introduce an external signal into what would otherwise be a fully internal judgment.

The production implication is blunt: reflection works when the quality criterion is externally specified, whether that is a rubric, a test suite, a schema, or a set of business rules written down before the workflow executed. An agent critiquing its own work against its own standard is a governance problem waiting to surface.

Plan-and-Execute and Tree of Thoughts: Structuring Longer-Horizon Reasoning Before Action Begins

Plan-and-Execute separates strategy from execution. The agent composes the full plan first, then runs each step in sequence. This suits long, multi-stage workflows where the task is sufficiently well-defined to plan upfront: a structured research report, a multi-step data transformation pipeline, a compliance review with known stages.

A theoretically sound plan can still miss a dependency, and it does so at the worst possible moment. A plan validation step before execution begins, where a second LLM call reviews the proposed plan against known constraints, catches structural errors before they become expensive runtime failures. Without explicit checkpointing between steps, a mid-plan failure restarts the entire sequence. Resumability is a prerequisite for any workflow where individual steps are long-running or involve external API calls.

Tree of Thoughts, introduced by Yao et al. (2023), takes a different approach: it explores multiple reasoning branches in parallel and self-evaluates each before committing to a path. It suits tasks where the right path is genuinely ambiguous, including mathematical problem-solving, strategic planning, and open-ended synthesis. The cost profile is materially different. Parallel branch exploration multiplies token consumption and latency relative to linear patterns, and most production systems use Tree of Thoughts selectively at specific decision points where ambiguity is high, not as a default architecture.

These patterns are not mutually exclusive, and mixing them correctly is where most of the architectural judgment lives. ReAct combined with Reflection handles tasks where the path is reasonably clear but execution errors are likely. Plan-and-Execute combined with Tree of Thoughts serves long-horizon tasks where upfront strategy and branch exploration both add value. The right combination depends on the task's time horizon, error tolerance, and cost envelope. Where single-agent patterns stop working is when subtasks are genuinely independent, require different expertise, or must run in parallel. That boundary is where orchestration patterns become necessary.

Tool Use as a Pattern in Its Own Right, Not Just a Feature of Other Patterns

Tool use is routinely framed as a capability that other patterns employ. It is more accurately understood as a pattern with its own architectural requirements and failure modes, and treating it as incidental is a reliable way to acquire problems that are hard to trace.

The structure: the agent dynamically selects from a registry of external capabilities, including web search, databases, code interpreters, and enterprise APIs, based on what the task requires at each step. Consider a financial report generation workflow where the agent queries a database for current figures, invokes a code interpreter to run calculations, and calls a formatting API to assemble the output. Each selection is a discrete reasoning decision that can be made well or poorly, and whether the tool call technically succeeded tells you almost nothing about whether the right tool was chosen. A successful wrong turn is still a wrong turn.

One architectural direction discussed by NVIDIA and others is a hybrid model where LLMs handle high-level planning while smaller, faster models handle scalable execution of individual tool calls. In this framing, the primary challenge shifts from invoking any single tool successfully to reliably coordinating multiple tools across long task horizons, which is a more interesting problem and a harder one.

Two failure modes dominate in production. The first: failed tool calls that dump raw error logs into the context window degrade model coherence on subsequent steps, the same observation-summarization problem that surfaces in ReAct. The second is governance-adjacent and gets less attention than it deserves. Agents inherit the access permissions of the human or service account they operate under, and they exercise that access at machine speed, without the friction that leads a human to pause before clicking something irreversible. Static permission models are insufficient for agentic tool use. Runtime controls specifying which tools an agent can call, under what conditions, at what rate, and with what approval thresholds are the structural equivalent of that friction.

Orchestrator-Worker: The Coordination Pattern Most Production Multi-Agent Systems Start With

Orchestrator-worker is the pattern most production multi-agent systems default to, and the reason is legibility. One orchestrator agent receives the task, decomposes it into subtasks, delegates each to a specialist worker agent, and assembles the results. The structure mirrors how effective enterprise teams actually operate: specialists under a coordinator, not generalists doing everything badly.

The cost architecture is a practical advantage that often gets overlooked in architectural discussions. The orchestrator runs on a more capable model for complex decomposition and synthesis; workers use cheaper, task-specific models for execution. A failure in a worker agent is isolated and attributable; you know which subtask failed and which agent was responsible. Tightly coupled architectures behave differently: failures cascade before they surface and debugging becomes archaeological.

Microsoft Azure's modular agent framing articulates this clearly: responsibilities stay legible as the system grows when each component is scoped to a defined function under orchestrator coordination.

As worker count grows beyond five to eight agents, coordination overhead grows with it. The appropriate response is hierarchical orchestration, a middle tier of sub-orchestrators managing agent subgroups, preserving the legibility of the two-level structure without requiring the top-level orchestrator to track every worker directly. When subtasks are genuinely independent and latency matters, fan-out dispatch replaces sequential delegation.

The governance property this pattern provides is underappreciated: because every subtask routes through the orchestrator, every delegation decision is a logged event. The orchestrator's decision log is the audit trail for the entire workflow. This is not incidental to the pattern; it is the reason orchestrator-worker is the correct starting point for any organization that needs to answer "what did the system decide, and why" at a later date.

Sequential Pipelines and Parallel Fan-Out: Choosing the Flow Topology That Matches the Task

Topology is a function of dependency structure, not preference. Treating the choice between sequential and parallel flow as a stylistic decision is how production workflows acquire failure modes that are expensive to diagnose months later, usually by someone who was not there when the architecture was chosen.

A sequential pipeline passes each stage's output to the next as input. It is appropriate when each step genuinely depends on the previous one: document drafting followed by factual review followed by formatting. The workflow's state at any point is simply the output of the last completed stage, which makes sequential pipelines comparatively straightforward to reason about and debug. The failure characteristic follows: if one stage stalls or produces degraded output, every downstream stage inherits the problem. Checkpointing between stages is not optional in production; it is the mechanism that prevents a single failure from requiring full re-execution of an expensive workflow.

Parallel fan-out dispatches independent subtasks simultaneously and aggregates the results. It is the right topology when tasks share no dependencies, analyzing five market segments simultaneously rather than sequentially, for instance. The latency advantage is substantial when subtasks are roughly equal in duration; one slow subtask becomes the bottleneck and the aggregation step cannot proceed until all branches complete. The aggregation logic itself is a non-trivial design decision. How conflicting outputs from parallel agents are resolved needs to be explicit, specified before the workflow runs, and testable. Implicit aggregation logic is a governance gap that will eventually produce a result nobody can explain.

Most real production workflows are hybrids: a sequential backbone with parallel segments at the steps where independence exists. Mapping the task's dependency graph before selecting a topology is the correct order of operations, not the reverse.

The audit implications of each topology differ in ways that matter at inspection time. Sequential pipelines produce a linear chain of handoffs that is straightforward to inspect. Fan-out produces a branching log that must be re-joined at aggregation. Both are auditable; each requires different monitoring tooling to inspect correctly, and standing up that tooling after the fact is considerably more expensive than designing for it upfront.

Predictability and Auditability Are Not Features You Add Later

Predictability and auditability are not properties of individual agents. They are properties of the system's structure, and they must be designed in from the beginning. Retrofitting them into a production workflow is significantly more costly than building for them initially, and in regulated environments, retrofitting is often simply not possible. Trying to bolt auditability onto a running agentic system is like installing smoke detectors in a building that is already on fire.

Across every pattern discussed here, the common requirements resolve to four structural commitments. First, every decision must produce a structured log entry at the moment it is made: the reasoning trace in ReAct, the delegation event in orchestrator-worker, the branch selection in Tree of Thoughts, the tool call and its parameters in any tool-use pattern. Logs generated after the fact from aggregate state are reconstructions. They are not audit trails.

Second, every quality criterion must be externally specified. Reflection and self-evaluation patterns drift when the evaluator defines its own standards. The criterion must exist outside the agent's reasoning loop, whether as a schema, a test suite, a rubric, or a business rule that someone wrote down before the workflow ran.

Third, failure must be isolated and attributable. Tightly coupled architectures where a failure in one component propagates silently through the rest are not auditable; they are opaque. Orchestrator-worker and sequential pipelines both provide natural isolation boundaries. Maintaining those boundaries under performance pressure requires active architectural discipline, because the path of least resistance is usually to couple things that should remain separate.

Fourth, permissions must be runtime-controlled rather than statically granted. The governance gap in tool-use patterns is that agents exercise access automatically, at scale, without the friction that human workflows use as an informal control. Removing that friction without replacing it with explicit runtime controls is not an efficiency gain. It is a liability.

Gartner projects more than 40% of agentic AI projects will be canceled by 2027, attributing the attrition to structural failure rather than model quality. The inverse is also true: the projects that survive will not survive because they used better models. They will survive because the teams that built them treated architecture as the primary variable, not an afterthought.