Workflow Enforcement and Handoff

Official Exam Guide Objectives

Task 1.4: Implement multi-step workflows with enforcement and handoff patterns.

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

What You Need to Know

Task Statement 1.4 draws a hard line between two approaches to controlling agent behaviour: prompt-based guidance and programmatic enforcement. The exam returns to this distinction repeatedly, and it is unforgiving about it wherever the scenario involves money, access or a regulator.

The Enforcement Spectrum

Two genuinely different mechanisms for making a workflow happen in the right order:

Prompt-based guidance places the requirement in the system prompt — "Always verify the customer's identity before processing a refund." It is not weak: something like 90–95% of runs will follow it. But a language model is probabilistic, so a share of runs will read the instruction loosely, reorder the steps, or skip one under an unusual request. Where an occasional miss is merely untidy, that is a perfectly sound trade.

Programmatic enforcement places the requirement in code — a hook, a prerequisite gate, a check that refuses to run the downstream tool until its precondition is satisfied. process_refund cannot execute until get_customer has returned a verified customer ID. There is no success rate to quote, because the model's judgement is not part of the mechanism: whatever it decides to attempt, the gate holds.

The Exam Decision Rule

The exam applies a consistent decision rule across multiple scenarios:

• Financial operations (refunds, transfers, payments): programmatic enforcement. One refund reaching the wrong account is a real loss, and an average across the other runs does not offset it.
• Security operations (identity verification, access control): programmatic enforcement. One bypass is a breach, and breaches are counted individually rather than as a rate.
• Compliance operations (AML checks, regulatory requirements): programmatic enforcement. One skipped check is the finding a regulator writes up, regardless of how many were performed correctly.
• Low-stakes operations (formatting preferences, style guidelines, output ordering): prompt-based guidance is acceptable. An inconsistent heading costs nothing, and a gate here is machinery built to enforce a preference.

Expect the high-stakes items to offer a better prompt among the options. Stronger wording, few-shot examples of the correct sequence, a restructured system message — each genuinely raises the success rate and none changes the shape of what you have. Where the scenario names money, security or compliance, the answer is the gate.

Prerequisite Gates in Practice

A prerequisite gate is a programmatic check that blocks a tool from executing until a prior condition is met. In a customer support agent:

1. The agent has access to get_customer, lookup_order, and process_refund tools.
2. Before process_refund runs, a gate inspects session state: has get_customer returned a verified customer ID?
3. Where it has, the call proceeds exactly as normal — the gate is invisible on the happy path.
4. Where it has not, the call never executes. The agent receives an error instead: "Cannot process refund — customer identity not verified. Please call get_customer first."

What makes this work is that step 2 runs in code, so the model is not consulted and cannot reason its way past it, misread it, or treat this case as an exception. Returning the refusal as a tool result rather than failing silently matters too: the agent reads the error, calls get_customer, and retries without human intervention.

Subagent Lifecycle Hooks: SubagentStart and SubagentStop

The Claude Agent SDK provides lifecycle hook events specifically for subagent management. These complement the PreToolUse and PostToolUse hooks covered in Task Statement 1.5.

SubagentStart fires when a subagent is spawned via the Task tool (renamed Agent in current Claude Code). Its role is observational: it receives the subagent's type and id, and can record the spawn or add context to the run. It cannot stop the spawn or alter it. Enforcing anything about spawning itself — a rate limit, or a check that the coordinator supplied the context it was supposed to — belongs on a PreToolUse hook attached to the Agent tool, which can deny or rewrite the invocation before it leaves.

SubagentStop fires when a subagent finishes execution and returns its results to the coordinator. It receives the subagent's id and final message, which is enough to validate the output and record completion for performance monitoring. Where validation fails — the output does not match the expected schema, say — the hook returns decision: "block" with a reason, and the subagent resumes work instead of finishing. What it cannot do is transform what comes back: reshaping or redacting the output is a PostToolUse hook on the Agent tool call, whose updatedToolOutput field replaces the tool result before the model reads it.

Subagent-scoped hooks: A subagent may declare its own PreToolUse and PostToolUse hooks in its AgentDefinition frontmatter. Those hooks observe only that subagent's tool calls — not the coordinator's, and not its siblings'. That scoping is what makes per-subagent policy possible: a billing subagent can carry a PreToolUse hook refusing refunds above a threshold while a technical support subagent operates without any such restriction.

