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. What Task 1.4 is testing
Task Statement 1.4 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 |
Exam trap:
Few-shot examples and a "stronger system prompt" both improve the odds.
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_customerentirely and callslookup_orderusing 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_orderandprocess_refunduntilget_customerhas returned a verified customer ID.- B) Enhance the system prompt to state that verification via
get_customeris mandatory before any order operation.- C) Add few-shot examples showing the agent always calling
get_customerfirst.- 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.
Cross-reference: hooks (D1.5)
Gates are implemented as hooks. The critical timing detail:
| 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) |
Exam 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 (§7) |
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 |
Exam 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):
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:
| 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 |
Exam 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:
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. Common exam anti-patterns
| Anti-pattern | Why it is wrong |
|---|---|
| "Strengthen the system prompt" to enforce ordering | Probabilistic; cannot remove the non-zero failure rate on a financial control |
| Add few-shot examples to force a tool sequence | Improves odds, still no guarantee; adds token overhead |
| Routing classifier to fix tool ordering | Routing controls tool availability, not the sequence in which they run |
Use PostToolUse to block a refund |
Fires after execution — too late to prevent the action |
| Store "customer verified" only in conversation text | Not authoritatively checkable; can be lost or hallucinated |
| Handoff = "customer has a billing problem" | Not self-contained; human lacks the transcript |
| Tell the human to read the chat history during handoff | Human does not have access to the conversation transcript |
| Start separate conversations per concern | Loses shared context; forces repeated verification |
| Treat a paused/awaiting-input workflow as "done" | Paused awaiting external action ≠ completed |
| Rely on a bigger model/context window to fix skipped steps | Capability does not equal a deterministic ordering guarantee |
Scenario-Based Questions
Q1. The 12% skip problem
Production data shows that in 12% of cases the agent skips get_customer and calls lookup_order with only the customer's stated name, sometimes issuing incorrect refunds. What most effectively fixes this?
A. Add a programmatic prerequisite (hook) that blocks lookup_order and process_refund until get_customer returns a verified customer ID
B. Strengthen the system prompt to make verification mandatory
C. Add 5–8 few-shot examples of correct ordering
D. Add a routing classifier that enables only the right tool subset
Answer
A. Critical business ordering with financial consequences requires deterministic enforcement; a gate guarantees the sequence that prompts (B, C) only make more likely, and routing (D) addresses tool availability, not ordering.
Q2. Guidance vs. enforcement
Which statement best captures the difference between a system-prompt instruction and a PreToolUse gate?
A. They are equivalent if the prompt is detailed enough B. The prompt enforces; the gate only guides C. The prompt guides probabilistically; the gate enforces deterministically D. Gates are only for formatting, prompts are for security
Answer
C. Prompts have a non-zero failure rate (probabilistic guidance); a code gate makes the unsafe path impossible by construction (deterministic enforcement).
Q3. Wrong hook for the job
A team implements refund blocking using a PostToolUse hook. What is the flaw?
A. PostToolUse cannot read tool arguments
B. PostToolUse fires after execution, so the refund has already happened
C. PostToolUse only works for subagents
D. There is no flaw; this is correct
Answer
B. Blocking must happen pre-execution. PostToolUse runs after the tool executes and is suited to transforming results, not preventing actions.
Q4. Where verification state belongs
An agent must verify identity before refunds. Where should "customer verified" be stored?
A. As a sentence in Claude's conversation history B. In explicit workflow/application state that a gate checks C. In a closing summary paragraph D. In a Markdown formatting rule
Answer
B. Authoritative, high-stakes state must be machine-checkable in code/DB so the prerequisite gate can read it; conversation text is not reliably checkable.
Q5. The weak handoff
A support agent escalates with the message: "Customer has a billing problem." Why is this inadequate?
A. It is too technical B. It is not self-contained — the human lacks the transcript C. It should be written in XML D. It should include the model's full chain of thought
Answer
B. The receiving human has no access to the conversation, so the handoff must carry customer ID, summary, root cause, amount, actions taken, and a recommended action.
Q6. Required handoff fields
Which set best represents a strong escalation handoff?
A. Just the customer's name and "needs help" B. Customer ID, conversation summary, root-cause analysis, amount, actions already taken, recommended action C. The entire raw chat transcript only D. The model's confidence score only
Answer
B. A complete handoff is self-contained and decision-ready, giving the human everything needed to approve or deny without re-investigating.
Q7. The multi-concern request
A customer says: "Return my order, update my address, and check my loyalty points." What should the agent do?
A. Answer only the first concern B. Open three separate unrelated conversations C. Decompose into concerns, investigate independent items in parallel on shared context, synthesize one response D. Escalate immediately to a human
Answer
C. Multi-concern requests are decomposed into distinct items investigated in parallel using shared identity/account context, then synthesized into a single unified resolution.
Q8. Why routing is the wrong answer in Q1
In Sample Question 1, why does the routing-classifier option fail?
A. Routing classifiers cannot be built B. Routing controls which tools are available, not the order they execute in C. Routing is more expensive than a gate D. Routing requires a larger model
Answer
B. The agent already has the correct tools; the problem is sequence. Routing addresses tool availability per request type, which is a different problem from ordering.
Q9. AML before transfer
An agent occasionally skips AML checks before money transfers, even though the prompt says "always perform AML first." Best fix?
A. A stronger, more emphatic prompt B. More few-shot examples C. A programmatic prerequisite gate that blocks transfer until AML state passes D. Resume the session
Answer
C. Compliance ordering requires deterministic enforcement; the gate reads authoritative AML state and blocks the transfer until it passes.
Q10. Threshold approval
Refunds above $500 must get manager approval. How should this be enforced?
A. Ask Claude to remember to check the amount
B. A PreToolUse gate that blocks refunds over $500 and routes to a human approval workflow
C. A PostToolUse hook that reverses large refunds
D. A few-shot example showing a $500 case
Answer
B. A pre-execution gate blocks the over-threshold action before it runs and redirects to human approval; reversing afterward (C) means the unsafe action already executed.
Q11. Shared context in decomposition
When decomposing a multi-concern request, why investigate concerns "in parallel using shared context"?
A. To start unrelated sessions per concern B. So identity/account context is gathered once and reused, avoiding repeated verification C. Because parallel work removes the need for gates D. To avoid synthesizing a single answer
Answer
B. The concerns share the same verified customer and account; gathering that context once and reusing it is more efficient and consistent than re-fetching per concern.
Q12. Non-zero failure rate
Why is "make the system prompt clearer" insufficient for an identity-verification control on financial operations?
A. Prompts cannot mention identity B. Prompt instructions have a non-zero failure rate, unacceptable where errors have financial consequences C. Prompts are slower than gates D. Prompts cannot be version-controlled
Answer
B. Prompt guidance is probabilistic; the residual failures are exactly the misidentified-account incidents the control exists to prevent. Deterministic enforcement is required.
Q13. Gate ordering vs. multi-concern decomposition
What is the key difference between prerequisite gating and multi-concern decomposition?
A. They are the same pattern B. Gating orders dependent steps; decomposition handles independent sibling concerns synthesized into one answer C. Gating is for humans; decomposition is for tools D. Decomposition must always precede gating
Answer
B. Gates enforce ordering among dependent steps (verify → refund); decomposition handles independent concerns in parallel, then unifies them — different structural patterns.
Q14. End-to-end architecture
Which architecture best supports a refund-and-escalation support agent?
A. One prompt telling Claude to remember and follow every rule B. Session state for the conversation, external workflow state behind prerequisite gates for verification/thresholds, structured handoffs for escalation, memory only for durable preferences C. Store every tool result in the memory store D. Re-prompt the agent after each customer message
Answer
B. It separates concerns correctly: conversation continuity, authoritative gated business state, self-contained human handoffs, and durable preferences each handled by the right mechanism.
Q15. The retry path after a block
When a PreToolUse gate blocks lookup_order because the customer is not yet verified, what is the ideal behavior?
A. Terminate the session
B. Return a tool error explaining the missing prerequisite so the agent calls get_customer, then retries successfully
C. Silently allow the call anyway
D. Hand off to a human immediately
Answer
B. A good gate is informative: it blocks the unsafe call and signals the missing prerequisite, steering the agent to satisfy it (get_customer) and then proceed — no human needed for the normal path.
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_refunduntilget_customerreturns a verified ID. - B/C = probabilistic, D = availability-not-ordering, A = deterministic ordering.
PreToolUseblocks before;PostToolUsetransforms 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.