ADPS Agent Design Pattern White Paper

Pattern Catalog and Selection Framework

Cognitive function × execution topology · 27 matrix patterns · 3 cross-cutting engineering planes · five extensions and one candidate.

v0.9 contains 27 cell-bound patterns, three cross-cutting engineering planes, five extension patterns, and one candidate. The dual axis locates patterns and the engineering planes carry system-wide responsibilities. Lifecycle, composition, and human-agent operating boundaries are documented as separate topics.

Pattern specifications define recurring problems, mechanisms, boundaries, and verification. Engineering case reports show how pattern combinations behave under named system constraints. Workshop records preserve field questions and unresolved disagreements.

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.

Start with one business change

Consider a payroll-agent request: “Change employee E-1842's monthly transport allowance from 800 to 1000, effective next month.” It should not compile directly into a tool call. The first design unit is a minimum controlled loop: one business change that can be decided, approved, executed, accepted, and compensated independently.

StageEngineering questionMinimum artifactPatterns
GoalWho, what field, which effective date, and what is out of scope?Goal ContractP1 Context Triage
EvidenceWhere do current state and policy basis come from?Mechanical state + versioned evidenceM2 RAG / structured query
PlanHow do read, validate, prepare, approve, commit, and after-read connect?PlanStep + completion conditionA2 Plan and Execute
CommitmentWho approves which tool, arguments, and resource?Intent + ApprovalG1 Approval Gate, G2 Blast-Radius Control
AcceptanceWhat proves completion and where does failure stop?Receipt + state delta + traceX1 Observability

Split the unit when decision, approval, execution, acceptance, or compensation requires a different owner or rule. The boundary is small enough when each control can be assigned and verified without reopening the others. Enterprise modelling defines business objects, rules, and responsibilities; agent design compiles one business change into a controlled runtime path.

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.

Execution topologyFits
ChainStable steps; one step's output goes straight to the next.
RouteClassify first, then choose model, tool, flow, or human-review path.
ParallelSeveral paths at once, trading cost for quality or latency.
LoopGenerate, observe, correct, regenerate — until convergence or a circuit breaker.
HierarchyLayered responsibility, permissions, memory, or protection boundaries.
OrchestrateOne central coordinator holds the global goal, the task ledger, and the rollup.
ADPS Agent Design Pattern Framework with 27 matrix patterns and three cross-cutting engineering planes
The dual-axis matrix retains 27 cell-bound patterns. X1–X3 span every cognitive function and execution topology.

Use the Pattern Selection Card for an initial shortlist, then apply the Six-Step Selection Method to test the baseline, constraints, and seams before implementation. See Common Pattern Compositions for cross-cell runtime designs, the Agent Design Lifecycle for production state transitions, and Human-Agent Interaction for authority and intervention boundaries.

The same matrix in text, for search and citation.

Cognitive functionChainRouteParallelLoopHierarchyOrchestrate
PerceptionP2 Semantic CompactionP1 Context TriageP4 Multi-Modal FusionP3 Progressive Discovery
MemoryM2 RAGM4 Failure JournalsM1 Hierarchical RetentionM3 Progress Tracking
ReasoningR1 Chain-of-ThoughtR2 Complexity-Based RoutingR3 Parallel ExplorationR4 Iterative Hypothesis Testing
ActionA3 Prompt ChainingA1 Tool DispatchA4 Guardrail SandwichA2 Plan-and-Execute
ReflectionF1 Generator-CriticF2 Skill PackageF4 Self-Heal LoopF3 Experience Replay
CollaborationC4 Handoff ChainC2 Fan-out GatherC3 Adversarial ReviewC1 Hierarchical Delegation
GovernanceG3 Progressive CommitmentG1 Approval GateG2 Blast-Radius Control

You will notice several empty cells in the matrix. At those intersections, ADPS has not yet found a stable structure that warrants its own name, or an existing pattern already explains the main engineering problem.