Stop hook auto-conversion: Stop hooks declared in a subagent's frontmatter are converted to SubagentStop events at runtime. Cleanup and validation logic can therefore live in the subagent's own configuration and still fire at the correct point in the lifecycle, without the coordinator having to register anything on its behalf.

Multi-Concern Request Handling

Customers rarely ask one thing at a time: "I want to return my order, update my shipping address, and ask about my loyalty points" is a single message carrying three jobs. The exam tests what an agent should do with it.

The correct approach:

1. Decompose the request into distinct items (return, address update, loyalty inquiry).
2. Investigate each in parallel using shared context — the account details bear on all three, so there is no reason to fetch them three times or to make one item wait on another.
3. Synthesise a unified resolution that answers every item in one response.

The failures are the predictable pair: handling each item in its own separate conversation, which makes the customer restate context they already supplied; or answering the first item competently while the remaining two are quietly dropped.

Structured Handoff Protocols

When an agent can't resolve an issue and must escalate to a human agent, the handoff must follow a structured protocol. One constraint shapes the whole format: the human agent does NOT have access to the conversation transcript. There is no scrollback to consult, so whatever the summary contains is the entire briefing.

A proper handoff summary must be self-contained and include:

• Customer ID — without it the human's first act is asking who they are speaking to.
• Conversation summary — what was requested, and what has already been attempted.
• Root cause analysis — the agent's reading of what is actually wrong, rather than the symptom the customer reported.
• Refund amount (if applicable) — the figure itself, not a reference to a refund having been discussed.
• Recommended action — what the agent believes should happen next.

Omit any one of these and the human reconstructs it from the customer, who is now explaining the same problem for a second time — which is the outcome the escalation was supposed to avoid.

Practical Example: The 8% Failure Rate

Production data shows a customer support agent processes refunds without verifying account ownership in 8% of cases. The system prompt is not missing the rule; it states plainly that identity must be verified before any refund, and that instruction is followed 92% of the time.

Part of the remaining 8% has already gone to the wrong accounts, which makes this a financial operation with realised losses rather than a hypothetical risk.

The candidate fixes separate cleanly. Rewriting the instruction, adding worked examples, restructuring the prompt — each might take 8% down to 3 or 4%, and none reaches zero, because every one of them is adjusting a probability. A prerequisite gate checking that get_customer returned a verified customer ID for the current session removes the failure outright, by making the wrong order impossible rather than unlikely.

Deep Dive

The permission evaluation order — where "enforcement" actually sits

Programmatic enforcement is not one undifferentiated blob — the SDK evaluates a strict, ordered sequence for every tool request: "the SDK checks permissions in this order:" hooks, deny rules, ask rules, permission mode, allow rules, then the canUseTool callback. This ordering is the concrete mechanism behind "programmatic enforcement vs prompt-based guidance": prompt-based guidance never appears in this list at all — it only shapes what the model chooses to attempt. Everything in the evaluation order runs regardless of what the model decides, which is exactly why it is deterministic.

Sourcecode.claude.com › permissionsfetched 2026-07-30

Deny beats everything, including bypassPermissions

The strength of a deny rule is absolute within this order: "if a deny rule matches, the tool is blocked, even in bypassPermissions mode." And a hook cannot soften this from the other direction either — "a hook that returns allow does not skip the deny and ask rules below; those are evaluated regardless of the hook result." For a scenario like refund verification, this means a deny rule or a blocking hook is a stronger guarantee than any permission mode the session happens to be running in.

Sourcecode.claude.com › permissionsfetched 2026-07-30

canUseTool is not a universal enforcement point — hooks are

A common mistake is assuming a custom canUseTool callback enforces a rule on every tool call. It does not: "auto-approved tools never reach canUseTool. A tool call approved at any earlier step, by acceptEdits or bypassPermissions, or by an allow rule, skips your canUseTool callback." The documented fix for a check that must be deterministic on every call, not just the ones that reach a prompt: "for checks that must run on every tool call, use a PreToolUse hook: hooks run before every other step, and a hook deny applies even in bypassPermissions mode." This is the precise reason prerequisite gates (like blocking process_refund until get_customer succeeds) belong in a hook rather than in a permission callback that might never fire.

