Agent Design Pattern

How it works

An agent design pattern names a coordination shape, not a model or a library. You choose it from the structure of the task: how the work decomposes, where verification has to live, and how many turns the loop needs before it can commit an action.

A useful pattern fixes three things:

1. Decomposition — whether one agent holds the whole task or a planner splits it into subtasks handed to workers.
2. Control flow — how turns advance: a single perceive-reason-act loop, a plan-then-execute pass, or a produce-then-critique cycle.
3. Termination — what closes the loop: a satisfied goal check, an evaluator's verdict, a step budget, or an operator approval.

A few shapes recur. ReAct interleaves reasoning and tool calls in one loop. Orchestrator-worker has a lead agent decompose and delegate to parallel workers, then merge. Evaluator-optimizer pairs a producer with a critic that iterates until a quality bar is met. Reflection folds the critique back into the same agent's context. These are not exclusive — you compose them, wrapping a ReAct worker inside an orchestrator, or gating an evaluator loop behind an approval step. The pattern is the scaffold you commit to before the model runs, so behavior stays legible when the run gets long.

Why it matters in an agent harness

The pattern you pick decides how much of the system stays controllable. Control lives at the seams between components, so the topology determines where you can insert a permission check, a budget, or a rollback.

A flat, single-loop agent gives you one place to observe and one place to interrupt — cheap, but every failure is entangled with every other. An orchestrator-worker split gives you isolated blast radius per worker and a natural checkpoint at each handoff, at the cost of coordination overhead. An evaluator-optimizer loop makes quality legible — the critic's verdict is an inspectable artifact — but you own a termination condition that can spin.

So the choice is really a choice about failure containment. Where does an error stop? Which step can you replay without redoing the whole run? Which transition can a human gate without stalling the rest? Pick the shape whose seams line up with the guarantees you need, not the one that produces the most autonomous demo. A pattern that hides its transitions hides exactly the points where you would otherwise regain control.

Agent design pattern vs agent framework

The distinction changes what you commit to. A pattern is a shape you can reason about; a framework is code that implements one shape (often silently) and asks you to accept it.

The practical trap: reaching for a framework's default topology instead of choosing a shape deliberately. Name the pattern first, then decide whether a framework's default matches it — or whether its abstraction is hiding the seams you need.

The Rifty take

We optimize for legible seams over minimal code. A pattern earns its place by making control points explicit — where you observe, where you gate, where you roll back — even when a flatter loop would ship faster. We accept coordination cost to buy containment, and we treat any pattern that obscures its own transitions as a liability, because the transitions are precisely where an operator's carried judgment gets to intervene.

Common failure modes

• Pattern chosen by fashion, not task shape. Multi-agent topology on a task one loop would handle adds coordination cost and hides errors.
• Missing termination condition. Evaluator-optimizer and reflection loops iterate forever without an explicit quality bar or step budget.
• Seams with no controls. Handoffs that carry no permission check, budget, or checkpoint waste the containment the topology offered.
• Framework defaults treated as the design. Inheriting a library's topology by accident instead of choosing one on purpose.
• Unbounded context growth. Long orchestrated runs accumulate state until the loop degrades; the pattern needs a compaction or checkpoint strategy.
• Over-decomposition. Splitting a coherent task across agents that then have to re-share context they never should have lost.

Frequently asked questions

How do I choose an agent design pattern?

Choose by task structure, not by feature list. Ask how the work decomposes, where verification must live, and what closes the loop. A single-loop task wants ReAct; parallelizable subtasks want orchestrator-worker; a strict quality bar wants an evaluator-optimizer pair. Match the pattern's seams to the controls you need.

Is an agent design pattern the same as an agent framework?

No. A pattern is a coordination shape you reason about and can reimplement anywhere; a framework is code that implements one shape, often silently, behind its own abstractions. Name the pattern you want first, then decide whether a framework's defaults match it or hide the seams you need to control.

Can I combine multiple agent design patterns?

Yes, composition is normal. You wrap a ReAct worker inside an orchestrator, gate an evaluator-optimizer loop behind an approval step, or fold reflection into a worker's context. The risk is layering topology past the task's real structure, which adds coordination cost and buries failures. Compose only where each layer earns a control point.

Why does the pattern affect controllability?

Control lives at the seams between components, so the topology decides where you can insert a permission check, budget, checkpoint, or rollback. A flat loop gives one interruption point; an orchestrator gives one per handoff. Pick the shape whose transitions line up with the guarantees and interventions your harness requires.

What is the most common agent design pattern mistake?

Adopting a framework's default topology by accident instead of choosing a shape on purpose. The second most common is omitting a termination condition, which lets reflection and evaluator loops iterate indefinitely. Both stem from treating the pattern as something you switch on rather than something you design against the task.