A pattern implementation may use several topologies; the matrix marks its primary coordinate. M2 RAG, for example, sits at Memory × Chain because evidence moves through a retrieval pipeline. A production implementation may also loop through query, evaluation, rewrite, and retrieval, or navigate a hierarchical index. These remain implementation choices within M2, whose identifying coordinate is Memory × Chain.

Cross-cutting engineering planes

The dual axis locates patterns. Cross-cutting planes supply shared infrastructure without adding matrix columns or replacing the two-axis model.

PlaneScopeKey artifacts
X1 ObservabilityEvery function, topology, and lifecycle stageEvents, causality, versions, state deltas, external receipts
X2 Evaluation & ValidationSpecifications, models, tools, skills, policies, and composed systemsCases, graders, regression, business acceptance, release gates
X3 Security & IdentityUsers, agents, workloads, runs, delegation chains, resourcesPrincipals, delegation, allow / deny / ask, short-lived credentials

Loop remains an execution topology. Runtime mechanisms such as ReAct can use it, with the engineering planes supplying evidence, validation, identity, and authority.

Related design topics

Six engineering contracts

Production agents should make six contracts explicit.

  • 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 version, argument provenance, idempotency, compensation, and external acceptance (Action).
  • Authority Contract — principal, delegation, resource scope, policy version, approval, and expiry (Governance).
  • Trace Contract — every LLM call, tool call, handoff, approval, and state update joined into one causal chain (X1 Observability).

White-paper catalog

White Paper v0.9 contains 27 matrix patterns and three cross-cutting engineering planes. Five extension specifications cover more specific runtime structures: M5 Procedural Memory, R5 Talker-Reasoner, A5 Minimal Tool Set, C5 Sub-Agent Isolation, and G5 Hooks Pipeline. C6 Choreography remains a candidate pending evidence across more than the collaboration function. Extensions 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 candidate information exceeds the context budget, decide what enters now, what remains available for later retrieval, and what is excluded.
  • P2 · Semantic Compaction — Long sessions approach the context limit. Semantic compaction removes redundant material while preserving goals, accepted evidence, unresolved failures, provenance, and recovery state.
  • P3 · Progressive Discovery — Scan an unfamiliar information space broadly, inspect promising sources, and deepen the search only where evidence justifies the cost.
  • P4 · Multi-Modal Fusion — Convert each modality into the representation required by downstream checks, process independent channels in parallel, and preserve provenance in the fused artifact.

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 — Organize agent memory by scope, functional type, and access cost, then maintain the active working set through explicit admission, promotion, demotion, and retirement rules.
  • M2 · RAG Pipeline — Organize large knowledge sources into provenance-, version-, and permission-aware indexes, then use a retrieval harness to query, navigate, rerank, and assemble evidence for the current task.
  • M3 · Progress Tracking — Maintain a goal contract, structured progress, authoritative state references, and checkpoints across a long task so that work can resume without drifting or repeating side effects.
  • M4 · Failure Journals — Separate immutable failure facts, candidate diagnoses, and verified lessons, then recall only applicable and current experience in later tasks.
  • M5 · Procedural Memory ext — Publish a verified method as a named, triggerable, versioned instruction or executable asset, and recertify it when dependencies change.

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. See the Reasoning module overview for boundaries, composition, and validation.

  • R1 · Chain of Thought — Manage available reasoning artifacts, evidence, decisions, and model metadata as structured data for replay, audit, and fallback.
  • R2 · Complexity-Based Routing — Route each request to a model and effort tier using task complexity, risk, and acceptance evidence. Record the decision and escalate when the selected tier fails its checks.
  • R3 · Parallel Exploration — Run independent reasoning branches, preserve their evidence, and aggregate only when measured quality gains justify the added cost.
  • R4 · Iterative Hypothesis Testing — Test versioned hypotheses against evidence, revise the active set, and stop on confirmation, no progress, or a hard limit.
  • R5 · Talker-Reasoner ext — Keep live conversation responsive while a separate Reasoner updates versioned shared state under timeout and stale-result controls.

Action · 4 core + 1 extension

