1.4 Workflow Enforcement and Handoff

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 tests this distinction repeatedly, and getting it wrong on high-stakes scenarios will cost you marks.

The Enforcement Spectrum

There are two very different ways to enforce workflow ordering in an agentic system:

Prompt-based guidance means putting instructions in the system prompt. For example: “Always verify the customer’s identity before processing a refund.” It works most of the time — perhaps 90-95% of cases. But it carries a non-zero failure rate. The model is probabilistic. Sometimes it’ll skip steps, reorder them, or read the instruction loosely. For low-stakes operations, that failure rate is fine.

Programmatic enforcement means implementing hooks, prerequisite gates, or code-level checks that physically block downstream tools until prerequisites complete. For example: the process_refund tool cannot execute until get_customer has returned a verified customer ID. This works every time. It is deterministic, not probabilistic. No matter what the model decides to do, the gate prevents the wrong execution order.

The Exam Decision Rule

The exam applies a consistent decision rule across multiple scenarios:

Financial operations (refunds, transfers, payments): programmatic enforcement. A single unverified refund to the wrong account is a financial loss.
Security operations (identity verification, access control): programmatic enforcement. A single bypass of identity verification is a security breach.
Compliance operations (AML checks, regulatory requirements): programmatic enforcement. A single missed compliance check can result in legal penalties.
Low-stakes operations (formatting preferences, style guidelines, output ordering): prompt-based guidance is acceptable. A formatting inconsistency is not a business risk.

The exam will present prompt-based solutions as answer options for high-stakes scenarios. Reject them. Enhanced system prompts, few-shot examples, and stronger instructions all improve accuracy but none provide deterministic guarantees. When the scenario involves money, security, or compliance, the answer is always programmatic enforcement.

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:

The agent has access to get_customer, lookup_order, and process_refund tools.
A prerequisite gate checks: has get_customer returned a verified customer ID for this session?
If yes, process_refund executes normally.
If no, process_refund returns an error message: “Cannot process refund — customer identity not verified. Please call get_customer first.”

The gate is code, not a prompt instruction. The model can’t bypass it by deciding to skip verification. Even if the model attempts to call process_refund directly, the gate blocks the call and returns an error that forces the model to verify identity first.

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). It is observational: the hook receives the subagent’s type and id, and can log the spawn. Its documented output fields are systemMessage and terminalSequence, so it cannot block the invocation, and it cannot inject context into the subagent’s run. To enforce rules on spawning itself — rate limits, or checking that the coordinator passed required context — attach a PreToolUse hook to the Agent tool instead, which can deny or rewrite the outgoing invocation before the subagent starts.

SubagentStop fires when a subagent finishes execution and returns its results to the coordinator. The hook receives the subagent’s id and final message, so it can validate output and log completion for performance monitoring. If validation fails — say the output does not conform to the expected schema — the hook exits with code 2, which prevents the subagent from stopping and sends it back to keep working. Exit code 2 is the documented blocking mechanism; there is no decision field for this event. SubagentStop does not transform the returned output, and the hooks reference documents no field on any event that rewrites a tool result in place, so treat output reshaping as something the coordinator does after the fact rather than something a hook does for you.

Subagent-scoped hooks: Subagents can define their own hooks in their frontmatter. All hook events are supported there, including PreToolUse and PostToolUse, and they are scoped to the component’s lifetime — they only intercept tool calls made by that specific subagent, not the coordinator or other subagents. This enables per-subagent policy enforcement (for example, a billing subagent might have a PreToolUse hook that blocks refunds above a threshold, while a technical support subagent has no such restriction).

Stop hook auto-conversion: When a subagent’s frontmatter defines Stop hooks, these are automatically converted to SubagentStop events, because SubagentStop is the event that fires when a subagent completes. You can therefore define cleanup or validation logic in the subagent’s own configuration and rely on it running at completion.

Multi-Concern Request Handling

Customers frequently submit requests with multiple issues: “I want to return my order, update my shipping address, and ask about my loyalty points.” The exam tests how agents should handle these compound requests.

The correct approach:

