Domain 1 · Statement 1.4 4 of 7

Implement multi-step workflows with enforcement and handoff patterns

What you need to know

Prompt instructions and few-shot examples give probabilistic compliance; hooks and prerequisite gates give deterministic compliance.
When errors have financial or legal consequences, enforce ordering programmatically — a non-zero failure rate is not acceptable there.
A prerequisite gate blocks downstream tool calls until the prerequisite has returned the required state (e.g. process_refund blocked until get_customer returns a verified ID).
Restricting which tools are available addresses availability, not ordering — it does not solve a sequence-violation problem.
Decompose multi-concern requests into distinct items, investigate them in parallel over shared context, then synthesize one unified resolution.
Escalation handoffs must be structured artifacts (customer ID, root cause, amount, recommended action) because the human agent cannot see the transcript.

Some orderings must never be violated. Verify the customer before refunding them. Check the deploy target before running migrations. This statement is about the difference between asking for that ordering and enforcing it.

Prompt guidance is probabilistic; enforcement is deterministic

A system prompt that says "you must always call get_customer before any order operation" works most of the time. Most of the time is a non-zero failure rate, and when the consequence is a refund sent to the wrong account, the tolerable rate is zero. Few-shot examples move the number; they do not change its class. The exam states this directly: when deterministic compliance is required, prompt instructions alone have a non-zero failure rate.¹²

Programmatic enforcement means a prerequisite gate in code:¹⁰ a hook or interceptor that inspects each outgoing tool call and blocks it unless the prerequisite has already produced the required state. process_refund and lookup_order are refused until get_customer has returned a verified customer ID for this conversation. The block is not silent — the agent receives an explanatory error and can recover by calling the prerequisite, which is exactly the behavior you want.

Note what a gate is not: it is not a routing classifier that decides which tools are available for a request type. That addresses tool availability, not tool ordering, and it is the classic distractor on this item.¹¹ Nor is it a forced tool_choice. Forcing a specific tool (see 2.3) pins the first call of a turn; it cannot enforce a prerequisite that has to hold across the many turns of an agentic loop. That is exactly why the prerequisite lives in code, as a programmatic gate.

Decomposing multi-concern requests

Real support requests bundle concerns: a damaged item, a duplicate charge and a change of address in one message. The pattern has three moves: decompose the request into distinct items, investigate each in parallel using shared context, then synthesize a single unified resolution. The shared context — the verified customer, the account history — is established once and reused by every branch. Investigating serially wastes latency; answering each concern in isolation produces a reply that contradicts itself on totals or eligibility.

Structured handoff on escalation

When the agent escalates mid-process, the human receiving it has no access to the conversation transcript. A handoff that says "customer is upset about an order" forces a full re-investigation and destroys the time saved. A structured handoff summary carries the load-bearing facts: customer ID, order references, the root cause analysis the agent reached, the amount at stake, what has already been attempted, and a recommended action. Treat it as a typed artifact with required fields, not free prose — that is what makes it reliably complete.

Prerequisite gate blocking a downstream tool call

Show that the gate sits between the model's tool request and execution, denies with an actionable reason, and records verified state only from the prerequisite tool's result.

one transition at a time

Decomposing a multi-concern request over shared context

Show identity established once, three concern branches investigated in parallel against that shared context, and a single synthesized resolution.

one transition at a time

Worked examples

Blocking process_refund until identity is verified

Scenario 1 · Customer Support Resolution Agent

Production data shows that in 12% of cases the agent skips get_customer and calls lookup_order from a customer-stated name alone, occasionally misidentifying accounts and issuing incorrect refunds. Strengthening the system prompt reduces the rate; adding few-shot examples reduces it further; neither reaches zero.

The effective change is a programmatic prerequisite: track verified state per conversation, and intercept outgoing tool calls to refuse lookup_order and process_refund until get_customer has produced a verified customer ID. The denial message tells the agent what to do instead, so the loop self-corrects on the next iteration rather than failing the customer.

typescript

const GATED_TOOLS = new Set(['lookup_order', 'process_refund']);

// Per-conversation state, populated only by a successful get_customer result.
type SessionState = { verifiedCustomerId?: string };

function gateToolCall(toolName: string, state: SessionState) {
  if (GATED_TOOLS.has(toolName) && !state.verifiedCustomerId) {
    return {
      decision: 'deny' as const,
      // The agent SEES this and can recover on the next iteration.
      reason:
        'Blocked: customer identity is not verified. Call get_customer first and ' +
        'use the verified customer ID it returns.',
    };
  }
  return { decision: 'allow' as const };
}

