Multi-Step Workflows, Enforcement & Handoff

A prompt is a request to do steps in order; a gate is a guarantee. When errors cost money, you do not ask the model to be careful - you make the unsafe step physically impossible until its prerequisite is satisfied.

1. Core Concept

This module covers implementing multi-step workflows with enforcement and handoff patterns. The exam wants an architect who can answer three connected questions:

Ordering - How do you guarantee step A happens before step B when B is high-stakes (refunds, transfers, identity-gated lookups)?
Escalation - When the agent cannot finish, how does it hand off to a human who does not have the conversation transcript?
Multi-concern - When one request bundles several issues, how do you decompose, investigate in parallel, and synthesize one answer?

2. The Core Distinction: Guidance Vs. Enforcement

The single highest-yield idea on this task statement:

Prompts guide behavior probabilistically. Code enforces behavior deterministically.

A system prompt that says "always verify identity before issuing a refund" is a guidance mechanism. The model usually follows it — but "usually" is the problem. Prompt instructions have a non-zero failure rate. At scale, a 1–12% miss rate on a financial control is a compliance incident, not a rounding error.

Mechanism	Nature	Failure rate	Use for
System prompt instruction	Probabilistic guidance	Non-zero	Tone, formatting, preferences, soft heuristics
Few-shot examples	Probabilistic guidance	Non-zero (lower)	Reinforcing patterns, edge-case shaping
Routing classifier	Selects which tools are available	N/A to ordering	Choosing the right toolset per request type
Prerequisite gate / `PreToolUse` hook	Deterministic enforcement	Zero (by construction)	Identity-before-refund, AML-before-transfer, approval thresholds

Trap:

Few-shot examples and a "stronger system prompt" both improve the odd but neither GUARANTEES ordering. If the question says "deterministic", "guaranteed", "compliance", "financial", or "must" — pick the gate, not the prompt.

3. Sample Question 1 — the Canonical Scenario

This scenario appears in the official sample questions and is worth internalizing verbatim.

Scenario: Production data shows that in 12% of cases the agent skips get_customer entirely and calls lookup_order using only the customer's stated name, occasionally misidentifying accounts and issuing incorrect refunds. What change most effectively addresses this reliability issue?

A) Add a programmatic prerequisite that blocks lookup_order and process_refund until get_customer has returned a verified customer ID.

B) Enhance the system prompt to state that verification via get_customer is mandatory before any order operation.

C) Add few-shot examples showing the agent always calling get_customer first.

D) Implement a routing classifier that enables only the subset of tools appropriate for each request type.

Correct answer: A.

Why A beats the others:

Option	Why it loses
B (stronger prompt)	Still probabilistic. The 12% miss rate is exactly the residual a prompt cannot remove. Errors here have financial consequences.
C (few-shot)	Same flaw as B — improves odds, does not guarantee ordering. Adds token overhead.
D (routing classifier)	Addresses tool availability (which tools exist for a request type), not tool ordering. The agent already has the right tools; it is calling them in the wrong sequence.
A (prerequisite gate)	When a specific tool sequence is required for critical business logic, programmatic enforcement provides deterministic guarantees that prompt-based approaches cannot.

Memorize the discriminators: B/C = probabilistic, D = availability not ordering, A = deterministic ordering. The presence of a financial consequence is the tell that you need a gate.

4. Prerequisite Gates

A prerequisite gate blocks a tool or workflow step until a required condition is true. It is the concrete implementation of deterministic ordering.

process_refund may execute ONLY IF:
- customer_verified == true
- verified_customer_id exists
- order_id is valid and belongs to verified_customer_id
- refund_amount is within the automated threshold
Otherwise: block the call (and, above threshold, route to human approval).

The gate reads from explicit workflow state, not from the model's recollection. For security, money, and compliance workflows, the enforcement points are:

Application-side state checks before dispatching a tool
PreToolUse hooks that block or modify a call before it runs
Permission policies
Human approval steps
External state machines that own authoritative business state

4.1 `hooks`

Gates are implemented using hooks.