Decompose the request into distinct items (return, address update, loyalty inquiry).
Investigate each in parallel using shared context (the customer’s account information is relevant to all three).
Synthesise a unified resolution that addresses all items in a single response.

The wrong approach is to handle them sequentially with separate conversations, or to address only the first item and forget the rest.

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. The critical constraint: the human agent does NOT have access to the conversation transcript. They can’t scroll through the chat history to understand the issue.

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

Customer ID — so the human agent can pull up the account.
Conversation summary — what the customer asked for and what has been attempted.
Root cause analysis — the agent’s assessment of the underlying issue.
Refund amount (if applicable) — the specific financial figure, not a vague reference.
Recommended action — what the agent believes the human agent should do.

This summary is the only information the human agent receives. If it is incomplete, the human agent must ask the customer to repeat everything, creating a poor experience.

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 instructs: “Always verify the customer’s identity before processing any refund.” The prompt works 92% of the time but fails 8% of the time.

The 8% failure rate has already resulted in refunds processed on wrong accounts. This is a financial operation with real monetary consequences.

The fix is a programmatic prerequisite gate. Before process_refund can execute, the system checks that get_customer has returned a verified customer ID in the current session. This eliminates the 8% failure rate entirely — not by improving the prompt, but by physically preventing the incorrect execution order.

Exam Traps

Practice Scenario

Production data reveals that in 8% of cases, a customer support agent processes refunds without verifying account ownership, occasionally leading to refunds on wrong accounts. The system prompt clearly states ‘always verify customer identity before processing refunds.’ What is the most appropriate fix?

A. Implement a programmatic prerequisite gate that blocks process_refund until get_customer has returned a verified customer ID
B. Add stronger instructions to the system prompt emphasising the critical importance of verification before any refund processing
C. Add few-shot examples demonstrating the correct verification-then-refund workflow sequence
D. Implement a routing classifier that sends all refund requests to a specialised verification-first pipeline

Answer & explanation

Correct: A

A — Financial operations require deterministic enforcement. A prerequisite gate physically prevents the refund tool from executing until identity verification is complete, eliminating the 8% failure rate entirely. This is the only option that provides a 100% guarantee.
B — The current prompt already instructs verification but fails 8% of the time. Enhanced prompts may reduce the rate to 3-4% but cannot eliminate it. Financial operations require deterministic guarantees, not probabilistic improvements.
C — Few-shot examples improve consistency but still produce a non-zero failure rate. For financial operations where a single failure means a refund to the wrong account, probabilistic improvements are insufficient.
D — A routing classifier handles how requests reach agents, not how agents execute their internal workflow. The issue is that the agent sometimes skips verification within its own execution, which requires a per-agent enforcement mechanism, not a routing change.

Sources

Claude Agent SDK Overview — Anthropic
Hooks Reference — Anthropic (source for the subagent lifecycle section)
Building with Claude API, including the Customer Support Resolution Agent scenario (Skilljar) — Anthropic

Exam Simulator

Five exam-style multiple-choice questions on Workflow Enforcement and Handoff. Pick an answer, then open the explanation.

Question 1

Production data reveals that in 8% of cases, a customer support agent processes refunds without verifying account ownership, occasionally leading to refunds on wrong accounts. The system prompt clearly states “always verify customer identity before processing refunds.” What is the most appropriate fix?

A. Implement a programmatic prerequisite gate that blocks process_refund until get_customer has returned a verified customer ID
B. Add stronger instructions to the system prompt emphasising the critical importance of verification before any refund processing
C. Add few-shot examples demonstrating the correct verification-then-refund workflow sequence
D. Implement a routing classifier that sends all refund requests to a specialised verification-first pipeline

Answer & explanation

Correct: A

A is correct because financial operations require deterministic enforcement. A prerequisite gate physically prevents the refund tool from executing until identity verification is complete, eliminating the 8% failure rate entirely. This is the only option that provides a 100% guarantee.
B is wrong because the current prompt already instructs verification but fails 8% of the time. Enhanced prompts may reduce the rate to 3-4% but cannot eliminate it. Financial operations require deterministic guarantees, not probabilistic improvements.
C is wrong because few-shot examples improve consistency but still produce a non-zero failure rate. For financial operations where a single failure means a refund to the wrong account, probabilistic improvements are insufficient.
D is wrong because a routing classifier handles how requests reach agents, not how agents execute their internal workflow. The issue is that the agent sometimes skips verification within its own execution, which requires a per-agent enforcement mechanism.

