Workflow Enforcement and Handoff

What You Need to Know

Some agent workflows have steps that must run in a set order. Prompt-based guidance sets that order with a system prompt instruction, such as "Always verify the customer's identity before processing a refund". Programmatic enforcement sets it in code: hooks, prerequisite gates or code-level checks that block downstream tools (the tools that run later) until their prerequisites complete. A prerequisite gate is a programmatic check that blocks a tool from executing until a prior condition is met. Task Statement 1.4 makes a strict distinction between the two.

This lesson uses one made-up example throughout: a tree surgeon whose agent answers client enquiries and books work. Before the agent books a tree felling, it must check whether the tree is protected. Before the agent refunds a deposit, it must verify the client's identity. The agent also formats quote emails, where a mistake costs nothing.

Prompt Guidance Versus Programmatic Enforcement

A prompt instruction works most of the time, perhaps in 90-95% of cases. It still has a non-zero failure rate, because the model is probabilistic. Sometimes the model skips steps, reorders them or reads the instruction loosely. A stronger system prompt, firmer instructions and few-shot examples (examples that show the correct workflow) all improve accuracy. None of them gives a deterministic guarantee. For low-stakes operations, that failure rate is fine.

A gate works every time. It is code, not a prompt instruction, so it is deterministic. Whatever the model decides, the gate prevents the wrong execution order. A prompt can tell the tree surgeon's agent to check protection first, but the agent could still skip that check on an occasional job. The agent cannot skip a gate on the booking tool.

Which Operations Need a Gate

The choice depends on what a single failure costs.

• 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 (anti-money laundering) 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.

For the tree surgeon, the deposit refund is financial, the identity check is security and the protection check is compliance. All three have gates. Quote formatting is low stakes, so a prompt instruction is enough.

How a Prerequisite Gate Works

Consider an agent with get_customer, lookup_order and process_refund tools. A gate on process_refund works like this.

1. The gate checks whether get_customer has returned a verified customer ID for this session.
2. If yes, process_refund executes normally.
3. If no, process_refund returns an error. The error says that the customer's identity is not verified, and it tells the model to call get_customer first.

The model cannot bypass the gate by deciding to skip verification. The gate blocks even a direct call to process_refund, and the error forces the model to verify identity first.

Production data on such an agent shows that it processes refunds without verifying account ownership in 8% of cases. Its system prompt instructs: "Always verify the customer's identity before processing any refund." The prompt works 92% of the time and fails 8% of the time. That 8% has already resulted in refunds processed on wrong accounts. A refund is a financial operation with real monetary consequences.

The fix is the programmatic prerequisite gate above. The gate prevents the incorrect execution order. In this way, it eliminates the 8% failure rate entirely, without improving the prompt at all.

The tree surgeon's booking tool works the same way. When the session has no protection check result, the booking tool returns an error that names the check. The agent runs the check, then retries the booking.

Subagent Lifecycle Hooks: SubagentStart and SubagentStop

The Claude Agent SDK provides lifecycle hook events to manage subagents. They complement the PreToolUse and PostToolUse hooks covered in Task Statement 1.5. They are useful background, but the exam does not test them. Suppose that the tree surgeon's coordinator spawns a quote-drafting subagent. The coordinator is the agent that spawns subagents and receives their results.

SubagentStart fires when the coordinator spawns a subagent via the Task tool. Claude Code v2.1.63 renamed this tool to Agent. SubagentStart receives the subagent's type and id, and it cannot block the spawn. It can add context. Return additionalContext in its JSON output, and that string is placed in the subagent's context before its first prompt. This is the documented way to give a newly spawned subagent an instruction that applies to all its work. To enforce rules on the spawn itself, attach a PreToolUse hook to the Agent tool. Examples of such rules are rate limits or a check that the coordinator passed required context. That hook can deny or rewrite the outgoing invocation before the subagent starts.

SubagentStop fires when a subagent finishes and returns its results to the coordinator. It receives the subagent's id and final message, so it can validate output and log completion to monitor performance. Validation can fail, for example because the output does not conform to the expected schema. The hook then exits with code 2, which prevents the subagent from stopping and makes it continue its work. Exit code 2, or a top-level decision: "block" with a reason, keeps the subagent running. A quote draft that is missing a required field would make its subagent continue its work.

SubagentStop does not transform the returned output. The hooks reference documents no field on any event that rewrites a tool result in place. The coordinator reshapes the output afterwards.

You configure both events like any other hook event, in settings.json or in a subagent's frontmatter (the block of settings at the top of the subagent's file):

{
  "hooks": {
    "SubagentStart": [
      { "hooks": [{ "type": "command", "command": "echo \"subagent started $(date)\" >> .claude/spawns.log" }] }
    ],
    "SubagentStop": [
      { "hooks": [{ "type": "command", "command": ".claude/hooks/validate-subagent-output.sh" }] }
    ]
  }
}

The first script only appends a line. To add context instead, print JSON with an additionalContext field. The second script reads the result on stdin and exits 2 if the schema check fails. Exit code 2 is one of SubagentStop's two ways to keep the subagent running.

Subagents can also define their own hooks in their frontmatter. The frontmatter supports all hook events, including PreToolUse and PostToolUse. These hooks are scoped to the component's lifetime. So they only intercept tool calls made by that subagent, not by the coordinator or other subagents. This lets you enforce a separate policy for each subagent. A billing subagent might have a PreToolUse hook that blocks refunds above a threshold, while a technical support subagent has no such restriction.

Stop hooks in a subagent's frontmatter 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 to run when the subagent completes.

Multi-Concern Request Handling

Customers often put several issues in one request, such as "I want to return my order, update my shipping address, and ask about my loyalty points". Handle it in three steps.

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

It is wrong to handle the items sequentially in separate conversations. It is also wrong to address only the first item and forget the rest. A tree surgeon's client might ask to move a felling date, query an invoice and ask about stump grinding. The agent separates the three requests, checks each against the client's account and sends one reply.

Structured Handoff Protocols

When an agent cannot resolve an issue and must escalate to a human agent, the handoff must follow a structured protocol. The human agent does not have access to the conversation transcript. They cannot scroll through the chat history. The handoff summary is the only information they receive, so it must be self-contained. It must include these fields.

• Customer ID, so the human agent can open the account.
• Conversation summary: what the customer asked for and what the agent has 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.

If the summary is incomplete, the human agent must ask the customer to repeat everything. That is a poor experience. When the tree surgeon's agent cannot resolve a disputed charge, its handoff contains all five fields, including the exact refund figure.

In the exam

The exam tests the distinction between prompt-based guidance and programmatic enforcement repeatedly. It uses one decision rule across multiple scenarios. A wrong answer on high-stakes scenarios will cost you marks. When the scenario involves money, security or compliance, the answer is always programmatic enforcement.

The exam also tests how agents should handle compound requests.

Exam Traps

Practice Scenario

Build Exercise

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
• CCAR-F Exam Guide v1.0: Task Statement 1.4 — Anthropic