Singleton
- Shared tool registry Esther Aznar, Ivan Garcia Villar
- Layered memory governance: decide which state is shared, isolated, persisted, or ephemeral Jia Huang
In Claude Code: CLAUDE.md hierarchy and auto memory
Your agent harness already speaks the patterns developers know: Observer, Mediator, Memento, Circuit Breaker, Saga. This page maps each one to the Claude Code mechanism behind it, then shows where the analogy breaks.
Hooks react to events like observers, subagents isolate context like bulkheads, turn and budget limits cap a run like circuit breakers. The vocabulary transfers.
The component in the middle is a model that decides at runtime. Order, restore and enforcement are no longer given; each card names what replaces them.
Every row ends with a check you can run on your own harness.
Object patterns (1994), integration and resilience patterns (2003 onward) and agent patterns (2024 onward) solve the same kind of problem. What changes is when the decision is taken.
19 of 21 rows carry Our mapping: the sources give the generic agent analogue, and this guide maps it to Claude Code. Mechanisms link to the official documentation.
| Classic pattern | Agent analogue | In Claude Code | Failure mode | Evidence |
|---|---|---|---|---|
| Factory Method GoF creational |
| The factory hands every product the full toolbox: a subagent definition without a tools field inherits every tool available to subagents. | Consensus Our mapping | |
| Singleton GoF creational |
| One shared memory file becomes mutable global state: parallel sessions or agents that write it at the same time can overwrite each other's entries. | Divergent Our mapping | |
| Adapter GoF structural |
| The adapter mirrors every upstream endpoint, so tool definitions crowd the context and the model picks among near-duplicate tools. | Consensus Our mapping | |
| Composite GoF structural |
| Recursion without a budget: each layer multiplies token use. Claude Code caps nesting with CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH, which can be adjusted but not removed. | Consensus Our mapping | |
| Decorator GoF structural |
| A classic decorator stack has a fixed order. Matching hooks run in parallel, so a wrapper that assumes another wrapper already ran is a race. | Divergent Our mapping | |
| Facade GoF structural |
| The facade is read as a contract. The docs state that Claude treats CLAUDE.md as context, not enforced configuration: a rule written there is a request, not a guarantee. | Single source Named by a source | |
| Chain of Responsibility GoF behavioral |
| Teams expect declaration order or rule specificity to decide. The docs state that rules are evaluated deny, then ask, then allow, and specificity does not change that order: a broad deny beats a narrow allow. | Divergent Our mapping | |
| Command GoF behavioral |
| The command object is written by the model. Without validation before dispatch, a malformed or out-of-scope argument executes as written. | Consensus Our mapping | |
| Mediator GoF behavioral |
| The mediator becomes the bottleneck: if workers return transcripts instead of summaries, the coordinating context fills with material it never reads again. | Consensus Our mapping | |
| Memento GoF behavioral |
| The snapshot is partial. The docs state that checkpoints only track changes made through Claude's file editing tools; Bash commands and external processes are not captured, and edits made by a background subagent usually are not either. | Consensus Our mapping | |
| Observer GoF behavioral |
| Subscribers assume an order. The docs state that matching hooks run in parallel, each one runs to completion, and for permission decisions the most restrictive result applies: one hook's deny does not stop a sibling hook's side effects. | Consensus Named by a source | |
| Strategy GoF behavioral |
| The strategy changes silently. Nobody can tell afterwards which model produced which result or what the switch cost. | Consensus Our mapping | |
| Template Method GoF behavioral |
| A prose skeleton is not enforced: the model can skip or reorder a step, unlike a base class that calls the steps itself. | Divergent Our mapping | |
| Pipes and Filters Enterprise integration |
| A filter emits free text that the next filter misreads, and the error travels down the pipe. | Consensus Our mapping | |
| Content-Based Router Enterprise integration |
| Overlapping descriptions route the same request to different handlers from one run to the next. | Consensus Our mapping | |
| Scatter-Gather Enterprise integration |
| The gather step averages contradicting answers instead of reconciling them, and token cost grows with every branch. | Consensus Our mapping | |
| Bulkhead Distributed and resilience |
| Only the context is isolated. Parallel agents still share one checkout and overwrite each other's files. | Consensus Our mapping | |
| Circuit Breaker Distributed and resilience |
| The breaker is static, not failure-triggered, and often set on one layer only: --max-turns has no limit by default and counts turns, not cost, so it needs --max-budget-usd beside it. | Consensus Our mapping | |
| Saga Distributed and resilience |
| Rewind is mistaken for compensation. It restores local file edits only; a push, an API call, or a database write stays done. | Consensus Our mapping | |
| Sidecar Distributed and resilience |
| Policy lives in the prompt instead of the sidecar, so the model can talk itself out of it. A policy hook can also fail open: on most events, a hook that crashes or times out lets the action through unless it sets onFailure: "block". | Single source Our mapping | |
| Event Sourcing Distributed and resilience |
| Replay is assumed to reproduce the result. Resuming a session restores the conversation, but the model calls that follow are not deterministic. | Single source Our mapping |
Each row opens its full card in the guide: classic intent, every source, and the check to run. Last verified Oct 27, 2026 against the official Claude Code documentation.
The same classic pattern gets different agent analogues depending on the source. The disagreement is shown, not resolved.
In Claude Code: CLAUDE.md hierarchy and auto memory
In Claude Code: UserPromptSubmit and PostToolUse hooks
In Claude Code: Permission rules: deny, then ask, then allow
In Claude Code: Skills that define a procedure; Stop hook as the final step check
A classic pattern assumes the component in the middle executes what it is given. A model does not, and four guarantees change with it.
Close to classic patterns, but built around two things classic patterns never managed: a context window as the scarce resource and a model as the decision-maker.
A central model breaks a task down at runtime, delegates the parts, and synthesizes the results.
What is new: Closest classic pattern: Mediator. The difference is that the model decides the decomposition during the run instead of the designer drawing it. Delegation pays on parallel work: in Google Research's controlled study, every multi-agent variant degraded a sequential planning task by 39 to 70%.
One call produces an answer, another evaluates it and sends feedback, in a loop.
What is new: The test oracle is itself a model, so the loop can converge on a wrong answer both sides accept.
Separate a read-only planning phase from the phase that changes files.
What is new: The plan is produced by the same model that will execute it, so the human review point is the plan, not the code.
Run a noisy side task in its own context and return only its conclusion.
What is new: Closest classic pattern: Bulkhead. Here the resource being protected is the context window, not threads or connections.
Summarize the conversation when it approaches the window limit, and continue from the summary.
What is new: State is lossy by design: what the summary drops is no longer in the model's context for the rest of the session.
Load short descriptions first and the full instructions only when they are needed.
What is new: Selection happens by the model reading descriptions, so a vague description hides a capability. Skills preloaded through a subagent's skills field are the exception: their full content loads at launch.
Put anything that must always happen in code that runs outside the model's judgment.
What is new: Closest classic patterns: Sidecar and Chain of Responsibility. The difference is that the rest of the system is probabilistic, so the line between suggestion and enforcement has to be drawn on purpose.
Keep the agent working until a stated completion condition is met.
What is new: Whether the goal is met is judged by a model, so the condition must be checkable.
Each card shows the classic intent, the Claude Code mechanism, when it breaks and the check to run. Under it, conference talks where a practitioner discusses the same pattern, opened at the right minute (25 talks, each timestamp checked against its transcript).
Pick by the shape of the problem, then use the simplest structure that passes its check.
On every branch: each side effect that leaves the machine needs a written compensating action (Saga), each rule that must never break needs a deterministic gate (a PreToolUse hook or a deny rule), and every automated run needs a turn limit and a budget limit (Circuit Breaker).
Decision tree in the guide →Three families come from the MAST taxonomy of multi-agent failures (Cemri et al.). The fourth covers Claude Code mechanics MAST does not address. The category assignment is this guide's reading.
| Anti-pattern | Symptom | Fix | Family |
|---|---|---|---|
| Prompt as enforcement | A must-never rule lives only in CLAUDE.md or a system prompt. | Deterministic gate: a PreToolUse hook with onFailure: "block", or a deny rule, with a test. | Specification issues |
| Context flooding | Workers return full transcripts or logs to the coordinating thread. | Context isolation: ask each worker for a bounded final report. | Inter-agent misalignment |
| Unbounded loop | An automated run has no turn, cost, or depth limit. | Circuit breaker on every layer: --max-turns, --max-budget-usd, maxTurns, spawn depth. | Specification issues |
| Unverified done | The agent declares success without running a check, or stops early. | Evaluator-optimizer with a real test, enforced by a Stop hook. | Task verification |
| Step repetition | The agent redoes completed steps after an interruption or a reset of the conversation. | Durable progress outside the context (a task list or a file) and idempotent side effects. | Specification issues |
| Rewind as rollback | A team counts on /rewind to undo shell commands or remote effects. | Saga thinking: git commits before risky work, a written compensation for each external effect. | Harness mechanics (beyond MAST) |
| Ordered hooks assumption | A hook relies on another hook for the same event having run first. | Independent observers: each hook passes or blocks on its own. | Harness mechanics (beyond MAST) |
| Specific allow overrides deny | A narrow allow rule is added to punch a hole in a broad deny. | Permission rules are evaluated deny, then ask, then allow: narrow the deny instead. | Harness mechanics (beyond MAST) |
| Unguarded shared checkout | Parallel write-capable agents edit the same working tree. | Bulkhead: isolation: worktree per writing agent. | Inter-agent misalignment |
| Untrusted content as instructions | Fetched pages, issue text, or tool output are allowed to steer the agent's next action. | Trust boundary: treat external content as data, and keep write and network tools behind permission rules. | Harness mechanics (beyond MAST) |
Articles and repositories that cover the same ground from other angles. None of them uses this page's crosswalk; each points to the closest pattern here.
April 19, 2026. A catalog of harness practices: Git as durable state, compaction, skills with progressive disclosure, hooks as the enforcement layer, planner, generator and evaluator splits, and turning each agent mistake into a permanent rule.
April 2, 2026. A mental model of feedforward guides and feedback sensors, each computational or inferential, with a human steering the loop.
A guide of practical patterns for coding agents: subagents, red/green TDD, running the tests first, manual testing and anti-patterns.
March 2024. The four agentic design patterns that popularized the term: reflection, tool use, planning and multi-agent collaboration.
January 2025. Tool use, planning and plan validation, reflection, failure modes and agent evaluation.
June 2023. The planning, memory and tool-use decomposition that most later catalogs start from.
An MIT-licensed Agent Skill for designing and auditing harnesses, built on one rule: the model proposes actions, the harness validates, authorizes, executes and records them.
An MIT-licensed reading hub on orchestration, context and memory, tools and protocols, evaluation and production safety.
MIT-licensed, small runnable Python implementations of workflow patterns such as chaining, routing, parallelization, reflection and planning.
At least one published crosswalk, catalog or paper maps the classic pattern to an agent analogue. Rows marked Consensus have two or more.
The Claude Code side links to the official documentation, checked on Oct 27, 2026. Repositories built from leaked source code are excluded.
A row without a failure mode and a check stays out. The dataset ships as JSON and through the guide's MCP server.
Each pattern card lists the classic intent, every source with its reading, the Claude Code mechanism, the failure mode and the check to run.