Pattern Catalog and Selection Framework

Scope: This release defines a shared architecture vocabulary and review framework. It does not certify products, implementations, or organizational readiness.

The white paper defines pattern problems, classifications, mechanisms, applicability, failure modes, and verification criteria. The blue-book case reports record how combinations of patterns behave under named enterprise constraints.

The catalog uses coordinates rather than a flat list. A coordinate identifies both the cognitive function under pressure and the topology that carries control. This makes architecture choices and failure reports comparable across systems.

Why agents need a new set of design patterns

GoF patterns handle collaboration between objects; distributed-systems patterns handle services, networks, storage, and failure. Agent systems add a new kind of actor: a model that makes judgments under incomplete information and calls tools that affect the outside world. In traditional software, control flow is decided mostly by code; in agent systems, part of the control flow passes through model judgment.

A user says one sentence, and the model has to decide whether it's small talk, a query, analysis, execution, or something needing human review. A tool returns a result, and the model has to decide whether the evidence is enough. A long task reaches the middle, and the model has to decide whether to continue, roll back, re-gather evidence, or stop and ask a human. If these judgments stay only in natural language, the system quickly loses control. Agent design patterns put those judgments back into engineering structure — routing, state, evidence, permissions, logs, rollback, and evaluation.

Two axes

Cognitive function (rows) answers what kind of work the agent is doing — seven: Perception, Memory, Reasoning, Action, Reflection, Collaboration, Governance.

Execution topology (columns) answers what shape the work takes — six.

The two axes cross into a 7 × 6 = 42-cell matrix. 28 cells hold named patterns — some borrowed from prior literature (RAG, chain-of-thought, plan-and-execute), some named here for the first time for previously nameless cells (context triage, failure journals, observability). The remaining 14 cells are deliberately empty: industry gaps and the frontier of future research.

The same matrix in text, for search and citation.

The matrix is left intentionally unfilled. Empty cells are a reminder not to invent immature patterns for the sake of symmetry. M2 RAG spans two cells — naive RAG is a query-once linear pipeline (Chain), Agentic RAG is query-evaluate-rewrite-query iteration (Loop). One pattern growing from Chain into Loop with engineering maturity shows this matrix is descriptive, not either/or.

Five engineering contracts

When the seven functions go to production, design five contracts explicitly for every agent. The stability of an agent system usually comes not from a bigger model but from whether these five contracts align model judgment with engineering state.

• Context Contract — what enters context, what is held as a handle, what is retrieved lazily, what is discarded (Perception).
• Evidence Contract — every piece of evidence carries source, version, scope, citation, provenance. RAG handles business evidence; SessionState handles mechanical ground truth like employee_id and amount (Memory).
• Decision Contract — how model output becomes a structured RouteDecision / PlanDecision rather than a paragraph of natural language (Reasoning).
• Action Contract — tool metadata, parameter provenance, permissions, approval, human review, and rollback rules (Action and Governance).
• Trace Contract — every LLM call, tool call, handoff, approval, and state update threaded onto one trace id (Governance).

White-paper catalog · 28 core + 6 extensions and candidates = 34

The 28 core patterns occupy the reviewed matrix. Six additional specifications cover extension mechanisms or emerging structures: M5 Procedural Memory, R5 Talker-Reasoner, A5 Minimal Tool Set, C5 Sub-Agent Isolation, G5 Hooks Pipeline, and C6 Choreography. C6 remains a candidate topology extension pending evidence across more than the collaboration function. Extension entries are marked ext.

Every specification follows the same review structure: problem, classification, solution and mechanics, applicability, known failure modes, verification metrics, reference implementation, application example, related patterns, and design conclusion.

Perception · 4 core

The agent's interface to the world — turning heterogeneous, noisy, oversized raw input into a high-signal representation the model can use. Governs what to look at, how small to compress, how deep to drill, how to merge.

• P1 · Context Triage — When the total volume of candidate information exceeds the context window budget, decide what gets in first, what waits outside the door, and what is not preloaded at all.
• P2 · Semantic Compaction — After an agent runs for a while its context fills up and has to be compacted. What you keep, what you drop, and how far you compress determine whether it can still reason clearly afterward.
• P3 · Progressive Discovery — When an agent faces an unfamiliar information space and does not know where the relevant information sits, it takes a quick look before deciding how deep to dig, working the space out through a three-stage loop of broad scan → close read → deep follow.
• P4 · Multi Modal Fusion — The agent receives input that includes images, text, tables, and logs. It converts each into the form the LLM can best digest, then merges them and feeds them to the reasoning layer.

Memory · 4 core + 1 extension

Keeps and retrieves knowledge beyond a single input. Memory is not an unbounded extension of context; it needs layers, versions, scope, expiry, and retrieval rules.

