Build an E-Commerce Support Agent
The example wasn't chosen by chance. An online-store support agent is narrow enough to implement reliably and rich enough to study on it RAG, personal data, tool calling, approvals, multi-turn state, and handoff - everything a real agent is made of. From here the whole book builds exactly this one.
One typical scenario shows how the parts fit together.
Customer: Order AB-10492 arrived with damaged packaging.
Can I get a refund?
Agent: policy_search("damaged package refund")
order_read("AB-10492")
refund_preview("AB-10492", "damaged_package")
System: Shows a card:
Refund 42.00 USD to the original payment method.
The preview is valid for 10 minutes.
Customer: Clicks "Confirm refund".
Server: Checks actor, preview, order version, and idempotency.
Executes the refund with no new model call.Note: the model runs the conversation and prepares the calculation, but the refund is executed by the server after the button press - with no new model call. This is the main boundary in action.
Which intents the agent supports and what each one ends with is convenient to keep in one table.
Intent · Tools · Final outcome
- A general rules question - policy_search; answer with citations
- The status of a specific order - order_read; answer or a clarification
- A possible refund - policy_search, order_read, refund_preview; approval_required
- An unclear or conflicting case - handoff_prepare; handoff_required
Behind these outcomes sit explicit SLOs, and it's worth fixing them before code. Quality SLO: no promise without an active source, ownership is checked for every order. Product SLO: the p95 of a successful read-only answer fits the given latency budget. Risk SLO: no refund commit ever arises from the model's tool call. The first and third are about trust, the second about speed.
The example's skeleton is clear. We'll start filling it where the agent gets facts about the rules - with RAG, which returns evidence, not a new prompt.