Order management
Order questions are high volume, low complexity, and completely dependent on live data. They are the clearest case for an agent — and the clearest case for strict per-customer scoping.
The problem
Customers ask where their order is; answering means a person looking it up. Letting AI look it up means guaranteeing it can only see that customer’s orders.
How it is built
- Scope the assistant to the signed-in shopper
Token exchange binds the run to one end user inside one host tenant. The agent cannot widen that.
- Publish order and inventory reads
Status, tracking and stock. No writes at all is a perfectly good configuration here.
- Gate changes if you allow them
Address changes and cancellations are proposed and approved, with the exact change shown.
What you get
- Routine order questions answered without a ticket.
- Escalations that arrive with the context already attached.
- No cross-customer data exposure, enforced below the application layer.
What keeps it safe
- Row-level security isolates tenant data in the database.
- The agent’s identity comes from the token, not the conversation.
- Every provider request is recorded in the run trace.
Publish the read actions, run it for a few weeks, and read the traces. Deciding which writes to publish from evidence is both safer and a much easier internal conversation than deciding from a roadmap.
Questions
What stops a customer asking for someone else’s order?
The scope is not something the conversation can change. The run is bound to an identity resolved from the exchanged token, and the data layer enforces it regardless of what is asked.
Build beyond the expected.
Create a workspace, register an application, and import your first API.