Hook	Fires	Can it block?	Correct use
`PreToolUse`	Before the tool executes	Yes	Block a non-compliant action before damage is done — identity gate, threshold check
`PostToolUse`	After the tool executes	No (too late)	Transform/normalize results after execution (e.g., date normalization)

Trap:

Using PostToolUse to "block" a refund is wrong, the refund has already happened. Enforcement must occur PRE-execution. PostToolUse is for data transformation only.

Decision rule for where a requirement belongs:

Scenario	Correct mechanism
"Always verify identity before refund"	Prerequisite gate / `PreToolUse`
"Block lookup until customer verified" (Sample Q1)	Prerequisite gate / `PreToolUse`
"Require manager approval above $500"	`PreToolUse` + human approval workflow
"Transfer only after AML pass"	Programmatic gate on external state
"Normalize dates from heterogeneous tools"	`PostToolUse`
"Format the answer in Markdown"	Prompt instruction
"Escalate an unresolved issue"	Structured handoff

5. The Agentic Loop with a Gate (Worked Example)

User: "Refund my order, my name is Jordan."

1. Agent wants to call lookup_order(name="Jordan")
2. PreToolUse gate fires:
     is workflow_state.customer_verified == true?  -> NO
     -> BLOCK lookup_order, return a tool error:
        "Verification required. Call get_customer first."
3. Agent calls get_customer(...) -> returns verified_customer_id = cust_789
4. Gate updates workflow_state.customer_verified = true
5. Agent retries lookup_order -> now allowed -> returns ORD-456
6. Agent wants process_refund(amount=349.99)
7. PreToolUse gate fires:
     verified? yes. amount within threshold? yes -> ALLOW
   (if amount > threshold -> block + structured handoff to human)

The gate makes the 12% miss path impossible: the agent cannot misidentify an account via lookup_order, because the tool will not run without a verified ID in state.

6. Workflow State Must Be Explicit

A high-stakes workflow cannot rely on Claude remembering which steps it completed. The system must hold workflow progress in explicit, machine-checkable state that gates read from.

{
  "session_id": "case_123",
  "customer_verified": true,
  "verified_customer_id": "cust_789",
  "order_loaded": true,
  "order_id": "ORD-456",
  "refund_amount": 349.99,
  "aml_passed": false,
  "manager_approval_required": false,
  "handoff_required": false
}

State type	Scope	Where it lives	Example
Conversation/session history	Current session	Model context	Current reasoning, tool calls this turn
Workflow state	Application/case	Code / database	`customer_verified`, `aml_passed`, approval status
Memory store	Across sessions	Memory resource	User preferences, project conventions
Handoff summary	Human escalation	Emitted artifact	Self-contained transfer of context

Rule:

Authoritative business state (verified? approved? AML pass?) lives in code/DB,
NOT in a natural-language sentence the model wrote. Gates check the state object.

Anti-pattern: storing "customer verified" only as a phrase in the model's conversation. It is not reliably checkable and can be hallucinated or lost to compaction.

7. Structured Handoff Protocols

When the agent hits a blocking condition it cannot resolve (e.g., refund exceeds the automated threshold, or a policy exception is needed), it must escalate to a human or another system. The key constraint:

The human agent receiving the escalation does not have the conversation transcript. The handoff must be entirely self-contained.

Weak handoff (fails the exam):

Customer needs help with a refund.

Strong handoff — a structured, self-contained summary:

{
  "customer_id": "cust_789",
  "conversation_summary": "Customer reports a duplicate charge on order ORD-456; was billed twice for one fulfilled order.",
  "root_cause_analysis": "Payment records show two captures for one shipment; duplicate capture is the likely cause.",
  "refund_amount": 349.99,
  "actions_already_taken": [
    "Verified customer identity (cust_789)",
    "Loaded order ORD-456",
    "Checked payment records and confirmed two captures"
  ],
  "recommended_action": "Approve a single refund of 349.99 after finance verification.",
  "blocking_reason": "Refund amount exceeds the automated approval threshold"
}

