Agentic AI Patterns — Part 1 of 3 · Part 2: Where They Break in Production · Part 3: The Maturity Model
“We’ll just use an agent” is not an architecture decision. It’s a deferral of one.
An agent is a loop — a model that observes, reasons, acts, and observes again. But how you structure that loop, where you put human checkpoints, and how many loops you run in parallel determines whether your system is reliable, debuggable, and safe. Pick the wrong pattern and you’ll rebuild it in three months.
This post names the six patterns that cover 95% of production agentic systems, gives you a decision flowchart, and includes a quick-reference table you can bookmark.
The decision tree picks your primary pattern; the others get layered in where a specific step demands it.
The six patterns
1. ReAct (Reason + Act)
What it is: The model alternates between a reasoning step (“Thought”) and an action step (“Action”), observing the result after each action before deciding the next move. The loop continues until the task is complete.
When to use it:
- Single-goal tasks that require dynamic tool selection
- Tasks where the path isn’t known upfront (e.g., “investigate this alert and summarize the root cause”)
- Debugging, research, or exploration workflows
Tradeoffs:
- Simple to implement — reasoning and action are both just model calls
- Unpredictable step count; latency varies with task complexity
- Reasoning traces are visible and debuggable, which is a significant operational advantage
2. Plan-and-Execute
What it is: The model produces a full plan as a first step, then executes each step sequentially (or in parallel). Planning and execution are separate model calls — often with different prompts or even different models.
When to use it:
- Long, multi-step tasks where you need predictable structure upfront
- When the task scope is well-defined and unlikely to change mid-flight
- CI/CD automation, document generation, structured reporting
Tradeoffs:
- Plan is inspectable before execution begins — great for human review gates
- Brittle when early steps produce unexpected results (the plan can become stale)
- Use a small/fast model for planning, a capable model for execution to manage cost
3. Critic / Reflection Loop
What it is: After the main agent produces output, a second model call (the critic) evaluates it against a rubric and returns structured feedback. The original agent revises based on the critique. Iterate until the critic approves or a max-turn limit is hit.
When to use it:
- High-stakes output where quality matters more than latency (incident reports, compliance documents, code reviews)
- Tasks with a clear, enumerable evaluation rubric
- Anywhere you’d otherwise rely on a human to QA before sending
Tradeoffs:
- Doubles (or more) the token cost per task
- Critic and generator can get stuck in loops — always set a max-iteration ceiling
- The critic model doesn’t need to be as capable as the generator; a smaller model with a strict rubric often works well
4. Parallel Fan-out
What it is: The orchestrator breaks a task into N independent subtasks and dispatches them to N agents simultaneously. Results are aggregated (reduced) before the next step.
When to use it:
- Tasks that decompose into independent subtasks (multi-file analysis, competitive research across sources, multi-region health checks)
- Latency-sensitive workflows where you can’t afford sequential steps
- Map-reduce patterns over large inputs
Tradeoffs:
- Significant latency reduction for parallelizable work
- Aggregation logic can be complex — design the reducer before you design the fan-out
- Cost scales linearly with N; set concurrency limits
5. Human-in-the-Loop Gate
What it is: The agent pauses at defined checkpoints and waits for human approval before continuing. The gate can be a Slack message, a UI prompt, a webhook callback, or a queue entry.
When to use it:
- Actions with irreversible consequences (database writes, infrastructure changes, customer-facing communications)
- Regulated or safety-critical environments where audit requires human sign-off
- Trust-building phases when deploying autonomous agents to new workflows
Tradeoffs:
- Breaks the autonomous loop — latency becomes human-dependent
- Approval fatigue is real: too many gates and humans start rubber-stamping
- Gate placement is a design decision: gate too early and you lose the value of automation; gate too late and you lose safety
6. Supervisor / Orchestrator
What it is: A supervisor agent delegates to specialized sub-agents, each scoped to a specific capability domain. The supervisor routes tasks, aggregates results, and handles errors from sub-agents.
When to use it:
- Multi-capability workflows that span domains (e.g., “resolve this incident” requires reading logs, querying a runbook, posting to Slack, and updating a ticket)
- Systems where you want to swap or upgrade individual sub-agents without rebuilding the orchestration layer
- Production multi-agent architectures at scale
Tradeoffs:
- Most powerful pattern, highest implementation complexity
- Supervisor prompt quality is critical — garbage routing produces garbage results
- Requires robust error handling: what happens when a sub-agent fails, times out, or returns unexpected output?
Decision flowchart
Is the task path known upfront?
├─ YES → Plan-and-Execute
└─ NO → Does the task span multiple capability domains?
├─ YES → Supervisor / Orchestrator
└─ NO → Can the task be decomposed into parallel subtasks?
├─ YES → Parallel Fan-out
└─ NO → Does the output require quality validation?
├─ YES → Critic / Reflection Loop
└─ NO → Does the task touch irreversible actions?
├─ YES → Human-in-the-Loop Gate
└─ NO → ReActIn practice, production systems combine patterns. A Supervisor orchestrates sub-agents; individual sub-agents use ReAct internally; high-stakes tool calls have a Human-in-the-Loop gate; final output runs through a Critic. The decision tree picks your primary pattern — the others get added where the specific step demands it.
Quick-reference table
| Pattern | Best for | Complexity | Latency | Cost multiplier |
|---|---|---|---|---|
| ReAct | Dynamic exploration | Low | Variable | 1× |
| Plan-and-Execute | Structured multi-step tasks | Medium | Predictable | 1.5× |
| Critic / Reflection | Quality-critical output | Low-Med | Higher | 2–3× |
| Parallel Fan-out | Independent subtasks | Medium | Lower | N× |
| Human-in-the-Loop | Irreversible / regulated actions | Low | Human-dependent | 1× |
| Supervisor | Multi-domain workflows | High | Variable | 2–5× |
Where to go next
This post names the patterns. Part 2 covers where each one breaks in production — the failure modes your demo will never surface. Part 3 maps these patterns onto a five-level maturity model so you can see where your team sits and what the next level actually requires.
Related posts: