Composing Agent Patterns: From Individual Patterns to an Operable Design

Connect local mechanisms into a stateful runtime path with guards, evidence, and recovery.

The dual-axis framework locates a pattern by cognitive function and execution topology. A working system needs another design step: connecting several patterns into a path that can run, fail, and recover.

A composition is a directed relationship graph. Its nodes are patterns or business steps. Its edges carry data, state, authorization, and evidence. The matrix remains two-dimensional; composition is recorded outside it as a runtime graph. More patterns do not strengthen a design by themselves. The interfaces must be explicit, including who stops, rolls back, or takes over when a step fails.

Agent pattern composition for a payroll change with a core path, guards, feedback, and cross-cutting planes — A payroll change example. The core path performs the business action, guards protect consequential steps, feedback handles failures, and the cross-cutting planes carry system-wide evidence and boundaries.

Start with a task boundary

Define one business change that can be decided, approved, executed, accepted, and compensated independently. This boundary is more concrete than “build a payroll agent” and more complete than “call a write API.” Before choosing patterns, record the following:

Object	What must be explicit
Goal	What should change and which outcomes are outside scope
Completion	Which external fact or consumer receipt proves completion
Failure cost	The effect of a wrong decision, wrong action, duplicate action, or delay
State	Which facts belong to the business system, work progress, or model context
Authority	What the agent may read, recommend, or execute, and who may expand or revoke authority
Recovery	Where retry resumes, which actions need compensation, and when a human takes over

Four composition relationships

Relationship	Meaning	Example
Sequence	One step emits a structured artefact that the next step consumes under a contract	P1 Context Triage emits a Goal Contract; A2 Plan-and-Execute builds PlanSteps from it
Guard	Controls surround a consequential action and decide admission, maximum impact, and pre- and postconditions	G1 Approval Gate, G2 Blast-Radius Control, and A4 Guardrail Sandwich protect A1 Tool Dispatch
Feedback	Runtime outcomes enter review, failure recording, or repair before returning to design and validation	X1 events and receipts feed F1 Generator-Critic, M4 Failure Journals, or F4 Self-Heal Loop
Shared substrate	System-wide capabilities supply common event, evaluation, identity, and delegation semantics	X1 Observability, X2 Evaluation & Validation, and X3 Security & Identity

The composition contract

A composition needs a structured definition. This example omits business fields and retains the interfaces needed for architecture review.

composition_id: payroll-allowance-change
goal: change one employee allowance for the next pay period

steps:
  - id: triage
    pattern: P1
    output: goal_contract
  - id: retrieve_policy
    pattern: M2
    input: goal_contract
    output: evidence_bundle
  - id: plan
    pattern: A2
    input: [goal_contract, evidence_bundle]
    output: plan_steps
  - id: execute
    pattern: A1
    input: approved_intent
    output: action_receipt

guards:
  - pattern: G1
    protects: execute
  - pattern: G2
    limits: [amount_delta, batch_size, employee_scope]
  - pattern: A4
    checks: [preconditions, tool_result, postconditions]

acceptance:
  probe: payroll_read_after_write
  evidence: [action_receipt, state_delta]

failure_policy:
  duplicate_request: return_existing_receipt
  policy_conflict: stop_and_escalate
  partial_write: compensate_then_checkpoint

Each edge should name its artefact type and owner. If a node emits only prose, the next node cannot reliably distinguish a suggestion, decision, authorization, and execution result.

Composing the payroll change

P1 Context Triage parses the request into a Goal Contract that separates the employee, field, target value, effective date, and non-goals.
M2 RAG Pipeline retrieves policy versions and explanatory evidence. Current allowance, employment status, and approval state come directly from business systems.
A2 Plan-and-Execute creates read, validate, prepare, approve, commit, and read-after-write steps, each with a completion condition.
A1 Tool Dispatch exposes only tools allowed for the current step. G1 binds approval to a concrete Intent, G2 limits amount, batch, and resource scope, and A4 checks state before and after the call.
External acceptance reads the final payroll state and verifies the effective period. A generated completion statement is not a receipt.
X1, X2, and feedback patterns connect the trajectory, state delta, and delayed outcomes to regression cases, failure journals, and later changes.

Guards need distinct decision ownership

Approval Gate decides whether a concrete Intent is authorized. Blast-Radius Control fixes the maximum impact if a decision is wrong. Guardrail Sandwich checks tool preconditions, result structure, and post-action state. All three may protect one action, but they do not replace one another.

If two components can rewrite the same decision, accountability becomes unclear. One component admits the call, another silently reverses it, and the trace no longer identifies the governing decision. Assign a single owner to admission, limits, execution, acceptance, and compensation.

A second public code path: DeerFlow Guardrail

The DeerFlow Guardrail case shows a different composition. Tools are filtered during assembly, then pass through providers, policy decisions, and deterministic hooks at runtime. The path separates which tools the agent can see, whether a particular call may execute, and where enforcement evidence is emitted.

The business domain differs from payroll, but the review method remains the same. Follow a tool from registration through exposure, selection, admission, execution, and recording instead of placing every control in one prompt or middleware component.

Common composition problems

Pattern shopping: the team selects fashionable patterns first and looks for a problem later.
Pattern stacking: the design contains many labels, while nodes still exchange untyped prose.
Loops without exit: reflection, retries, or multi-agent debate have no budget, termination condition, or takeover point.
Overlapping control: routers, approvers, guardrails, and tools can all rewrite the same decision.
Internal-only acceptance: a grader approves the response, but the external system is never checked.
Editable protection: the agent can change execution logic, guardrails, and graders in the same change set.

Composition review checklist

Does the composition serve a concrete business change or task boundary?
Are input, output, state owner, and completion conditions explicit for every node?
Who admits, limits, executes, and accepts each consequential action?
Do retries, loops, parallel branches, and delegation have budgets and termination conditions?
Can a failure be located at a node, version, and state handoff?
Do external outcomes, human corrections, and delayed feedback enter the next validation round?
Does each added pattern close a specific gap?

Composition and lifecycle

Composition describes how one version operates. The lifecycle manages how that composition is registered, validated, released, revalidated, and retired. A change to prompts, tools, skills, policies, or topology may create a new version that needs fresh evidence. See the Agent Design Lifecycle.

Related material

Suggested citation: ADPS, Composing Agent Patterns: From Individual Patterns to an Operable Design, ADPS Topic Research, 2026-08-25.

Topic index · CC BY 4.0

The payroll change illustrates a composition structure. Named practices remain governed by their case pages and source material.