Agentic Design Patterns

What Is Agentic Design Patterns?

Agentic design patterns are reusable structures for building AI agent systems. The core four are reflection, tool use, planning, and multi-agent collaboration. Each pattern describes a proven way to arrange model calls, tools, and control flow, and each trades off autonomy, cost, latency, and reliability in a different, predictable way.

Key Takeaways

• The four foundational patterns are reflection (the agent critiques and revises its own output), tool use (the agent calls external functions), planning (the agent decomposes a goal before acting), and multi-agent collaboration (specialized agents divide the work).
• Patterns compose. A production system typically stacks several: a planner that delegates to tool-using workers whose output passes through a reflection step.
• Every pattern you add costs tokens and latency. Reflection can double spend on a task, so it belongs where quality matters more than speed.
• Patterns are architecture, not framework features. You can implement all of them with plain API calls, and knowing them helps you evaluate what a framework actually provides.

How It Works

Reflection wraps generation in self-review. The agent produces a draft, then a second pass, sometimes with a different prompt or a different model acting as LLM judge, critiques it against explicit criteria and triggers a revision. It is the cheapest reliability upgrade available because it needs no new infrastructure, only another model call. The payoff is measurable: the Reflexion method, which has the agent reflect verbally on its failures, reached 91% pass@1 on HumanEval in 2023 and beat the previous GPT-4 state of the art of 80% [1].

Tool use extends the model beyond text prediction. Through tool calling, the agent reads files, queries databases, hits APIs, and runs code, grounding its decisions in real system state instead of guesses. Planning has the agent write out a task decomposition before touching anything, which makes long tasks tractable and gives humans a plan to approve up front. In coding agents this often appears as a plan mode that must be accepted before edits begin, which pairs naturally with spec driven development.

Multi-agent collaboration splits work across agents with distinct roles and separate context windows. An orchestrator decomposes the goal and routes subtasks to workers, or peers hand work to each other in a pipeline. This is the heaviest pattern: it multiplies cost, introduces coordination failures, and demands agent orchestration logic, so it earns its keep only when a task genuinely exceeds what one agent context can hold.

Example

A team building an automated code-review service ships patterns incrementally. Version one is a single model call that comments on a diff; reviews are shallow. Version two adds tool use so the agent can open neighboring files and run the test suite, and comment quality jumps because the agent sees real context. Version three adds reflection: a second pass filters the draft comments against a checklist of false-positive patterns, cutting noisy nitpicks roughly in half in their internal evals. Only at version four, when they want security and performance reviewed by different specialists, do they adopt multi-agent collaboration with an orchestrator merging three reviewers' findings. Each pattern was added to solve a measured problem.

What People Get Wrong

The recurring mistake is starting with the most elaborate pattern. Teams read about multi-agent systems and design a crew of six named agents for a task a single tool-using agent handles fine. Every agent boundary adds a place where context gets lost, results get miscommunicated, and costs multiply. The patterns form a ladder: exhaust the single-agent rungs, tool use, then planning, then reflection, and reach for collaboration only when one context window demonstrably cannot hold the job.

FAQ

Where do these four patterns come from? They crystallized out of practice and were popularized around 2024, notably in Andrew Ng's writing on agentic workflows. Ng's numbers made the case: wrapping GPT-3.5 in an agentic loop lifted HumanEval accuracy from 48.1% zero-shot to as much as 95.1%, a bigger jump than upgrading the base model to GPT-4, which scored 67.0% [2]. The taxonomy stuck because it maps cleanly onto what production systems actually do, and later additions like memory and routing slot in as refinements rather than replacements.

Is ReAct one of the agentic design patterns? A ReAct agent is best understood as a concrete realization of the tool use pattern: it interleaves a reasoning step with each action. In the original 2022 paper by Yao et al., ReAct beat imitation- and reinforcement-learning baselines by 34 and 10 absolute points on the ALFWorld and WebShop benchmarks using only one or two in-context examples [3]. Most modern tool-calling agent loops are descendants of it.

Do I need a framework to use these patterns? No. Each pattern is a control-flow idea you can write in a few dozen lines around a model API. Frameworks package the patterns with tracing and state management, which helps at scale, but choosing the right pattern for the task is the part that determines success.

Sources

1. Shinn et al. (arXiv). "Reflexion achieves 91% pass@1 on HumanEval, beating the prior GPT-4 state of the art of 80%." https://arxiv.org/abs/2303.11366. Accessed August 2026.
2. Andrew Ng, DeepLearning.AI (The Batch). "GPT-3.5 in an agentic loop lifts HumanEval accuracy from 48.1% to up to 95.1%, versus 67.0% for zero-shot GPT-4." https://www.deeplearning.ai/the-batch/how-agents-can-improve-llm-performance/. Accessed August 2026.
3. Yao et al. (arXiv). "ReAct beats imitation- and reinforcement-learning baselines by 34% and 10% absolute success rate on ALFWorld and WebShop." https://arxiv.org/abs/2210.03629. Accessed August 2026.