Required fields the exam expects in a handoff summary, example:

Field	Why it matters
Customer ID	Lets the human locate the account without the transcript
Conversation summary	Conveys what the customer asked and the journey so far
Root-cause analysis	The agent's diagnosis, so the human does not re-investigate
Refund amount (or relevant figures)	The concrete decision the human must approve
Actions already taken	Avoids duplicated work and shows what is already verified
Recommended action	Turns the escalation into an approve/deny decision, not an open investigation

Trap:

"Escalate the issue and let the human read the chat" is wrong, the human lacks the transcript. The handoff itself must carry all context.

8. Multi-Concern Decomposition

Customers frequently bundle several requests:

"I want to return my order, update my shipping address, and ask about my loyalty points."

Correct workflow:

1. DECOMPOSE the message into distinct concerns:
     - return order
     - update shipping address
     - loyalty points inquiry
2. Identify SHARED CONTEXT (same verified customer, same account).
3. INVESTIGATE independent concerns in PARALLEL using that shared context.
4. Apply prerequisite GATES where needed (e.g., verify identity before the return/refund).
5. SYNTHESIZE one unified response covering all concerns.
6. ESCALATE any unresolved item with a structured handoff (§7).

Why "shared context" matters: identity verification, account lookup, and policy context are gathered once and reused across all three concerns — not re-fetched per concern.

Wrong approach:

Start three separate, unrelated conversations (one per issue),
losing shared identity/account context and forcing repeated verification.

This is task decomposition applied to a single user turn: the concerns are independent enough to investigate in parallel, but the resolution is unified into one reply. Contrast with prerequisite gating, which is about ordering dependent steps — here the three concerns are siblings, not a chain.

9. Putting It Together — the Reference Architecture

A customer-support resolution agent handling identity verification, order lookup, refunds, multi-concern requests, and escalation should use each mechanism for what it guarantees:

Need	Mechanism
Verify identity before order/refund operations	Prerequisite gate (`PreToolUse`) reading explicit workflow state
Hold "verified / approved / AML passed" authoritatively	External workflow state (code/DB), not prompt text
Block refunds above threshold	`PreToolUse` gate + human approval
Hand off when blocked	Structured, self-contained handoff summary
Handle bundled requests	Decompose, parallel-investigate on shared context, synthesize
Durable user preferences	Memory store (not workflow state)

The exam reward is always separation of concerns: session continuity for the conversation, authoritative state in code, deterministic gates for ordering, structured handoffs for humans.

10. Memory hooks

Prompts guide, code enforces. Financial/compliance ordering = gate, never a prompt.
Non-zero failure rate is the magic phrase that rules out "stronger prompt" and "few-shot."
Sample Q1 = A. Block lookup_order/process_refund until get_customer returns a verified ID.
B/C = probabilistic, D = availability-not-ordering, A = deterministic ordering.
PreToolUse blocks before; PostToolUse transforms after (too late to block).
Workflow state lives in code/DB, not in a sentence the model wrote.
Handoff must be self-contained — the human has no transcript. Carry: customer ID, summary, root cause, amount, actions taken, recommended action.
Multi-concern: decompose → parallel investigate on shared context → synthesize one answer → escalate leftovers with a structured handoff.
Gating orders dependent steps; decomposition handles independent siblings.
Separation of concerns wins: session ≠ workflow state ≠ memory ≠ handoff.

Test yourself on this topic Interactive questions for Task 1.4 — Workflows, Enforcement & Handoff, with instant explanations and scoring.

Start quiz →

Multi-Step Workflows, Enforcement & Handoff

1. Core Concept

2. The Core Distinction: Guidance Vs. Enforcement

3. Sample Question 1 — the Canonical Scenario

4. Prerequisite Gates

4.1 hooks

5. The Agentic Loop with a Gate (Worked Example)

6. Workflow State Must Be Explicit

7. Structured Handoff Protocols

8. Multi-Concern Decomposition

9. Putting It Together — the Reference Architecture

10. Memory hooks

4.1 `hooks`