Sourcecode.claude.com › permissionsfetched 2026-07-30

Why hooks are the documented answer to "must never fail"

Anthropic's own framing of what hooks are for maps directly onto the exam's decision rule: hooks exist to "block dangerous operations before they execute, like destructive shell commands or unauthorized file access; log and audit every tool call for compliance, debugging, or analytics; transform inputs and outputs to sanitize data, inject credentials, or redirect file paths; require human approval for sensitive actions." Every one of those is a scenario where a single silent failure has a real-world cost — financial, security, or compliance — which is exactly the exam's threshold for choosing programmatic enforcement over a system-prompt instruction.

Sourcecode.claude.com › hooksfetched 2026-07-30

A second enforcement lever: scoped deny rules on the tool itself

Prerequisite gates are not the only programmatic mechanism. disallowed_tools offers a coarser but still deterministic lever, and its two forms behave differently: "disallowed_tools=[\"Bash\"] | The Bash tool definition is removed from the request. Claude does not see the tool and cannot attempt it. disallowed_tools=[\"Bash(rm *)\"] | Bash stays available. Calls matching rm * are denied in every permission mode, including bypassPermissions." For a workflow-enforcement scenario, a scoped deny rule like process_refund(amount>500)-style matching (implemented via a hook, since deny-rule syntax matches on the literal call pattern) is a second, complementary way to guarantee a limit is never crossed, independent of whichever permission mode the session is running under.

Sourcecode.claude.com › permissionsfetched 2026-07-30

Quick Reference

Exam Traps

Practice Scenario

Build Exercise

Build a Prerequisite Gate for Financial Operations

Difficulty: Advanced (3/4)

60 minutes

1. Create a customer support agent with three tools: get_customer (returns customer ID and verification status), lookup_order (returns order details), and process_refund (processes a refund for a given amount)

Why: These three tools create the exact scenario the exam uses for the 8% failure rate question. The workflow dependency between get_customer and process_refund is where programmatic enforcement becomes essential.

You should see: Three tool definitions with proper JSON Schema input_schema. get_customer accepts a name or email, lookup_order accepts an order ID, and process_refund accepts a customer ID and amount.

2. Implement a programmatic prerequisite gate that blocks process_refund from executing until get_customer has returned a verified customer ID in the current session

Why: This is the core exam concept: prompt instructions work 92% of the time but fail 8%. A prerequisite gate provides 100% deterministic enforcement. The exam always rejects prompt-based solutions for financial operations.

You should see: A session-level state tracker that records whether get_customer has returned a verified customer. The process_refund handler checks this state before executing and returns an error if verification has not occurred.

3. Test that the gate works by prompting the agent to skip verification and process a refund directly — verify the gate blocks the attempt

Why: Testing the bypass attempt demonstrates the difference between prompt-based and programmatic enforcement. Even when the model decides to skip verification, the gate blocks the action — which is the entire point of deterministic enforcement.

You should see: The agent attempts to call process_refund without prior verification. The gate returns a blocked error message. The agent then calls get_customer before retrying the refund successfully.

4. Implement a structured handoff protocol: when the agent cannot resolve an issue, it compiles a self-contained summary with customer ID, conversation summary, root cause analysis, refund amount, and recommended action

Why: Human agents do NOT have access to the conversation transcript. The handoff summary is the only information they receive. The exam tests whether you include all five required fields: customer ID, summary, root cause, amount, and recommended action.

You should see: A handoff function that produces a structured object with all five fields populated. No field should be empty or contain placeholder text.

5. Test the handoff with a multi-concern request (return plus billing dispute plus account update) and verify the handoff summary is complete and self-contained

Why: Multi-concern requests test whether the agent decomposes the request into distinct items and addresses all of them. The exam expects decomposition, parallel investigation, and unified resolution — not sequential handling or forgetting items.

You should see: The agent identifies all three concerns, investigates each one, and produces a handoff summary that covers all three issues with specific details for each. No concern is omitted.

Sources