Action covers model and tool steps that can change external state. These steps require tool admission, authority, evidence, and rollback or compensation.

  • A1 · Tool Dispatch — Before execution, the runtime narrows eligible tools using metadata, permissions, risk, and current state. The model chooses only within that admitted set.
  • A2 · Plan and Execute — Represent a long task as a versioned dependency plan, execute ready steps, and replan affected future work when assumptions change.
  • A3 · Prompt Chaining — Decompose a workflow into ordered model or tool steps with explicit input, output, and acceptance contracts. Each artifact is validated before the next step consumes it.
  • A4 · Guardrail Sandwich — Apply policy checks before a high-risk tool call, retain execution evidence, and validate the result afterward, with defined paths for rejection, approval, compensation, and escalation.
  • A5 · Minimal Tool Set ext — Reduce tool ambiguity by removing obsolete tools, consolidating overlaps, routing by task, and loading specialist tools on demand.

Reflection · 4 core

The agent reviews artifacts, trajectories, and external outcomes, then decides whether to change the current output, runtime path, or reusable assets. Every loop needs evidence, a stop condition, and explicit change authority.

  • F1 · Generator-Critic — A Generator produces an output and a Critic reviews it against evidence and a rubric. Scope, rounds, and cost are bounded; the run exits when release criteria or the iteration cap is reached.
  • F2 · Skill Package — Package a repeatedly successful workflow as a named, loadable, versioned skill, then manage its evaluation, coexistence, release, rollback, and retirement.
  • F3 · Experience Replay — Turn reviewed trajectories and delayed outcomes into scoped experience records, then measure whether later runs use them successfully.
  • F4 · Self-Heal Loop — Use a bounded diagnose-repair-verify loop for deterministic failures inside an approved repair domain.

Collaboration · 4 core + 2 extensions

Collaboration governs the movement of tasks, context, authority, evidence, and responsibility across participants. The module overview separates relationship patterns, isolation constraints, distributed candidates, and mechanisms, then explains topology lowering.

  • C1 · Hierarchical Delegation — A supervisor delegates bounded tasks and authority to workers, then verifies and integrates their artifacts against a shared contract.
  • C2 · Fan-Out/Gather — The orchestrator distributes independently executable subtasks to parallel sub-agents, then an aggregator deduplicates, resolves conflicts, and merges their results.
  • C3 · Adversarial Review — Separate proposal, review, and adjudication roles; give reviewers independent evidence and a shared rubric before release.
  • C4 · Handoff Chain — Split a long process across agents with bounded responsibilities. Each agent returns a structured HandoffPacket with the state, evidence, open questions, and authority the next agent needs.
  • C5 · Sub-Agent Isolation ext — Run each delegated worker within bounded context, tools, credentials, budget, and workspace, then return a schema-valid artifact with evidence links and failure state.
  • C6 · Choreography candidate — Event participants advance a shared outcome under local subscription rules; no node owns the complete plan. Completion, causal trace, and compensation must be explicit.

Governance · 3 matrix core + 1 extension

Governance decides whether the current intent is admitted, where maximum impact stops, and what authority a capability earns or loses over repeated operation. See the Governance module overview for lifecycle and control-plane design.

  • G1 · Approval Gate — Route a concrete intent by principal, immutable tool version, canonical arguments, resource, environment, impact, and preconditions. Revalidate on resume; consume approval once.
  • G2 · Blast-Radius Control — Set hard limits for resource, amount, batch, rate, budget, tenant, and fleet aggregation, then keep those limits outside agent judgement.
  • G3 · Progressive Commitment — Hold, promote, narrow, demote, freeze, or retire authority by agent version, capability, scenario, resource, and environment.
  • G4 · Observability Harness · legacy entry → X1 — The identifier and old route remain visible for catalog history. The current cross-cutting specification is X1 Observability.
  • G5 · Hooks Pipeline ext — Enforce deterministic controls at unavoidable lifecycle points while separating policy source, decision, enforcement, and evidence. DeerFlow Guardrail provides a public code path.

