Lesson 28 / 29

Case Study: A Customer-Support Agent Team

Design a supervised team with approvals, memory and limits.

The design

Goal: handle support tickets with a team of agents. Entry: a classify node (small model) labels the ticket billing, technical or other. Supervisor: routes to workers via Command(goto=...) and ends when resolution is set or after 8 steps. Workers: billing (tools: get_invoice, propose_refund), technical (tools: search_docs, get_account_status), writer (drafts the reply from verified facts only). Approval: any refund above a threshold hits interrupt() for a human, with the proposed amount and evidence shown. Memory: Postgres checkpointer with thread_id from the session; a store keeps the customer's language and plan; long histories are trimmed with a summary. Reliability: retry policy on tool nodes, error field in state routing to a human queue, recursion limit 25, per-run cost cap. Testing: scripted-model tests for every route and the cap; a 100-ticket evaluation set scoring outcome, tool trajectory and safety; tracing with redaction. Security: least-privilege read-only tools except propose_refund, validated arguments, ticket text treated as data.

A bounded, resumable, observable agent

State, routing, tools, memory, approval and tests combine into a dependable agent system.

Four habits: bound, persist, approve, test.
Figure 8.1 — Bound, persist, approve and test.

The design on one page

Each line maps to a section of this course.

START -> classify -> supervisor <-> {billing, technical} -> writer -> supervisor -> END   (Sec 1, 2, 6)
billing.propose_refund -> interrupt() -> human approves / rejects                                    (Sec 5)
state: messages (add_messages), route, resolution, error, hops (counters)                            (Sec 1)
memory: Postgres checkpointer (thread_id from session) + store for language/plan; trim+summary       (Sec 4)
limits: step cap 8, recursion_limit 25, retry policy on tools, cost cap per run                       (Sec 2, 3, 5)
quality: scripted tests per route; 100-ticket eval (outcome + trajectory + safety); traces           (Sec 7)

Quick check: Why is the refund step behind an interrupt?

  • Interrupts make tools faster
  • It is costly and irreversible, so a human should approve it
  • Refunds are free
  • To avoid state
Answer

It is costly and irreversible, so a human should approve it — Human approval limits the damage of a wrong or manipulated action.