Agentic Design Patterns: A Practitioner’s Catalogue for Production Systems

If you build agents, the problems you face are largely the problems other teams have already faced and solved, and the difference between a team that builds reliable agents and one that keeps hitting the same failures is often whether it knows the patterns. A pattern catalogue is not a substitute for judgment, because applying a pattern where it does not fit is its own failure, and it is a way to bring the accumulated lessons of agent building to bear on a new system rather than rediscovering them. Knowing the patterns, when they apply, and what they cost is what lets a team build on the field’s experience rather than only its own.

Why the same problems recur

Agent projects hit the same problems because agents share a structure that produces the same failure modes, and a team building its first agent encounters failures that are novel to it and familiar to the field. The compounding-error problem appears in every multi-step agent, the non-idempotent retry appears in every agent that takes side-effecting actions, the governance and coordination problems appear in every multi-agent system, and a team meeting each of these for the first time experiences them as surprises, when they are predictable consequences of the structure agents share. The problems recur because the structure recurs, which means the solutions can be catalogued and applied in advance.

The cost of not knowing the patterns is learning each one through the failure it prevents, which is the expensive way to learn. A team that does not know to make side-effecting actions idempotent learns it when a retry double-fires in production, and a team that does not know to bound a retrieval loop learns it when the loop spirals, and each of these lessons, learned through a production incident, could have been applied as a known pattern before the incident. The pattern catalogue is valuable precisely because it lets a team skip the expensive learning, applying the solution to a recurring problem before encountering the problem, which is the difference between building on the field’s accumulated experience and repeating its mistakes. Naming the patterns is what makes that accumulated experience transferable.

The patterns that recur across production agents

The catalogue spans the recurring problems, and the patterns that address them have appeared throughout production agent engineering. For reliability, the pattern of narrowing model discretion and pushing control flow into deterministic code addresses the compounding-error problem, and the pattern of idempotency keys with an action ledger addresses the non-idempotent retry. For control flow, the patterns of sequential, parallel, and orchestrated coordination address the question of how to structure multi-step work, and the supervisor pattern addresses governable multi-agent coordination.

For state and recovery, the pattern of durable externalised state with checkpointing and rollback addresses failure partway through a trajectory. For control and safety, the patterns of bounded action space, least-privilege agency, and approval pauses at consequential actions address the containment of what the agent can do. For evaluation, the patterns of whole-trajectory scoring and capturing failures as eval cases address knowing whether the agent works. Each pattern is a named solution to a recurring problem, and the catalogue’s value is that a team facing any of these problems can reach for the known solution rather than inventing one, which is what turns the field’s accumulated experience into a resource a new project can draw on.

Using patterns well, and the trade-off

A pattern catalogue is a tool for judgment, not a replacement for it, and naming that distinction is what prevents the catalogue from being misapplied. A pattern is a solution to a specific problem under specific conditions, and applying it where the conditions do not hold is a failure, because a pattern used out of its context adds complexity or constraint that the situation does not warrant, the same over-engineering that comes from reaching for agentic complexity a task does not need. The catalogue tells you the solutions that exist and when they apply, and the judgment of whether a given pattern fits a given situation remains with the practitioner, who has to understand not just the pattern but the conditions under which it is the right choice.

The trade-off each pattern carries is part of knowing when to apply it, because every pattern solves its problem at a cost, and applying it means accepting that cost in exchange for the solution. The idempotency pattern costs the engineering of keys and a ledger, the supervisor pattern costs the flexibility of distributed coordination, the approval-pause pattern costs latency at the consequential actions, and knowing a pattern means knowing its cost as well as its benefit, so the decision to apply it is deliberate. A catalogue that presented patterns as free solutions would mislead, and one that presents each pattern with its cost and its conditions lets a team choose which patterns to apply based on what its system actually needs. The discipline is applying the patterns that fit and their costs are worth paying, which requires understanding the patterns deeply enough to judge their fit, and that understanding is what the catalogue supports rather than replaces.

Where it almost broke

We saw a team building an agent that hit, in sequence, several of the well-known agent problems as if each were novel: the compounding errors on its multi-step trajectories, the double-firing from non-idempotent retries, the uncontrolled from an unbounded loop, each discovered through the failure it caused in testing or early operation. The team was capable and was learning the patterns the expensive way, encountering each recurring problem as a surprise and reinventing the solution after the failure, when every one of these problems was known and had a known solution that could have been applied in advance. The cost was time and incidents spent rediscovering what the field already knew.

The correction brought the pattern catalogue to bear. We introduced the team to the patterns that addressed the problems they were hitting, the idempotency pattern for the retries, the bounded-loop pattern for the uncontrolled, the deterministic-control pattern for the compounding errors, and the team began applying the known solutions in advance rather than discovering the need for them through failure. We also emphasised the judgment: which patterns fit their system, what each cost, and where a pattern did not apply. The team’s agent building accelerated and its failures dropped, because it was building on the field’s accumulated experience rather than repeating it. The lesson was that agent problems recur and their solutions are known, and a pattern catalogue is what lets a team apply the solution before the problem rather than after.

Engineer on the field’s experience as well as your own

The reframe that accelerates agent building is recognising that the problems a new agent faces are largely the problems the field has already solved, and a catalogue of agentic design patterns is how a team applies those solutions in advance rather than rediscovering them through failure. The patterns address the recurring problems of production agents, reliability, control flow, state, safety, and evaluation, and each is a named solution with a known cost and known conditions, which lets a team reach for the solution that fits rather than inventing one after the problem has already caused an incident.

The teams that build reliable agents efficiently are the ones that knew the patterns, applied the ones that fit their system in advance, and exercised the judgment of when each pattern applied and what it cost. Agent problems recur because agent structure recurs, and learning each pattern through the failure it prevents is the expensive way to acquire what the field already knows. Drawing on the pattern catalogue, with the judgment to apply each pattern where it fits and pay its cost where it is worth it, is what lets a team build on the accumulated experience of production agent engineering rather than only on its own hard lessons.