Workflow Enforcement & Handoff

There are two fundamentally different ways to control agent behavior. Prompt-based guidance is probabilistic: instructions in the system prompt work perhaps 90-95% of the time, but the model can still skip, reorder, or misread steps. Programmatic enforcement is deterministic: code-level checks and gates physically block an incorrect sequence before it executes, every time, regardless of what the model decides.

The enforcement decision matrix

Prerequisite gates

A prerequisite gate is a code-based mechanism that blocks a tool until prior conditions are met. Consider a refund flow with get_customer, lookup_order, and process_refund. The gate checks whether get_customer has returned a verified customer ID this session. If yes, process_refund runs; if not, it returns a blocking error telling the agent to verify identity first. The model cannot reason its way past the gate - even a direct process_refund call is blocked until the prerequisite completes. In production, an 8% unverified-refund rate under prompting dropped to 0% once a gate was added.

SYSTEM = "Always verify identity before any refund."

if tool == "process_refund" and not session.get("verified_customer_id"):
    return {"decision": "block", "reason": "Verify identity first."}

Subagent lifecycle hooks

The Agent SDK exposes two lifecycle hooks specific to subagents. They are easy to confuse, and the exam tests the distinction:

• SubagentStart - fires when a subagent is spawned. It is observational: it can log the spawn and inject extra context, but it cannot block or modify the invocation. To deny or rewrite a spawn, attach a PreToolUse hook to the Agent tool itself.
• SubagentStop - fires when a subagent returns. It can validate the output schema, log metrics, and return decision: "block" with a reason to send the subagent back for more work. It does not transform output - use PostToolUse on the Agent tool (via updatedToolOutput) to reshape or redact.

Structured handoff to humans

When an agent escalates to a human, remember the constraint that trips up so many designs: the human agent does not have access to the conversation transcript. They see only the handoff summary. If a field is empty or a placeholder, the human must make the customer repeat everything. A complete handoff carries all of:

1. 1Customer ID - so the human can pull the account immediately.
2. 2Conversation summary - what the customer wanted and what the agent tried.
3. 3Root cause analysis - the agent's assessment of the underlying issue.
4. 4Refund amount (if applicable) - a specific figure, never vague.
5. 5Recommended action - exactly what the human should do next.

# PreToolUse gate: process_refund is blocked until identity is verified.
def pre_tool_use(tool_name, tool_input, session):
    if tool_name == "process_refund":
        if not session.get("verified_customer_id"):
            return {
                "decision": "block",
                "reason": "Customer identity not verified. Call "
                          "get_customer first.",
            }
    return {"decision": "allow"}

One more handling note: for compound requests ("return my order, update my address, and check my loyalty points"), decompose into distinct items, investigate them in parallel using shared account context, and synthesize a single unified response. Handling one item and forgetting the rest, or spinning up separate sequential conversations, both fail the requirement.