System Design: Customer Service AI Agent
Explore the system design for LumenPay's customer service AI agent, from request routing to bounded answers and human handoff. Learn how to keep retrieved content from overriding instructions, which refund steps must be deterministic, and what an execution extension would require. Understand what evidence shows what the agent actually did.
We'll cover the following...
- Which component answers each request
- How P-730 becomes a bounded answer
- When a retrieved passage requests P-731 and the connector key
- Deterministic refund handling for U-17
- Requirements for a $20 execution extension
- Evidence that explains what the agent actually did
- Practice: Placing the controls for U-62
Define three tools for LumenPay's support assistant: policy search accepting a query, payment-status lookup accepting a payment reference, and refund-request intake accepting a payment reference and reason. Tool names describe their intended functions, but backend implementations must enforce access permissions and define what each result confirms. Enforce authorisation and financial-action restrictions in backend services, not through model instructions alone. This prevents prompt injection from granting additional access or triggering unauthorised financial operations.
Which component answers each request
The established version-one scope remains policy explanations, authorized payment-status reads, and refund-request intake; financial execution and card-detail collection are excluded. Treat the following interfaces and record identifiers as proposed design choices, rather than verified existing LumenPay APIs.
Choose one orchestrator with bounded model use and three narrow contracts:
Policy search (input: query): A read-only search of approved, published policy, filtered by current document access before content reaches the model. Return relevant passages with document identity, version, and effective-date metadata; bound query length and result count.
Payment-status lookup (input: payment reference): A read-only payment-adapter call. Accept a bounded reference; return only reference, amount, currency, status, and observation time after authorization.
Refund-request intake (inputs: payment reference and reason): A support-case write through a deterministic workflow service and case adapter. Validate the reference and a bounded reason; return a verified case reference and handling state. It performs no payment mutation.
The model interprets requests, proposes a route, and drafts explanations. Backend code validates the route and arguments, while the workflow service controls permitted transitions. The payment service remains authoritative for live payment facts; retrieval supplies policy; the case system supplies handling state. The model is not a system of record.
Grounding provides evidence for an answer; server-side authorization determines which evidence and actions the ...