• Claude Agent SDK Overview — Anthropic
• Customer Support Resolution Agent Scenario (Skilljar) — Anthropic
• Building with Claude API (Skilljar) — Anthropic
• Claude Agent SDK — Permissions — Anthropic
• Claude Agent SDK — Hooks — Anthropic

Appendix A — Build Exercise Step Hints

Progressive hints revealed by the "Stuck? Get a nudge" control on each step.

Step 1. Create a customer support agent with three tools: get_customer (returns customer ID and verification status), lookup_order (returns order details), and process_refund (processes a refund for a given amount)

Why: These three tools create the exact scenario the exam uses for the 8% failure rate question. The workflow dependency between get_customer and process_refund is where programmatic enforcement becomes essential.

You should see: Three tool definitions with proper JSON Schema input_schema. get_customer accepts a name or email, lookup_order accepts an order ID, and process_refund accepts a customer ID and amount.

const tools = [
  {
    name: "get_customer",
    description: "Look up and verify a customer by name or email",
    input_schema: {
      type: "object",
      properties: {
        query: { type: "string", description: "Customer name or email" }
      },
      required: ["query"]
    }
  },
  {
    name: "lookup_order",
    description: "Look up order details by order ID",
    input_schema: {
      type: "object",
      properties: {
        order_id: { type: "string" }
      },
      required: ["order_id"]
    }
  },
  {
    name: "process_refund",
    description: "Process a refund for a verified customer",
    input_schema: {
      type: "object",
      properties: {
        customer_id: { type: "string" },
        amount: { type: "number" }
      },
      required: ["customer_id", "amount"]
    }
  }
];

tools = [
    {
        "name": "get_customer",
        "description": "Look up and verify a customer by name or email",
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {"type": "string", "description": "Customer name or email"},
            },
            "required": ["query"],
        },
    },
    {
        "name": "lookup_order",
        "description": "Look up order details by order ID",
        "input_schema": {
            "type": "object",
            "properties": {"order_id": {"type": "string"}},
            "required": ["order_id"],
        },
    },
    {
        "name": "process_refund",
        "description": "Process a refund for a verified customer",
        "input_schema": {
            "type": "object",
            "properties": {
                "customer_id": {"type": "string"},
                "amount": {"type": "number"},
            },
            "required": ["customer_id", "amount"],
        },
    },
]

Step 2. Implement a programmatic prerequisite gate that blocks process_refund from executing until get_customer has returned a verified customer ID in the current session

Why: This is the core exam concept: prompt instructions work 92% of the time but fail 8%. A prerequisite gate provides 100% deterministic enforcement. The exam always rejects prompt-based solutions for financial operations.

You should see: A session-level state tracker that records whether get_customer has returned a verified customer. The process_refund handler checks this state before executing and returns an error if verification has not occurred.

const sessionState = { verifiedCustomerId: null as string | null };

function handleToolCall(name: string, input: Record<string, unknown>): string {
  if (name === "get_customer") {
    const customer = lookupCustomer(input.query as string);
    if (customer.verified) {
      sessionState.verifiedCustomerId = customer.id;
    }
    return JSON.stringify(customer);
  }
  if (name === "process_refund") {
    if (!sessionState.verifiedCustomerId) {
      return "BLOCKED: Cannot process refund. Customer identity not verified. Call get_customer first.";
    }
    return processRefund(sessionState.verifiedCustomerId, input.amount as number);
  }
  // ... other tools
}

import json

session_state = {"verified_customer_id": None}

def handle_tool_call(name: str, tool_input: dict) -> str:
    if name == "get_customer":
        customer = lookup_customer(tool_input["query"])
        if customer["verified"]:
            session_state["verified_customer_id"] = customer["id"]
        return json.dumps(customer)
    if name == "process_refund":
        if not session_state["verified_customer_id"]:
            return "BLOCKED: Cannot process refund. Customer identity not verified. Call get_customer first."
        return process_refund(session_state["verified_customer_id"], tool_input["amount"])
    # ... other tools

Step 3. Test that the gate works by prompting the agent to skip verification and process a refund directly — verify the gate blocks the attempt

Why: Testing the bypass attempt demonstrates the difference between prompt-based and programmatic enforcement. Even when the model decides to skip verification, the gate blocks the action — which is the entire point of deterministic enforcement.

