Last updated: September 22, 2026
Reference bounds
How the customer support agent stays bounded
Level 2 — reference architecture. Risk high. Oversight: approval required.
Look up where-is-my-order, tracking, and return status, then hand off when the case is not a lookup.
Explore, then act, then confirm, then verify. Explore gathers the context for the customer support agent. Act stays reversible. Confirm stops before an irreversible step. Verify is a separate check of the outcome.
- Starts when
- A shopper ticket is one of the repeat status questions.
- Tools
- A write goes through a router, a permission check, a policy check, and a budget check. The model does not commit it. An approval token lives in tool context, not in the user message.
- Stops for a person
- Anything that moves money or changes a fulfilled order is a proposal. A named reviewer acts in the store.
- Checked by
- The answer matches the order and shipment tools. Disagreement or a missing record is a handoff.
- Untrusted data
- The shopper message, including text that tries to authorize a refund.
- If it fails
- If the customer support agent stops, name the reason: completed, budget_exceeded, timed_out, cancelled, guardrail_blocked, approval_required, tool_failure, verification_failed, or partial_completion. Retry a timeout at most twice. Back off on rate limits. After repeated verification failure, escalate. Stop when the budget is exhausted or a permission is denied. No unbounded loop. Anything that moves money or changes a fulfilled order is a proposal. A named reviewer acts in the store.
This is the reference architecture for the page, not a published production deployment. The shared contract is the AWS store-agent architecture. Permissions and data boundaries are in securing store agents.
Monday, the queue is the same question in different clothes. Where is it. Did it ship. Can I return it. The answers are already in the order system, the carrier feed, and the return policy. The work is copying them.
This week the agent does that copy: look up, answer from the record, hand off when the record is wrong or the ask moves money. It does not refund.
A person still signs refunds, cancellations, address changes, and gift cards.
Skip it if an order-status email or a carrier template already closes most of those tickets. That is a fine outcome. You do not need an agent to restate a rule.
This page is the commercial summary. The long build — which lookups, the week-one list, and how you test it — lives in the guides linked below. Those guides keep their own URLs.
Returns and fraud, on this page
“Was it received?” and “did the refund go out?” are the same job as “where is my order”: look up a record, answer from it, hand off when the record is wrong.
Abuse and refund investigation stay a section of this family. They are not a separate page and not a separate product. If the pain is “people keep asking where the label is,” start with where-is-my-order. If the pain is “we are eating fraudulent returns,” read the fraud and refund-investigation guides first. Those are different lookups and a different approval path.
What we will not do in week one
- Give the agent a refund, a cancel, an address change, or a gift card before a named reviewer owns the queue.
- Let it browse the open web “to be helpful” on a tracking question.
- Call a help-center chatbot an agent.
How we start
First question: can the agent join an order to a shipment without guessing? If it cannot, that is a data problem, and we will say so. If it can, the engagement is one scoped agent at eCommerce AI Agents. AWS is how it stays up. It is not the first question we ask you.