// Recorded from the tool RESULT, never from what the model claims:
function recordCustomerVerification(result: GetCustomerResult, state: SessionState) {
  if (result.verified) state.verifiedCustomerId = result.customerId;
}

Prerequisite gate implemented as a tool-call interception hook

Multi-concern decomposition over shared context

Scenario 1 · Customer Support Resolution Agent

"My headphones arrived cracked, I was charged twice in March, and please update my shipping address." Three concerns, one customer.

Verify identity once, then fan out: a damaged-goods branch (order lookup, warranty eligibility, replacement vs refund), a billing branch (transaction history, duplicate detection), and an account branch (address update). All three read the same verified customer and account context instead of re-establishing it. Then synthesize: one reply that states the replacement is shipping, the duplicate charge is refunded at a specific amount, the address is updated, and — crucially — reconciles the two monetary outcomes into one coherent total.

Answering each concern in a separate pass with independent context is what produces replies that contradict themselves on amounts or eligibility.

A structured handoff the human can act on

Scenario 1 · Customer Support Resolution Agent

The agent determines that a refund exceeds policy and must escalate. The human agent picking this up sees a ticket, not the conversation. A structured summary with required fields turns a 10-minute re-investigation into a 30-second decision — and because the fields are required, the agent cannot escalate with a vague "customer is unhappy".

json

{
  "customerId": "cust_8842",
  "verifiedAt": "2026-03-11T09:14:22Z",
  "orderIds": ["ord_55120"],
  "rootCause": "Carrier damage in transit; photo evidence provided. Item is outside the 30-day replacement window by 4 days.",
  "requestedOutcome": "Full refund",
  "amountAtStake": 742.00,
  "policyConflict": "Refund exceeds the $500 autonomous limit and falls outside the replacement window.",
  "actionsAlreadyTaken": [
    "Identity verified via get_customer",
    "Order and delivery status confirmed via lookup_order",
    "Photo evidence reviewed and accepted"
  ],
  "recommendedAction": "Approve one-time goodwill refund of $742.00; damage is documented and the window overrun is marginal.",
  "conversationSummary": "Customer reported a cracked item on arrival, supplied photos, and asked for a refund rather than a replacement."
}

Structured escalation handoff payload

Anti-patterns

Strengthening the system prompt or adding few-shot examples to guarantee a critical tool ordering instead of adding a programmatic prerequisite because prompt-based compliance is probabilistic and the residual failure rate has financial consequences.
Adding a routing classifier that enables only the tools appropriate to a request type instead of gating tool order because that changes tool availability and leaves the ordering violation untouched.
Recording prerequisite state from the model's assertion ("I verified the customer") rather than from the prerequisite tool's actual result because the gate then trusts exactly the thing it exists to check.
Escalating with a free-text note instead of a structured handoff containing customer ID, root cause, amount and recommended action because the human agent has no transcript access and must redo the investigation.

How it is examined

Any stem with a percentage failure rate on a required tool sequence ("in 12% of cases the agent skips…") is asking for programmatic enforcement — the prompt-improvement and few-shot options are deliberate distractors.
Distinguish ordering from availability: an option that restricts which tools are exposed does not fix when they may be called.
For escalation items, the winning option is the one whose payload a human with no transcript could act on immediately; anything relying on "the human can review the conversation" is wrong by construction.

References — 3 sources

Hooks reference Anthropic The `PreToolUse` schema that implements a prerequisite gate, and `PostToolUse`’s `updatedToolOutput`, which replaces a tool result before it reaches the model.
Configure permissions Anthropic The allow/ask/deny rule layer and the `canUseTool` callback — the availability controls, none of which expresses an ordering constraint.
Automate actions with hooks Anthropic Working shell-hook examples for validating commands and enforcing project rules — the shortest path from the argument here to something runnable.

All sources verified · Aug 21, 2026

Live product docs — where they differ from the exam guide, answer from the guide. All references

Exam guide, verbatim — what is measured

Knowledge of

The difference between programmatic enforcement (hooks, prerequisite gates) and prompt-based guidance for workflow ordering
When deterministic compliance is required (e.g., identity verification before financial operations), prompt instructions alone have a non-zero failure rate
Structured handoff protocols for mid-process escalation that include customer details, root cause analysis, and recommended actions

Skills in

Implementing programmatic prerequisites that block downstream tool calls until prerequisite steps have completed (e.g., blocking process_refund until get_customer has returned a verified customer ID)
Decomposing multi-concern customer requests into distinct items, then investigating each in parallel using shared context before synthesizing a unified resolution
Compiling structured handoff summaries (customer ID, root cause, refund amount, recommended action) when escalating to human agents who lack access to the conversation transcript