How it works
A design pattern is a name attached to a recurring shape. Someone solves the same structural problem enough times—an agent that plans then acts, a critic that revises a draft, a coordinator that fans work out to workers—and the shape gets a name so the next engineer doesn't rediscover it from scratch. Agentic design patterns apply that idea to systems built around a stochastic model.
A pattern usually carries four things:
- A problem: the recurring situation it addresses ("the model commits to a bad plan and never revisits it").
- A structure: the arrangement of loops, roles, and control points that responds to it.
- A set of forces: the tradeoffs it balances—latency against reliability, autonomy against oversight, cost against coverage.
- Consequences: what you gain and what you now have to manage instead.
What a pattern is not is a library, an API, or a score. It is a description you can implement many ways. react names a reason-act-observe loop; reflection names a generate-critique-revise pass; orchestrator-worker names task decomposition and fan-out; evaluator-optimizer names a scored refinement loop. None of these tells you which framework to install. They tell you what you are building and what it will cost you.
Why it matters in an agent harness
A harness is the controllable, reversible structure around an agent. Patterns matter because they make that structure legible before you commit code to it.
When a design is named, its control surface is predictable. If a piece of the system is an evaluator-optimizer, you already know it needs a defined scorer, an iteration budget, and a stopping rule—otherwise it loops forever. If a component is an orchestrator-worker, you know coordination cost and partial-failure handling are the risks, not raw model quality. The pattern tells you where the failure modes live, which is exactly what a harness has to contain.
Naming also makes evaluation tractable. You evaluate a trajectory differently depending on its shape: a reflection loop is judged on whether revision actually improved the output, an orchestrator on whether decomposition was sound. Shared vocabulary lets a team say "this is the wrong pattern for this problem" during design review instead of discovering it in production. And when something breaks, a named structure gives you a rollback and checkpoint story that matches the loop, rather than a bespoke recovery path per feature.
The quiet benefit is restraint. Patterns make it obvious when you are reaching for autonomy you don't need—when a single tool call would do and you've reached for a multi-agent system out of habit.
Patterns vs frameworks
The distinction that changes decisions is pattern versus framework. Conflating them is how teams end up owned by their tooling.
| Design pattern | Framework | |
|---|---|---|
| What it is | A named structure and its tradeoffs | An implementation with an API |
| What it gives you | Shared vocabulary, legibility | Code, defaults, abstractions |
| Lock-in | None—you can reimplement it | Real—you inherit its opinions |
| When it's wrong | You chose the wrong shape | The abstraction leaks under load |
A pattern survives your framework choice. You can describe a system as "orchestrator with reflecting workers" and implement it in three different stacks. Treat a framework's feature list as the canonical pattern catalog and you inherit its blind spots—the patterns it can't express become the ones you never consider.
The Rifty take
We treat patterns as vocabulary for design review, not as a menu to shop from. The value is in naming the shape early so the control points—budgets, stopping rules, checkpoints, permission boundaries—are designed in, not bolted on. We optimize for the smallest pattern that solves the problem: a bare loop over an orchestrated agent team, every time the simpler shape holds. A named pattern you can't observe or roll back is decoration.
Common failure modes
- Cargo-culting the shape: adopting a multi-agent orchestration because it's fashionable when a single reasoned tool call would be more reliable and cheaper to operate.
- Treating names as guarantees: assuming "we used reflection" means the output improved. A pattern is a structure, not a result—verify the revision actually helped.
- Framework-as-catalog: letting your library's feature set define which patterns exist, so you never reach for a shape it can't express.
- Unbounded loops: implementing an evaluator-optimizer or react loop without an iteration budget and a stopping rule, so it burns tokens without converging.
- No control points: naming the structure but leaving no checkpoint, rollback path, or permission boundary at the seams where the pattern actually fails.
- Pattern soup: nesting three patterns deep because each was locally reasonable, until no one can trace a single trajectory end to end.
Frequently asked questions
How are agentic design patterns different from an agent framework?
A pattern is a named structure and its tradeoffs; a framework is an implementation with an API. Patterns describe what you're building and survive your tooling choice—you can reimplement them anywhere. Frameworks give you code and defaults but also opinions and lock-in. Use patterns to reason, frameworks to ship.
What are common agentic design patterns?
The recurring ones are ReAct (reason-act-observe loops), reflection (generate-critique-revise), orchestrator-worker (decompose and fan out), and evaluator-optimizer (scored refinement loops). Each names a structure and its failure modes—looping, coordination cost, unbounded revision—rather than a specific library or a benchmark to beat.
Do patterns guarantee a better agent?
No. A pattern names a structure, not a result. Using reflection doesn't mean the revision improved anything; using an orchestrator doesn't mean decomposition was sound. Patterns make design legible and failure modes predictable, but you still have to evaluate the actual trajectory and verify the outcome empirically.
When should I avoid reaching for a multi-agent pattern?
Whenever a simpler shape holds. If one reasoned tool call or a single bounded loop solves the problem, an orchestrated agent team adds coordination cost, more failure surface, and harder observability for no reliability gain. Choose the smallest pattern that works and add structure only when the problem forces it.
How do patterns relate to building a harness around an agent?
A named pattern tells you where its control points belong—iteration budgets, stopping rules, checkpoints, permission boundaries, rollback paths. Because the failure modes are known per shape, the harness that contains them can be designed up front rather than discovered in production. An unobservable, un-rollback-able pattern is decoration.