What you need to know
Prompt guidance versus programmatic enforcement
There are two ways to make an agent do steps in order:
| Prompt-based guidance | Programmatic enforcement | |
|---|---|---|
| How | "Always verify the customer before looking up orders" in the system prompt | Code that blocks the downstream tool until the prerequisite has succeeded |
| Reliability | High, but not 100%: a persuasive message or an unusual case can skip it | Deterministic: the blocked call cannot run |
| Good for | Preferences, tone, ordering that is nice to have | Rules with legal, financial or security consequences |
When a requirement is deterministic, such as "identity must be verified before any financial operation", a prompt alone has a non-zero failure rate. In production, a 1% failure rate across 50,000 contacts is 500 refunds to unverified callers. The exam expects you to recognise this and choose enforcement in code.
Programmatic prerequisites
A prerequisite gate tracks what has happened in the session and refuses calls that come too early.
verified = {} # session_id -> customer_id, set when get_customer verifies
def gate(session_id, tool_name):
if tool_name in ("lookup_order", "process_refund") and session_id not in verified:
return "Blocked: verify the customer with get_customer first."
return None # allowedIn the Agent SDK this check usually lives in a PreToolUse hook (lesson 1.5), which denies the call and tells Claude why, so Claude can go back and verify.
Multi-concern requests
Customers often raise several problems in one message: a damaged item, a wrong address and missing loyalty points. Handling only the first one and asking "anything else?" damages first-contact resolution. The stronger pattern:
- Decompose the message into distinct items.
- Investigate each against the shared customer context (one verification, one customer record), in parallel where the items are independent.
- Synthesise one reply that resolves or explains each item.
Structured handoff to humans
When the agent escalates mid-process, the human agent usually cannot see the transcript. A handoff that says "customer has a billing issue, please help" forces the human to start again and the customer to repeat themselves. A structured handoff carries what the human needs to act:
| Field | Example |
|---|---|
| Customer ID and verification status | C-118204, verified by email and order number |
| The issue, in one line | Charged twice for order 55107 |
| Root cause found so far | Payment retried after a gateway timeout |
| Amounts and references | $219.90, orders 55107 and 55107-R |
| Actions already taken | Refund of the duplicate requested, rejected: over limit |
| Recommended next action | Approve the $219.90 refund of the duplicate charge |
In the exam
Scenario 1 (customer support) carries most of these. Typical stems: a measured rate of skipped verification, refunds that bypass a rule, a multi-part message handled partially, or human agents complaining that escalations are useless. Choose code-level enforcement for hard rules, decomposition for multi-concern messages, and a structured summary for handoffs.
Check your understanding
In 2% of chats the agent looks up orders before verifying the customer, despite a clear instruction. What is the best fix?
Show answer
Answer: A. A prompt can reduce the skip rate but cannot guarantee it. A programmatic prerequisite makes the out-of-order call impossible.
A customer's message raises a damaged item, a wrong address and missing points. What should the agent do?
Show answer
Answer: C. Decomposing the request and resolving each item against shared context protects first-contact resolution. Escalation is for items that meet a trigger, not for messages with more than one item.
Human agents say escalations from the bot are useless. What should the handoff contain?
Show answer
Answer: B. The human cannot see the transcript, so the handoff must stand alone: who the customer is, what was found, the numbers involved, what was tried and what to do next.
Apply it: Gate Cedar Ridge's refund workflow
Cedar Ridge's finance controller wants proof that no refund can reach an unverified customer, and the support lead wants handoffs her team can act on. Design both.
- List the prerequisites. For each of
lookup_orderandprocess_refund, state what must already have happened in the session. - Say where each check runs and what Claude is told when a call is blocked.
Why: a blocked call with no reason leaves Claude guessing. - Walk one multi-issue message through the workflow. Use: "My tent arrived torn (order 55107), and I never got points for order 54980."
- Write the handoff template for an escalated refund over the $500 limit.
Show model answer
1. Prerequisites
| Tool | Must already be true |
|---|---|
lookup_order | get_customer returned one verified customer ID in this session |
process_refund | Customer verified; the order was looked up in this session and belongs to that customer; amount at most $500 |
2. Where and what. All checks run in a PreToolUse hook on the support server's tools, using session state set by earlier tool results. A blocked call is denied with a reason Claude can act on, such as "Blocked: verify the customer with get_customer first" or "Blocked: refunds over $500 need a human; use escalate_to_human with a handoff summary."
3. Multi-issue walk-through. Verify the customer once. Split into item A (torn tent, order 55107) and item B (missing points, order 54980). Look up both orders. A: within 45 days, refund or replacement offered. B: points were not credited, so credit them or explain why not. One reply covers both items, each with its outcome.
4. Handoff template
| Field | Content |
|---|---|
| Customer | ID, name, how verified |
| Issue | One line |
| Root cause | What the agent found |
| Amounts and orders | Refund requested, order numbers |
| Already done | Tools run and their outcomes |
| Why escalated | Over the $500 limit |
| Recommended action | Approve or reject, with reason |