Answers that can’t lie: grounding an AI agent in real orders
A support agent that guesses is worse than no agent at all. How we bound every answer to order data, live inventory and the customer’s own history.
Ask a general-purpose chatbot where an order is and it will produce something confident. It will have the shape of an answer — tracking-ish language, a plausible number of days, a reassuring close. What it will not have is your order, because it cannot see it. The failure is not that the answer is sometimes wrong; it is that nothing about the answer was ever connected to the truth.
A support agent for a store has to be built so that this failure is structurally impossible, not merely discouraged. Here is how CartBuddy does it.
Deterministic first, generative second
Most of what shoppers ask has a factual answer that lives in the store’s own data: where is my order, when does the return window close, is the large back in stock, how much is delivery to Scotland. For those, the model is not asked to answer at all. The question is routed to the record, and the record’s fields — fulfilment status, carrier, tracking number, promised date — are placed verbatim into the reply.
The model’s job in these exchanges is wording, not facts. It can make the answer polite and complete; it cannot invent the tracking number, because it never sees a conversation where one is missing. This is why the same question asked twice gets the same answer, and why the answer is cheap: no model call happens at all.
The agent may only claim what a tool returned
Questions that do need the model — sizing advice, a recommendation, a bundle — are bounded differently: every claim the reply makes about the store has to have come from a tool result in that conversation. The agent can offer the medium because the inventory tool said there are six; it can suggest the bundle because the cart API priced it. If a tool did not return it, the reply cannot assert it.
When nothing grounds the answer — a question the data cannot resolve — the honest move is to say so and hand the conversation to a human with the full history attached. Merchants tell us this is the behaviour they trust most, which tells you something about what chatbots have done to their inboxes.
Why platform focus is what makes this possible
None of this is a clever prompt. It is access: the app can read fulfilment and inventory because it is built for one platform’s APIs, and it can act — apply the discount, start the exchange, add the size — because those APIs are the same ones your theme uses. A widget that supports every platform equally can read none of them deeply, and its answers will always be shaped like guesses.