Pattern library

Engineering patterns you can run

Each pattern below is an original interactive diagram with a deterministic simulation: play it, step it, break it, compare it with an alternative. Maturity is set editorially against primary sources and explained on every page. The families follow the shape of the work, from one model call to a durable graph.

How to read a diagram

One kit, every pattern. Humans draw in violet, model decisions in green, machinery in ink. A dashed halo marks where the model reasons; outside it, behaviour is deterministic. Dashed edges loop back; amber edges are failure paths. Turn on Trust boundaries on any stage to see what is trusted, what is the model, and what is untrusted content.

input nodeinput

input

What enters the system: a request, a message, an event.

output nodeoutput

output

What leaves it: an answer, a file, a change in the world.

agent nodeagent

agent

A model decides here. Inside the ring, behaviour is probabilistic; outside it, deterministic.

worker nodeworker

worker

A subordinate agent given one bounded task and a slice of the context.

tool nodetool

tool

A function or external service. Deterministic, callable, and the thing that actually acts.

retrieval noderetrieval

retrieval

A lookup: documents, an index, memory. Returns context, not decisions.

state nodestate

state

Shared state the run can read and write, and a human can inspect.

router noderouter

router

A switch. Sends the run down one branch based on a condition or a classification.

evaluator nodeevaluator

evaluator

A check that scores or validates an output before the run continues.

human nodehuman

human

A human understands, decides, approves, edits or redirects. The run waits.

checkpoint nodecheckpoint

checkpoint

A durable save point. The run can stop here and resume later, even on another machine.

guard nodeguard

guard

A safeguard: an input filter, a permission check, a budget, a sandbox wall.

merge nodemerge

merge

Where parallel branches rejoin.

flow
The main path of execution.
return
A loop back: the run repeats an earlier step.
data
Context or state moving, without a transfer of control.
control
A branch chosen by a condition.
failure
The path taken when something fails.

Foundations

A request enters from the left into a model ring. Three tools sit to its right: read file, run tests, edit file. Each tool call returns to the ring, which holds a context window above it and a step budget below it. When the ring answers, the result leaves to the right; when the budget runs out, the loop escalates to the developer at the bottom right.promptevery turncallcallcallresultresultresultanswerexhaustedapproveRequestContext windowModel decidesStep budgetRead fileRun testsEdit fileAnswerDeveloper

established · beginner

Single-agent tool loop

One model decides, one tool runs, the result comes back, and the model decides again until the job is done or a budget runs out.

5 scenarios · 5 lifecycle stages

Multi-agent architectures

A request enters a lead model ring. Above it sits the plan it wrote. Three worker rings run in parallel to the right, each with a slice of the task; one reads the public web and is marked untrusted. Their results join at a merge dot, return to the lead, and the answer leaves on the right. A per-worker budget sits beneath the lead.writesreviewbriefbriefbriefresultresultresultsynthesiseanswerthin · failedRequestPlanOrchestratorBudgetsWorker: public webWorker: internal docsWorker: codebaseResults joinAnswerResearcher

established · practitioner

Orchestrator and workers

A lead agent breaks a task into bounded sub-tasks, hands each to a worker with its own context, and synthesises what comes back.

5 scenarios · 5 lifecycle stages

Control and graph patterns

A change request enters a risk router. The low-risk edge goes straight to an implement ring, then a verify diamond, then a ship tool and the output. The high-risk edge drops to a plan ring, a checkpoint bar, and a reviewer double ring who can approve into implement, edit back into plan, or decline to the output. A typed state stack sits above the router; verify loops back to implement on failure.read/writelow riskhigh riskwaitapproveeditdeclinepassfail (≤2)3rd failureChange requestTyped stateRisk routerImplementPlanCheckpointReviewerVerifyOpen PRDone

established · practitioner

Stateful graph with branching and human approval

Explicit nodes and edges over typed, checkpointed state: the run branches on a condition, waits for a reviewer, and resumes later from where it stopped.

