Implement multi-step workflows with enforcement and handoff patterns

There are two ways to make an agent do step A before step B. Prompt-based guidance puts the rule in the system prompt or in few-shot examples: "always call get_customer before process_refund." Programmatic enforcement puts the rule in code that runs outside the model, such as a hook or a prerequisite gate that refuses to let the downstream tool run until the prior step has completed.

Guidance shapes behavior probabilistically. The model usually complies, but it is still free to skip the step when a shortcut looks reasonable, for example when a customer volunteers an order number and the model decides it can go straight to the lookup. Enforcement removes that freedom: the tool call is intercepted and blocked regardless of what the model decided.

The exam frames this as a spectrum, not a rivalry. You keep the prompt guidance because it makes the common path smooth and cheap, and you add enforcement on the specific transitions where a single violation is unacceptable. The skill being tested is recognizing which transitions need the hard guarantee.

The mechanism for a prerequisite gate in the Claude Agent SDK is a PreToolUse hook. The hook fires before a tool executes, inspects the tool name and input, checks whatever state records that the prerequisite ran, and either allows the call or denies it with a reason.

from claude_agent_sdk import ClaudeAgentOptions, HookMatcher

verified = {"customer_id": None}  # set by a PostToolUse hook on get_customer

async def gate_order_ops(input_data, tool_use_id, context):
    tool = input_data["tool_name"]
    if tool in ("lookup_order", "process_refund") and not verified["customer_id"]:
        return {"hookSpecificOutput": {
            "hookEventName": "PreToolUse",
            "permissionDecision": "deny",
            "permissionDecisionReason":
                "Call get_customer and obtain a verified customer ID first."}}
    return {}

options = ClaudeAgentOptions(
    hooks={"PreToolUse": [HookMatcher(hooks=[gate_order_ops])]})

When the gate denies a call, the reason is returned to the model rather than crashing the turn. The model reads "call get_customer first," does exactly that, the prerequisite state is set, and the retried process_refund now passes the gate. The block is corrective, not fatal.

Claude Code exposes the same idea declaratively in settings.json (a PreToolUse matcher whose command exits with code 2 or prints a deny decision blocks the tool). The TypeScript SDK offers an equivalent canUseTool callback that returns { behavior: 'deny', message }. All three share the property that matters for the exam: the decision is made in deterministic code, not by the model.

Not every ordering rule deserves a gate. The dividing line the exam draws is the cost of a single violation. When an out-of-order action is irreversible or has financial, legal, or safety consequence, prompt instructions are not enough, because their failure rate is small but non-zero. Identity verification before a refund, authorization before releasing funds, and a signed approval before a production deploy all belong here.

When the worst case of a skipped step is mild inconvenience or a slightly worse answer, guidance is the proportionate choice. Forcing a gate onto every soft preference adds brittleness and blocks legitimate variation for no benefit.

A subtle trap: enforcing ordering is not the same as restricting availability. A router that enables only a subset of tools per request type controls which tools exist for the turn, but it does not guarantee that get_customer runs before process_refund when both are enabled. If the requirement is sequence, the answer is a prerequisite gate, not a tool-availability switch.

Real support messages often bundle several problems: "My order arrived damaged, I think I was charged twice, and my subscription never cancelled." The failure mode is answering only the first concern, or working them one at a time and losing track of the rest.

The pattern is to decompose the message into distinct items up front, then investigate each item using shared context so you do not redo expensive prerequisites. The verified customer ID from a single get_customer call is reused across the damage lookup, the billing lookup, and the subscription check. Independent items can be investigated in parallel, then merged.

The final move is synthesis into one unified resolution rather than three disconnected replies. The customer gets a single coherent answer that addresses the damaged item, the duplicate charge, and the subscription in one place, which is both better service and easier to audit.

When the agent escalates mid-process, for example because a refund exceeds an auto-approval limit or the policy is silent on the request, it hands off to a human. The critical constraint is that the human agent cannot see the conversation transcript. A bare "escalating this customer" forces the human to start the investigation over.

A structured handoff makes the escalation self-contained. The escalate_to_human tool should carry the verified customer ID, a concise root-cause analysis, the concrete numbers (refund amount, order IDs, statuses), and a recommended action, plus what the agent already attempted.

{
  "customer_id": "CUS-88231",
  "verified": true,
  "issue_summary": "Duplicate charge on order #4471 plus item damaged in transit.",
  "root_cause": "Payment retry created a second capture; box crushed on delivery.",
  "refund_amount": 640.00,
  "recommended_action": "Approve full refund (exceeds $500 auto-limit) and ship replacement.",
  "attempted": ["get_customer", "lookup_order x2", "process_refund blocked: over $500"]
}

The human reads one record and acts. This is the same discipline as preserving case facts across a long conversation, applied at the boundary where context stops being shared automatically.

The strongest designs use both layers deliberately. The system prompt still tells the agent to verify identity first and to compile a full handoff before escalating, so that on the happy path the model does the right thing without ever hitting a gate. That keeps latency and token cost low and the interaction natural.

The gate then sits underneath as a guarantee for the one invariant that must never break. If the model ever deviates, the hook catches it and feeds back a correction. Guidance optimizes the common case; enforcement bounds the worst case.

Think of the prompt as the intended path and the gate as a guardrail. You would not remove the guardrail because drivers usually stay on the road, and you would not rely on the guardrail to do the steering.