Cross-cutting engineering planes

  • X1 · Observability — Join input provenance, causal identity, component and policy versions, decisions, state deltas, and external receipts into runtime evidence.
  • X2 · Evaluation & Validation — Use repeatable cases, graders, regression, and external acceptance to govern capability evidence.
  • X3 · Security & Identity — Propagate identity across delegation and constrain each run with least privilege and short-lived credentials.

Choreography and distributed control

The six core topologies each expose a control point: sequence order, router, fan-out and gather owner, loop controller, hierarchy supervisor, or orchestrator. Choreography distributes that control across event participants.

In choreography, each participant subscribes to defined events, applies local rules, and publishes new events. No component owns the complete plan. Adding a participant changes event contracts and subscriptions instead of a central call graph, but the system still needs explicit completion, timeout, causal trace, and compensation rules.

ADPS registers choreography as an emerging topology, not a promoted seventh column. A core column must cut across several cognitive functions; current public agent-engineering evidence for choreography remains concentrated in collaboration. X1 Observability is essential because decentralized execution still needs causal trace, timeout, compensation, and a defined completion owner. Hybrid designs can keep event-driven collaboration while retaining explicit coordination at critical commits. Full write-up in the C6 Choreography white paper.

Pattern composition

The matrix locates individual mechanisms. Composition tools connect them to one complete business task.

  1. Pattern Selection Card

    Record the scenario boundary, failure cost, cognitive needs, topology, and candidate patterns on one page for the first design discussion.

  2. Six-Step Selection Method

    Run the baseline and candidate designs against the same workload, inspect their seams, perform ablations, and issue a decision receipt with reopen conditions.

  3. Common Pattern Compositions

    Review an execution-agent reference architecture and starting compositions for knowledge work, long-running research, content production, coding, business transactions, and multi-agent work.

ADPS Pattern Selection Card with scenario boundary, cognitive needs, topology, candidate patterns, tradeoffs, and architecture sketch
The card records the architecture hypothesis; the six-step method tests it against a baseline.

Execution-agent reference architecture

An execution agent connects goals and evidence, plans and tools, authority and external acceptance. P1, M2, A1/A2, G1/G2, and X1 are common starting points. Add M3 when work crosses sessions, A4 around consequential writes, and F1 or C3 when the result needs independent review. See Common Pattern Compositions for the full structures and boundaries.

Three common runtime mechanisms

ReAct lets the model choose its next action after each observation, which suits tasks whose path is not known in advance. Programmatic Tool Calling lets the model write a bounded program that loops over, runs, or filters results from registered tools. It suits tool-heavy steps whose local control flow can be expressed as code. CodeAct provides a broader executable-code action space for computation, libraries, and currently available capabilities. All three are runtime-mechanism concepts and have no separate matrix coordinates.

Workshop records

First Collaboration Module Workshop · 25 August 2026. Hosts: Haili Zhang and Jia Huang. Core workshop guests: Dong Zhang and Wei Wang. The session covered topology lowering, delegated authority, cross-session conflicts, Handoff Contracts, Hook Composition, three collaboration planes, Agent OS, and abstraction-reconstruction.

First Governance Module Workshop · 18 August 2026. Hosts: Willem Jiang and Jia Huang. Core workshop guests: Yangyang Ma, Dong Zhang, Qingfeng Li, Bo Long, Yibo Xu, and Bin Wu. Topics included dangerous tool calls, agent fleets, lifecycle, sandboxing and domain authorization, assembly-time filtering and runtime review, durable intent, capability-specific authority, agent registry, evidence attribution, and the change loop across observation, evaluation, reflection, and governance.

First Perception Module Workshop · 13 August 2026. Host: Jia Huang. Core workshop guests: Dong Zhang, Xianglong Huang, Qingfeng Li, and Cheng Huang. The session covered signal admission, event ingress, the boundary between multi-source and multi-modal input, and context in AI-driven software engineering.

First Reflection Module Workshop · 12 August 2026. Hosts: Haili Zhang and Jia Huang. Core workshop guests: Dong Zhang, Mo Zhou, Wei Wang, Qianchun Lu, Pylon Peng, and Jiaqi Li. The session covered online and offline reflection, feedback latency, evaluation evidence, skill evolution, attribution, and self-repair boundaries.

