Scenario: Customer Support Agent

The full picture

An agent talks to a customer and uses tools. It handles returns, billing disputes, and account issues. It can also hand the case to a person. The exam tests one skill above all: when to escalate. It also tests the loop, the tool design, and the memory around that choice. Money limits are not a prompt job. Hooks and code enforce them. Every section below hangs on this one flow.

flowchart TD
    IN[Customer message] --> LOOP[Agent loop]
    LOOP -->|stop_reason is tool_use| TOOLS[get_customer<br/>lookup_order<br/>process_refund]
    TOOLS --> LOOP
    HOOK[Hook checks hard limits] -. blocks bad calls .-> TOOLS
    LOOP -->|stop_reason is end_turn| CHECK[Orchestration code<br/>checks the outcome]
    LOOP --> ESC[escalate_to_human<br/>structured summary]
    CHECK -->|still unresolved| ESC
    CHECK -->|resolved| DONE[Done]

The cast: four tools

Those grey boxes in the diagram are real tools. Here is the set the exam uses.

The agent resolves what it can. It escalates the rest.

When to escalate

The first three tools solve most cases. The skill is knowing when to stop and use the fourth.

flowchart TD
    A[Customer message] --> B{Asks for a human?}
    B -- Yes, angry, repeated --> E[Escalate now<br/>with conversation history]
    B -- No --> C{Within agent authority<br/>and policy?}
    C -- No --> E2[Escalate with<br/>structured handoff]
    C -- Yes --> D[Resolve with tools]
    D --> F{Tool fails or<br/>stuck, no progress?}
    F -- Yes --> E2
    F -- No --> G[Done]

The exam likes one reliable trio of triggers.

1. The customer requests a human.
2. The issue needs a policy exception. It goes past the agent's authorization.
3. The agent cannot make progress.

One nuance. Sometimes the fix is instant and the customer is only frustrated.

• Acknowledge the frustration.
• Say you can fix it right now.
• Offer both paths: finish it now, or escalate.
• The customer chooses.

The escalation handoff

You decided to escalate. Now the shape of the handoff decides the score.

• A handoff is a structured summary.
• Include the customer ID.
• Include the root cause.
• Include the amount.
• Include the recommended action.
• Never dump the raw transcript.
• When the customer demands a human, escalate with the conversation history.

Hard limits belong in code

A clean handoff does not stop a bad refund. Limits need real enforcement.

• Prompts cannot guarantee behavior.
• An agent may process a refund above the compliance limit anyway.
• A hook intercepts the tool call.
• The hook blocks it or escalates.
• Example limit: refunds over $500.
• A refund past the agent's authorization goes to escalate_to_human.

The agent loop and stop_reason

Hooks guard one call. Now look at the loop that makes all the calls.

• A tool result joins the conversation.
• The model reasons about what to call next.
• No fixed rule table picks the next action.
• Your loop code checks stop_reason.
• Keep going while stop_reason is tool_use.
• Stop when stop_reason is end_turn.
• The loop can hit max_turns with nothing resolved.
• Then orchestration code checks the outcome after the loop.
• If it is unresolved, the code escalates programmatically.

Tool design that prevents mistakes

The loop is only as good as the tools it picks from. Three fixes come up again and again.

• An agent can invent a plausible order_id.
• Fix that in the tool description.
• Write: "order_id must come from a prior lookup_order call, never invented".
• An order response can carry 40 fields.
• That bloats the context.
• Trim tool outputs to the relevant fields only.
• Too many overlapping tools confuse the agent.
• Consolidate semantic duplicates.
• Example: one resolve_compensation tool with an action parameter.

Errors and timeouts

Tools also fail. The agent needs a clear signal about what to do next.

• Return structured errors.
• Add errorCategory: transient, validation, or permission.
• Add isRetryable.
• Without those fields, retries and escalation stay inconsistent.
• process_refund can time out mid-case.
• Tell the customer what was confirmed.
• Acknowledge the system issue.
• Offer escalation or retry.

Memory across turns and sessions

Some failures are not about tools. They are about what the agent still knows.

• The agent forgets earlier verification answers.
• Cause: history is not passed back in later API requests.
• A customer returns hours later.
• The old session holds stale tool results.
• Start a new session.
• Inject a structured summary of the earlier interaction.
• Make fresh tool calls for current data.
• One long session can cover three issues.
• A later question about issue #1 needs facts, not scrolling.
• Persist structured issue data outside the transcript.
• Keep the IDs, amounts, and statuses.

What gets tested

Here is the whole lesson as a lookup table. Every row is an exam pattern.

Traps

Wrong answers repeat too. Learn these four.

• ❌ "Ask the customer to explain more" when they already demanded a human.
• ❌ "Escalate everything" or "never escalate". Both extremes are wrong.
• ❌ Passing the entire raw transcript as the handoff.
• ❌ Enforcing money or compliance limits in the system prompt only.

Recap

• The agent uses get_customer, lookup_order, process_refund, escalate_to_human.
• It handles returns, billing disputes, and account issues.
• Escalate when the customer asks for a human. Do it before any tool call.
• Escalate when the issue needs a policy exception or goes past authorization.
• Escalate when the agent cannot make progress.
• Instant fix plus a frustrated customer: acknowledge, say you can fix it now, offer both, let them choose.
• A handoff is a structured summary: customer ID, root cause, amount, recommended action.
• Never send the raw transcript as the handoff.
• An angry or repeated demand escalates with the conversation history.
• Hooks or code enforce hard limits, like refunds over $500. Prompts cannot.
• A hook intercepts the tool call and blocks or escalates it.
• Tool results join the conversation. The model decides the next call.
• Loop while stop_reason is tool_use. Stop at end_turn.
• After max_turns with no result, orchestration code escalates.
• Stop invented IDs in the tool description: order_id must come from a prior lookup_order call.
• Trim 40-field tool outputs to the relevant fields.
• Merge overlapping tools into one, like resolve_compensation with an action param.
• Structured errors carry errorCategory (transient, validation, permission) and isRetryable.
• On a process_refund timeout: report what was confirmed, acknowledge the issue, offer escalation or retry.
• Forgotten answers mean the history is not passed back in later API requests.
• A customer who returns hours later gets a new session, a structured summary, and fresh tool calls.
• Keep structured issue data outside the transcript for multi-issue sessions.