6 scenarios · 6 lifecycle stages

Maturity

established
Established: described the same way by several independent primary sources and in wide production use.
emerging
Emerging: documented by at least one primary source and in use, but the shape is still settling.
contested
Contested: credible practitioners disagree about when, or whether, to use it.
experimental
Experimental: promising, thinly evidenced. Treat as a hypothesis.

Planned · 46

Named in the taxonomy and referenced by the patterns above, not yet written as full interactive records. Each will follow the same template. The order is in docs/agentic/roadmap.md.

Foundations

  • Augmented model One model call with retrieval, tools and memory attached: the building block.
  • Reasoning and acting in turn The think-act-observe cycle from the ReAct paper, inside a loop.
  • Structured tool calling Typed arguments, validated results, and what the schema protects against.
  • Retrieval before answering Just-in-time context from an index, with provenance.
  • Short-term and persistent memory What survives a turn, a session, a user; who can see and edit it.
  • Context engineering Treating the window as a finite resource: compaction, notes, failure modes.

Workflow composition

  • Prompt chaining Fixed steps, each a model call, with checks between them.
  • Routing and classification Classify first, then send to the specialised path.
  • Conditional branching Code decides the path from state; the model does not.
  • Parallelization Sectioning and voting: independent calls at once.
  • Fan out and fan in Many branches, one join, structured results.
  • Map and reduce Apply the same step to many items, then combine.
  • Evaluator and optimizer One model produces, another critiques, until the critic is satisfied or a budget ends.
  • Reflection and refinement The agent reviews its own failed attempt before trying again.
  • Iterative planning and execution Plan, execute a step, re-plan from what happened.

Multi-agent architectures

  • Supervisor and specialists A supervisor routes turns among specialist agents that share a conversation.
  • Agent delegation An agent calls another agent as a tool and keeps control.
  • Agent handoff An agent transfers the conversation; control moves with it.
  • Sequential multi-agent orchestration Specialists in a fixed order, each handing structured output to the next.
  • Concurrent orchestration Specialists on the same input at once; results compared.
  • Hierarchical agent teams Orchestrators of orchestrators; when the tree is worth it.
  • Collaborative review An author agent and a reviewer agent with a human arbiter.
  • Debate and consensus Several agents argue; a judge or a vote decides. Contested.
  • Shared-state coordination Agents coordinate through a store, not messages.

Control and graph patterns

  • Directed workflow graphs Nodes, edges, no cycles: the simplest graph.
  • Conditional graph transitions Edges chosen by a function of state.
  • Cyclic graphs Loops inside graphs, with termination conditions.
  • Dynamic routing The next node chosen at runtime, including by a model.
  • Graph checkpoints Durable save points: resume, replay, time travel.
  • Long-running resumable workflows Runs that outlive a process, a deploy, a day.
  • Human-in-the-loop graph interruptions A node that waits for a person.
  • Event-driven agent execution Runs started and resumed by events, not calls.
  • Subgraphs and reusable components A graph as a node in another graph.

Reliability, trust and security

  • Tool permission boundaries What each tool may touch, enforced in code.
  • Human approval A person authorises before an action executes.
  • Sandboxed tool execution Isolation, limits and fast start for generated code.
  • Prompt-injection defences Data is data; capability removal; input and output checks.
  • Context provenance Every piece of context knows where it came from.
  • Least-privilege agent identities The agent is not the user; it gets its own, smaller credentials.
  • Scoped delegation Delegated authority narrows at every hop.
  • Agent authentication and authorization Who the agent is and what it may do, per call.
  • Secure agent-to-agent communication Messages between agents are untrusted input too.
  • Resource and budget limits Steps, tokens, time and money, counted outside the model.
  • Observability and audit trails Traces that explain and prove what happened.
  • Failure recovery Retries, fallbacks, escalation, rollback, as designed paths.
  • Evaluation-driven development Evals from real failures, graded on outcomes, run in CI.