3. Agentic RAG (Retrieval-Augmented Generation with Agent Control)

[Common Pattern]

An important distinction: RAG itself is not an agentic pattern. Classic RAG is a retrieval pipeline — a linear, static sequence of query → embed → retrieve top-k chunks → stuff into prompt → generate. It has no decision-making, no loops, no autonomy. It's infrastructure, not agency.

What is an agentic pattern is Agentic RAG — where the LLM takes control of the retrieval workflow. Instead of passively consuming whatever chunks a vector search returns, the agent decides when to retrieve, what to search for, whether the results are sufficient, and whether to re-retrieve with a refined query. The retrieval becomes a control loop: retrieve, reason, evaluate, decide to retrieve again or stop.

The analogy from practice: classic RAG is like running one database query and writing your report from whatever comes back. Agentic RAG is a debug loop — you query, inspect the evidence, notice what's missing, refine the query or check a second source, and repeat until you're confident or you hit a cost budget and escalate.

The maturity curve: Naive RAG plateaus quickly on complex queries — precision drops off as questions require synthesizing across multiple sources. Production systems in 2025-2026 have moved to Adaptive RAG, where a classifier routes each query to the appropriate retrieval strategy — direct answer from parametric knowledge for simple factual questions, single-hop retrieval for document lookups, multi-hop retrieval with query decomposition for complex reasoning. The insight: not every question deserves the same retrieval investment, and the agent should be the one making that call.

4. Human-in-the-Loop (HITL)

[Core Pattern]

The agent escalates to a human when confidence is low, stakes are high, or the task crosses a predefined boundary. This isn't a fallback — it's a first-class design pattern.

The design spectrum: HITL exists on a gradient, not as a binary switch. The levels, in increasing order of agent autonomy: observe-only (agent watches, human acts), recommend-with-approval (agent proposes, human approves), execute-with-logging (agent acts, human audits after the fact), and fully autonomous (agent acts, no human review). Most production systems should operate at level two or three, with level four reserved for low-risk, high-volume tasks.

Why it's a pattern, not a compromise: HITL isn't an admission that the AI isn't good enough. It's a recognition that some decisions carry consequences that demand human judgment — legal liability, ethical ambiguity, irreversible actions. The pattern defines where in the workflow the human gate sits, what information the agent surfaces to support the human's decision, and how the human's input flows back into the agent's state.

5. Workflow Orchestration and State Machines

[Core Pattern]

Not every agentic system needs open-ended reasoning. Many production use cases are better served by a deterministic workflow engine that uses AI at specific nodes. The workflow itself — the sequence of steps, the branching logic, the retry policies — is defined as a state machine or a directed acyclic graph (DAG). The AI model is invoked at specific nodes for specific tasks: classification, summarization, extraction, generation.

When to use it: When the business process is well-understood and the steps are known in advance. Think: insurance claims processing, invoice reconciliation, support ticket triage.

Why this pattern wins in enterprise: It gives you the best of both worlds. The workflow is deterministic, auditable, and testable. The AI nodes handle the tasks that are hard to code with rules — understanding natural language, extracting entities from unstructured documents, generating human-readable summaries. You get the flexibility of AI without surrendering control of the process.

The implementation: Frameworks like LangGraph, Temporal, and even traditional BPM engines (Camunda, SAP Build Process Automation) can serve as the orchestration layer. The key design decision is granularity: how much reasoning do you delegate to the model at each node, and how much do you keep in deterministic code?

6. Tool-Use Routing

[Core Pattern]

The agent acts primarily as an intelligent dispatcher. It receives a request, selects the right tool (or sequence of tools), formats the inputs, and returns the combined result. The intelligence is in the selection, not in multi-step reasoning.

When to use it: When you have a well-defined set of capabilities (APIs, databases, calculators) and the problem is knowing which one to invoke. Think: a customer support agent routing between order lookup, refund processing, and FAQ retrieval.

Why it works: It minimizes the surface area of stochastic behavior. The tools themselves are deterministic; only the routing decision is probabilistic.

7. Multi-Agent Orchestration

[Specialized Pattern]

Multiple specialized agents collaborate, each responsible for a domain. A coordinator agent delegates tasks, collects results, and synthesizes a final output. Think of it as microservices, but the services are language models with different system prompts and tool sets.

When to use it: Complex workflows that span domains — a research agent that delegates to a search agent, a summarizer, and a fact-checker.

The risk: Compounding variance. If one agent introduces variability, several agents interacting amplify it across the chain. The math is unforgiving: if each step in a five-step chain is 95% reliable, end-to-end reliability is only about 77% (0.95⁵). At 90% per step, you're down to 59%. You need strong contracts between agents: structured outputs, schema validation, and clear handoff protocols.

8. Reflection and Self-Correction

[Specialized Pattern]

The agent reviews its own output, critiques it, and iterates. This can be a single model re-reading its work, or a separate “critic” model evaluating the “actor.”

When to use it: Code generation, writing, analysis — any task where quality improves with revision. The pattern works because language models are often better at evaluating output than generating it on the first attempt.

The subtlety: Reflection can degrade results if the critic is miscalibrated. A model might “correct” a right answer into a wrong one. The purpose of reflection isn't intelligence — it's risk reduction. Knowing when to stop reflecting is itself a design decision.

9. Memory-Augmented Agents

[Specialized Pattern]

The agent maintains persistent memory across interactions — episodic memory (what happened in past conversations), semantic memory (facts about the user or domain), and working memory (context for the current task). Memory transforms an agent from stateless to stateful.

When to use it: Long-running assistants, personalized workflows, any scenario where context accumulates over time.

The design challenge: Memory curation. Not everything should be remembered. Stale facts, contradicted preferences, and irrelevant details create noise. You need eviction policies, conflict resolution, and relevance scoring — all problems that traditional databases solved decades ago, now complicated by the fuzziness of natural language.

10. Prompt Chaining (Sequential Pipeline)

[Core Pattern]

The simplest pattern of all — and the one every major framework lists first. You decompose a task into a fixed sequence of LLM calls, where each step's output feeds the next: draft → critique → revise, or extract → classify → summarize. The defining trait is that you hard-code the sequence in advance; the model doesn't decide the order. Optional validation gates sit between steps to catch failures early before they propagate.

When to use it: Whenever a task has clear, stable sub-steps that always run in the same order. If you can write the steps on a whiteboard before the agent runs, this is your pattern. It's the highest-reliability, lowest-cost option because almost nothing is left to the model's discretion except the content of each step.

Why it's where you start: Though it's last in this list, Prompt Chaining is the first pattern you should reach for. Anthropic, OpenAI, Microsoft, and Google all introduce sequential chaining before anything more autonomous, for the same reason: most “agent” problems are actually fixed pipelines in disguise. Reach for a dynamic planner or a multi-agent swarm only after a simple chain demonstrably falls short. The distinction from Plan-then-Execute is exactly this — there, the model generates the plan; here, you did, at design time.

What the Major Players Call These Patterns

You won't find the names above used consistently across the industry. Each major vendor has published its own framework with its own vocabulary — but underneath, they're describing the same handful of control-flow shapes. If you've read Anthropic's “Building Effective Agents,” OpenAI's “Practical Guide to Building Agents,” Microsoft's Azure orchestration patterns, or Google's ADK docs, this table maps their terms back to the patterns in this post.

This post Anthropic (Building Effective Agents) OpenAI (Agents SDK) Microsoft (Azure / Copilot Studio) Google (ADK / Vertex) LangGraph