Question 2

When an agent escalates to a human agent, the handoff summary must include specific fields because:

A. The human agent prefers structured data over conversational summaries when triaging a queue of escalations
B. Structured handoffs are required by the Claude API specification
C. The human agent does NOT have access to the conversation transcript and needs a self-contained summary
D. The monitoring system requires specific fields on every handoff for compliance tracking and audit reporting

Answer & explanation

Correct: C

C is correct because the critical constraint is that human agents cannot scroll through the chat history. The handoff summary is the only information they receive. Without a complete, self-contained summary (customer ID, conversation summary, root cause analysis, refund amount, recommended action), the human agent must ask the customer to repeat everything.
A is wrong because this is not about preference — it is about the human agent literally not having access to the prior conversation.
B is wrong because handoff format is not an API specification requirement. It is an architectural design decision based on the reality that human agents lack conversation access.
D is wrong because while monitoring may benefit from structured data, the primary reason is the human agent’s inability to access the conversation transcript.

Question 3

A compliance team requires that a certain workflow step occurs 100% of the time before a financial operation. Which approach provides this guarantee?

A. Including the requirement in the system prompt with bold formatting and repeated emphasis
B. Implementing a hook or prerequisite gate that programmatically blocks the operation until the step completes
C. Using few-shot examples that demonstrate the correct sequence in 10 different scenarios
D. Adding a separate validation agent that checks compliance before forwarding to the financial agent

Answer & explanation

Correct: B

B is correct because hooks and prerequisite gates provide deterministic enforcement. The operation physically cannot execute until the prerequisite completes. This is the only mechanism that guarantees 100% compliance.
A is wrong because prompt instructions, regardless of formatting or emphasis, are probabilistic. They improve the rate but cannot guarantee 100% compliance. A single failure in a financial operation has real consequences.
C is wrong because few-shot examples improve accuracy but remain probabilistic. Ten examples may achieve 98% compliance, but 100% requires deterministic mechanisms.
D is wrong because a validation agent is itself probabilistic — it might occasionally fail to catch violations. A programmatic gate is the only deterministic guarantee.

Question 4

A customer submits a request with three concerns: return an order, dispute a charge, and update their address. How should the agent handle this?

A. Address the most urgent concern first and ask the customer to call back for the other two
B. Forward all three concerns to a human agent because compound requests are too complex
C. Handle each concern in a separate conversation to avoid confusion
D. Decompose into three items, investigate them in parallel, and synthesise one resolution

Answer & explanation

Correct: D

D is correct because multi-concern requests should be decomposed into distinct items, investigated in parallel using shared context (the customer’s account information is relevant to all three), and synthesised into a single response addressing all concerns.
A is wrong because it fails to resolve all concerns and creates a poor customer experience by requiring the customer to call back.
B is wrong because compound requests are a normal part of customer support. Escalating all of them to humans defeats the purpose of the agent.
C is wrong because separate conversations lose shared context (the customer’s account information) and force the customer through multiple interaction cycles.

Question 5

For which of the following scenarios is prompt-based guidance (rather than programmatic enforcement) an acceptable approach?

A. Ensuring refunds are processed only after identity verification
B. Formatting agent responses in markdown with headers and bullet points
C. Requiring anti-money laundering checks before international transfers
D. Blocking account deletions without manager approval

Answer & explanation

Correct: B

B is correct because formatting preferences are low-stakes. An occasional plain-text response instead of markdown is not a business risk. Prompt-based guidance is sufficient for style and formatting requirements.
A is wrong because refund processing without verification is a financial risk. Programmatic enforcement is required for financial operations.
C is wrong because AML checks are a regulatory requirement. A single missed check can result in legal penalties. Deterministic enforcement via hooks is required.
D is wrong because account deletion is a high-stakes, irreversible operation. Programmatic enforcement (requiring manager approval token) is required to guarantee the approval step.