• M1 · Hierarchical Retention — Slice an agent's memory into tiers by scope, where each tier has its own storage, lifecycle, and loading strategy, and a new session loads from coarse to fine.
• M2 · RAG Pipeline — Give the agent an attached library, so that whenever it needs knowledge beyond what the context can hold, it can search, filter, and iteratively pull that knowledge back to use.
• M3 · Progress Tracking — Across a long task, the agent explicitly maintains a structured todo list, externalizing its state on every turn so that both the agent itself and the user can see how far the work has progressed.
• M4 · Failure Journals — The agent records every failure in structured form (which step failed, what went wrong, root cause, how it was remediated), persists it across tasks, and proactively recalls it the next time a similar situation arises.
• M5 · Procedural Memory ext — Freeze the successful execution flow of a class of tasks into a named, loadable, reusable structured asset. The next time the same kind of task arrives, the agent calls it directly, skipping trial-and-error and going straight to the main path.

Reasoning · 4 core + 1 extension

Draws conclusions and makes decisions from what's known. The engineering key is to put a control plane on judgment: mode, budget, evidence requirements, allowed actions, human-review boundary, and the next step.

• R1 · Chain of Thought — Make the model's reasoning process explicit as structured data that can be stored, audited, and migrated across models, so that "why this conclusion was reached" is on record.
• R2 · Complexity Based Routing — Before a query enters the main loop, pick a model and effort tier based on complexity signals, so that simple queries go to a cheap model and only complex queries use an expensive one. Trade routing for the bill.
• R3 · Parallel Exploration — Within a single query, deliberately launch N independent reasoning chains, then use an aggregation strategy to synthesize one answer. Trade compute for accuracy.
• R4 · Iterative Hypothesis Testing — The agent forms a hypothesis, validates it against evidence, revises based on the result, and loops until the evidence converges or an iteration limit is reached, bringing the scientific method into reasoning.
• R5 · Talker Reasoner ext — Split the agent into a fast, shallow Talker and a slow, deep Reasoner that coordinate through a shared belief state, so the agent can think deeply while still talking to the user in real time.

Action · 4 core + 1 extension

The agent acts on the world — it calls tools. This is the divide between talking and doing, and the source of all side effects and risk.

• A1 · Tool Dispatch — Before each step of action, the engineering layer selects the most suitable tool from the tool set based on tool metadata, rather than letting the model decide on the spot.
• A2 · Plan and Execute — The agent first generates a complete plan (with dependency structure, resource estimates, approval nodes), then executes against the plan, doing local replanning rather than a full rewrite when it drifts.
• A3 · Prompt Chaining — Break a complex task into a series of small tasks. Each step runs with its own independent prompt, and the output of one step becomes the input of the next, strung together to complete the work.
• A4 · Guardrail Sandwich — Wrap a pre-check and a post-check layer around every side-effecting or high-risk action the agent takes, constraining it from "free action" to "supervised action."
• A5 · Minimal Tool Set ext — Keep the agent's tool set within a reasonable ceiling (usually 10 to 30 tools): drop low-frequency tools, merge similar ones, and push secondary tools down into sub-agents, so the model has the focus to choose.

Reflection · 4 core

The agent checks itself, corrects itself, and accrues experience — the core of cumulative intelligence. It must bind to external feedback, failure signals, or past trajectories, not self-congratulatory summary.

• F1 · Generator Critic — One agent hosts two roles. The Generator writes, the Critic evaluates, and the loop improves the output until the critic passes it or the iteration cap is reached.
• F2 · Skill Package — Package a repeatedly successful workflow into a named, loadable, reusable structured asset, so the next task of the same kind calls it directly instead of figuring things out from scratch.
• F3 · Experience Replay — When a new task arrives, the agent proactively retrieves the trajectories of similar past tasks and injects the reusable parts into the current context, so that what was once learned is not learned in vain.
• F4 · Self Heal Loop — When a deterministic failure signal fires, the agent automatically diagnoses, repairs, verifies, and loops until convergence or a circuit break.

Collaboration · 4 core + 2 extensions

Division of labor across agents. Collaboration is forced by scale; below that scale a single agent is usually steadier. The floor: each agent has its own context, permissions, output, and failure boundary.

• C1 · Hierarchical Delegation — A supervisor agent dynamically splits a task, dispatches it to N worker agents for execution, and then merges the results. This is the classic multi-agent supervisor-worker collaboration.
• C2 · Fan out Gather — The orchestrator distributes a batch of independently executable subtasks in parallel to N sub-agents. Each completes its subtask on its own, and an aggregator merges the results into a single output using an aggregation strategy, trading N times the compute for 1/N of the wall-clock time.
• C3 · Adversarial Review — Pair one generator agent with one or more independent critic agents and improve the output through a structured adversarial loop. The critics must use a different model, a different family, and a different prompt incentive.
• C4 · Handoff Chain — Split a long process into N agents with clearly scoped responsibilities. After one agent finishes its leg, it passes the critical state to the next through a structured HandoffPacket (not raw text), and each agent is good at only one thing.
• C5 · Sub Agent Isolation ext — A sub-agent runs in an isolated context and must reduce its work into a schema-formed artifact before returning. The supervisor agent consumes only the artifact, never the raw trajectory.

Governance · 4 core + 1 extension