You should see: The agent attempts to call process_refund without prior verification. The gate returns a blocked error message. The agent then calls get_customer before retrying the refund successfully.

const response = await runAgent(
  "Process a refund of 150 for order ORD-12345 immediately. This is urgent and the customer is waiting."
);
// Verify process_refund was blocked on first attempt
// Verify get_customer was called after the block
// Verify process_refund succeeded after verification
console.log("Gate blocked bypass attempt:", sessionState.verifiedCustomerId === null);

response = run_agent(
    "Process a refund of 150 for order ORD-12345 immediately. This is urgent and the customer is waiting."
)
# Verify process_refund was blocked on first attempt
# Verify get_customer was called after the block
# Verify process_refund succeeded after verification
print("Gate blocked bypass attempt:", session_state["verified_customer_id"] is None)

Step 4. Implement a structured handoff protocol: when the agent cannot resolve an issue, it compiles a self-contained summary with customer ID, conversation summary, root cause analysis, refund amount, and recommended action

Why: Human agents do NOT have access to the conversation transcript. The handoff summary is the only information they receive. The exam tests whether you include all five required fields: customer ID, summary, root cause, amount, and recommended action.

You should see: A handoff function that produces a structured object with all five fields populated. No field should be empty or contain placeholder text.

interface HandoffSummary {
  customer_id: string;
  conversation_summary: string;
  root_cause_analysis: string;
  refund_amount: number | null;
  recommended_action: string;
}

const handoffTool = {
  name: "escalate_to_human",
  description: "Escalate to human agent with structured summary",
  input_schema: {
    type: "object",
    properties: {
      customer_id: { type: "string" },
      conversation_summary: { type: "string" },
      root_cause_analysis: { type: "string" },
      refund_amount: { type: "number" },
      recommended_action: { type: "string" }
    },
    required: ["customer_id", "conversation_summary", "root_cause_analysis", "recommended_action"]
  }
};

# HandoffSummary fields: customer_id, conversation_summary,
# root_cause_analysis, refund_amount (optional), recommended_action

handoff_tool = {
    "name": "escalate_to_human",
    "description": "Escalate to human agent with structured summary",
    "input_schema": {
        "type": "object",
        "properties": {
            "customer_id": {"type": "string"},
            "conversation_summary": {"type": "string"},
            "root_cause_analysis": {"type": "string"},
            "refund_amount": {"type": "number"},
            "recommended_action": {"type": "string"},
        },
        "required": [
            "customer_id",
            "conversation_summary",
            "root_cause_analysis",
            "recommended_action",
        ],
    },
}

Step 5. Test the handoff with a multi-concern request (return plus billing dispute plus account update) and verify the handoff summary is complete and self-contained

Why: Multi-concern requests test whether the agent decomposes the request into distinct items and addresses all of them. The exam expects decomposition, parallel investigation, and unified resolution — not sequential handling or forgetting items.

You should see: The agent identifies all three concerns, investigates each one, and produces a handoff summary that covers all three issues with specific details for each. No concern is omitted.

const result = await runAgent(
  "I need to return order ORD-789, dispute a charge of 45.00 on my last bill, and update my shipping address to 123 New Street."
);
const handoff = extractHandoff(result);
console.log("All concerns covered:",
  handoff.conversation_summary.includes("return") &&
  handoff.conversation_summary.includes("dispute") &&
  handoff.conversation_summary.includes("address")
);

result = run_agent(
    "I need to return order ORD-789, dispute a charge of 45.00 on my last bill, "
    "and update my shipping address to 123 New Street."
)
handoff = extract_handoff(result)
print(
    "All concerns covered:",
    "return" in handoff["conversation_summary"]
    and "dispute" in handoff["conversation_summary"]
    and "address" in handoff["conversation_summary"],
)

Appendix B — Interactive Study Prompts

Two prompts to paste into Claude. B1 drills the judgement the exam actually measures; B3 reviews the code you wrote for the Build Exercise above. The exam simulator between them is the interactive quiz on this page.

B1. Concept Check — Discrimination Drill

B2. Exam Simulator

B3. Build Coach — Code Review

The Build Exercise and its hint ladder are already on this page. This prompt is for the one thing the page cannot do: review the code you actually wrote.