Patterns/Composition tools/Common Pattern Compositions

The dual-axis framework is a map of patterns. Applications, data, people, policy, waiting states, and acceptance points make up the task terrain. Two teams can choose the same patterns and still produce different architectures because they place facts and responsibility differently.

A composition is a directed task graph. Its nodes are business activities or patterns. Its edges carry task identity, business state, authority, and completion evidence. For every consequential edge, the design names the producer, consumer, mutation rights, and the owner of stop, compensation, or takeover.

Keep four continuity lines intact

Review fit at three levels. Task-pattern fit asks whether each pattern addresses an observed failure. Pattern-pattern fit checks the artifact, owner, and acceptance rule at each seam. Architecture-workload fit compares the composition with the smallest baseline under the same input, faults, and authority.

Draw the complete task first

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:

Four composition relationships

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

1. P1 Context Triage parses the request into a Goal Contract that separates the employee, field, target value, effective date, and non-goals.
2. M2 RAG Pipeline retrieves policy versions and explanatory evidence. Current allowance, employment status, and approval state come directly from business systems.
3. A2 Plan-and-Execute creates read, validate, prepare, approve, commit, and read-after-write steps, each with a completion condition.
4. 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.
5. External acceptance reads the final payroll state and verifies the effective period. A generated completion statement is not a receipt.
6. 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.

An execution-agent reference architecture

A task that changes an external system usually passes through goal, evidence, plan, commitment, and acceptance. P1 turns the request into a Goal Contract. M2 and structured queries supply policy evidence and mechanical state. A2 owns the plan and step state. A1 binds the current Intent to a tool. G1, G2, and A4 handle authorization, impact limits, and state checks around the commit. X1 links the state delta and external receipt to the run.

Adapt this starting architecture to the task. Read-only answering may not need an approval gate. Cross-session work needs M3. Parallel writes add C5 and write-conflict checks. Independent review adds F1 or C3. Each addition should trace to a failure record or business constraint.

Starting points for eight application types

ReAct, Programmatic Tool Calling, and CodeAct

All three connect reasoning to action at runtime, with different control rhythms and action spaces.

ADPS catalogues ReAct, Programmatic Tool Calling, and CodeAct as runtime-mechanism concepts without separate pattern IDs. ReAct commonly uses Loop. Programmatic Tool Calling sits between A1 Tool Dispatch and A2 Plan and Execute. CodeAct provides a broader code action space. A generated procedure enters M5 Procedural Memory only after validation, naming, versioning, and admission for reuse across tasks.

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

1. Does the composition serve a concrete business change or task boundary?
2. Are input, output, state owner, and completion conditions explicit for every node?
3. Who admits, limits, executes, and accepts each consequential action?
4. Do retries, loops, parallel branches, and delegation have budgets and termination conditions?
5. Can a failure be located at a node, version, and state handoff?
6. Do external outcomes, human corrections, and delayed feedback enter the next validation round?
7. 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

• ADPS Pattern Catalogue and Selection Framework
• Pattern Selection Card
• Six-Step Selection Method
• Agent Design Lifecycle
• Human-Agent Interaction
• Bo Liang execution-agent case
• DeerFlow Guardrail code and architecture evolution
• Action overview
• Governance overview

Edit source · Published source · Review process