How the AI support cockpit works
Customer support is mostly the same questions answered with the customer's specific facts. This reads each ticket, pulls the real order context, and drafts a grounded reply for a human to approve. The model proposes; a person always decides.
A look under the hood: how it grounds a draft in real order data, the two checks every draft passes, and why the model is never allowed to hit send.
The short version
It reads new tickets from your helpdesk, works out what each customer actually wants, pulls the real order facts from your store, and drafts a reply grounded in those facts. Every draft lands in a review queue with the order context and a grounding check attached. A person approves, edits, or rejects it. The system is built so the model can only ever propose: the decision to send lives in code, behind a human, not in the model.
That's the design. The rest of this page is how each stage works, and why "the model never sends" is the load-bearing rule, not a nice-to-have.
It drafts from real order facts, not generic FAQ text
When a ticket arrives, a fast classifier labels the intent (shipping status, return, refund, sizing, product question, complaint, and so on). If the ticket references an order, the system looks up that order read-only from the store and attaches the live facts. The reply is then drafted from those specific facts plus your brand voice, not from a generic template.
This is the difference between a support bot that says "your order should arrive soon" and one that says the actual status of the actual order. Every factual claim in a draft is tied to a fetched fact, with a snapshot of the raw value at the moment it was read. If the fact isn't there, the draft doesn't assert it.
Two grounding checks before a draft is allowed through
Each draft passes a two-part check: a deterministic lint, and a separate model acting purely as a verifier (it judges, it doesn't write). The verdict is green, amber, or red. Green requires both the lint and the verifier to pass. Red blocks the draft from being sendable at all.
The verifier also re-fetches the ticket and the order right before anything can act, so a draft written against a thread the customer has since replied to, or an order value that has since changed, gets caught and held. That "stale thread" case is the classic way auto-reply systems embarrass a brand, and it's closed here by design.
Code owns every write, the model owns none
The model has no tool to send a message and no tool to change any state. Sending is a deterministic code path gated behind an explicit per-intent allowlist, a confidence floor, dedupe, and human approval. This is the single most important design choice: it means the trust boundary is code, not the model's good behavior.
If a draft promises operational work, like issuing a refund, the system creates an explicit follow-up action for a human to carry out rather than doing it silently. Nothing operational happens on the model's say-so.
Built, deployed, and human-in-the-loop by design
This is a working, deployed drafting-and-review system, run deliberately with a human approving every reply. It's honest to say what it is and isn't: it turns raw tickets into grounded, reviewable drafts with full order context and an audit trail per ticket. It is not an autonomous agent that answers customers on its own, and it was never meant to be.
Every ticket becomes one auditable row: the classification, the draft, the grounding verdicts, the facts used, and the human's accept, edit, or reject. Tiered kill switches (full, auto-send, per-intent) exist so the safety posture can be tightened instantly. The point of the whole thing is a support workflow you can trust precisely because a person stays in the loop and the model can't act alone.
The model never sends a message and never changes an order. It drafts; a human approves; deterministic code does the sending. That boundary is the product.