Constrains the agent's permissions and traceability. Governance is not a patch bolted on before launch; it runs through the other six functions and takes part in pattern selection in every case.

• G1 · Approval Gate — Before executing a high-blast-radius or irreversible action, route it by risk to one of three tiers — auto-approve, log-and-execute, or human review — so that a human retains final veto power at the critical decision points.
• G2 · Blast Radius Control — Classify actions by severity (readonly / mutating / catastrophic) and use nested engineering boundaries to lock down the maximum loss a single failure can cause.
• G3 · Progressive Commitment — The agent's permissions start read-only and unlock in stages toward writable, then toward irreversible. Each step up must be earned with evidence, and any incident triggers an immediate downgrade.
• G4 · Observability Harness — Attach five-dimensional telemetry across the full agent lifecycle and stitch traces across agents, so the system can be replayed after the fact, audited by regulators, and used to drive product decisions.
• G5 · Hooks Pipeline ext — Attach a deterministic interception layer before and after tool calls and agent steps, stripping the things the model should not reason about out of the prompt and into hooks that guarantee them.

Choreography: the decentralized twin of orchestration

All six core topologies share one implicit premise — a designable control point. A chain has order, routing has a router, parallel has fan-out and gather, a loop has an iterator, hierarchy has a manager, orchestration has a conductor. The defining trait of choreography is to remove that control point.

In choreography there is no central conductor. Each agent becomes an autonomous unit that subscribes only to events it cares about, reacts when one arrives, and publishes its result as a new event back to a shared stream — reporting to no center. The system's overall behavior is not written in any single flowchart; it emerges from every agent's local subscribe-react-publish rules. Add a new agent and you only wire its subscriptions; no other agent changes a line. It is orchestration's twin: orchestration is coordinated by a conductor, choreography by events.

ADPS registers choreography as an emerging topology, not a promoted seventh column. The test: to be a core column a topology must cut across multiple cognitive functions, and choreography so far holds densely only in collaboration. As of 2026 the vast majority of production multi-agent systems are still orchestration-based — the evidence isn't thick enough. It depends heavily on observability (G4): without a central trace, emergent misbehavior is hard to debug. The most common production form is a hybrid — choreography-led with a thin orchestration at the critical close. Full write-up in the C6 Choreography white paper.

Three starter combos

First time building an agent and unsure where to start — these three combos cover most scenarios. For any agent with write permission, G1 Approval Gate and G4 Observability are the floor.

• Knowledge-QA agent. P1 Context Triage + M2 RAG + R2 Complexity-Based Routing + G4 Observability. Boundary: RAG provides business evidence, not mechanical ground truth; every citation must be traceable.
• Execution-type SaaS agent. P1 + M2 RAG + M3 Progress Tracking + R2 + A1 Tool Dispatch + A2 Plan-and-Execute + G1 Approval Gate + G2 Blast-Radius Control + G4 Observability. Boundary: mechanical state like employee_id, amount, approval_id must come from tools and SessionState, never synthesized by the model on the spot.
• Multi-agent research or review system. P3 Progressive Discovery + M2 RAG + R3 Parallel Exploration + C1 Hierarchical Delegation + C2 Fan-out Gather + C3 Adversarial Review + G4 Observability. Boundary: multi-agent gains come from task scale, role boundaries, and independent review — not from looking more advanced.

Methodology

From a business problem to an agent architecture, run the six-step selection method: converge from the business down to 3–7 patterns. Don't load every pattern into the system up front.

• Bound — write a one-page scope statement: what's in, what's out.
• Map — score each of the seven functions None / Light / Heavy to get a capability vector.
• Select — fix the primary topology by the main constraint.
• Pick — choose 5–7 patterns on the matrix by coordinate.
• Assess — validate the combination on accuracy, latency, and cost.
• Build — build in three phases: minimal loop first, then reflection and memory, then governance.

Its entry point is a Pattern Selection Card with three panels: ASSESS (which cognitive functions the task needs), ROUTE (which topology fits the constraints), SELECT (which patterns live at the intersections). The card turns "I want to build an X agent" into a shortlist of candidate patterns in fifteen minutes.

Related assets

Each pattern group connects to its specifications, the relevant book chapter, runnable reference code, and reviewed case reports where available.

The book: Designing AI Agents

The white papers and the Manning book Designing AI Agents describe the same framework for two different needs, in completely different forms.

The white papers are a converged, cross-role reference. Each pattern is compressed to one page answering four things — what problem it solves, when to use it, where it tends to break, what to watch in production. The reader is the whole team; the goal is to align product, architecture, engineering, and compliance in ten minutes on "which coordinate of agent we're building."

The book is the expanded, engineer-facing treatment: the same patterns developed with runnable code, the running Argus example, and post-mortems of real production failure modes. The white papers tell you whether to use a pattern and how to avoid the traps; the book shows you how to build it and build it right.

Further reading

• Position paper: arXiv:2605.13850
• Book: Designing AI Agents (Manning)
• Runnable code: agent-design-patterns (28 patterns, LangGraph + LangChain)