First Action Module Workshop · 6 August 2026. Discussion host: Bingsheng Ru. Core participants: Qingfeng Li, Dong Zhang, Jun Luo, Hongshan Tang, Wei Wang, Pylon Peng, and Leida Ren. The session covered Plan and ReAct, structured plans, tool admission, GUI action, sandboxes, multi-agent orchestration, and event-driven execution.

First Memory Module Workshop · 5 August 2026. Hosts: Haofen Wang and Jia Huang. Core experts: Yingfeng Zhang, Qiuai Fu, Dong Zhang, Mo Zhou, Yutao Chen, and Qingfeng Li. The session covered adoption criteria, lifecycle, engineering boundaries, admission, versioning, and forgetting.

View the White Paper contributors.

Related assets

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

Pattern groupWhite papersBook chapterCode directory
PerceptionP1–P4Ch3 Perceptionperception/
MemoryM1–M4 (+M5 ext)Ch4 Memorymemory/
ReasoningR1–R4 (+R5 ext)Ch5 Reasoningreasoning/
ActionA1–A4 (+A5 ext)Ch6 Actionaction/
ReflectionF1–F4Ch7 Reflectionreflection/
CollaborationC1–C4 (+C5 ext; C6 candidate)Ch8 Collaborationcollaboration/
GovernanceG1–G3 (+G5 ext)Ch9 Governancegovernance/
Cross-cutting planesX1–X3Across chaptersobservability / evals / security

The book: Designing AI Agents

The white papers and the Manning book Designing AI Agents use the same framework at different levels of detail.

The white papers are concise architecture references. Each specification covers the recurring problem, mechanism, applicability, failure modes, verification, and related patterns so product, architecture, engineering, and governance teams can review the same design.

The book develops the implementation in depth through runnable code, the Argus example, and production failure analysis. It covers how the patterns are built, combined, tested, and operated.

Further reading

  • Position paper: arXiv:2605.13850
  • Book: Designing AI Agents (Manning)
  • Runnable code: agent-design-patterns
  • Atul Gawande, The Checklist Manifesto, Metropolitan Books, 2009.
  • Liu Chunlei, Yi Hong, and Wang Lin, Technology Control: Seeking Efficiency from Methods (Chinese), CITIC Press, 2024, ISBN 9787521764666.

Version history

VersionDateChange
v0.1May 2026Established seven cognitive functions and pattern cards.
v0.218 June 2026Converged 28 core patterns, six execution topologies, and engineering contracts.
v0.313 July 2026Aligned web and local catalogs; added extension and candidate status plus evidence boundaries.
v0.419 August 2026Retained the dual axis; moved the then-G4 Observability specification outside the matrix; added lifecycle, a payroll running example, and revised Governance.
v0.520 August 2026Established X1–X3 as cross-cutting engineering planes; retained the old G4 route as a legacy entry; added a thin lifecycle rail to the canonical figure.
v0.625 August 2026Revised the canonical title, proportions, and typography; combined offline evaluation and canary under validation.
v0.725 August 2026Returned the canonical figure to the dual axis and cross-cutting planes; moved lifecycle, composition, and human-agent boundaries into separate topics.
v0.825 August 2026Removed explanatory microcopy from the cross-cutting cards, tightened the lower section, and renamed X2 Evaluation & Validation.
v0.926 August 2026Reorganized Collaboration; added its module overview, workshop record, topology-lowering and handoff concepts; retained the G4 legacy route to X1 while keeping the v0.8 canonical figure.

Suggested citation: ADPS, Agent Design Pattern White Paper v0.9: Pattern Catalog and Selection Framework, 26 August 2026.

CC BY 4.0

Scope: This release defines architecture vocabulary, applicability boundaries, and a review method. It does not certify products, implementations, or organizational readiness. Pattern specifications, illustrative scenarios, and attributed case reports use different evidence standards; scenarios explain mechanisms.