Making a support bot stay in its lane

The first thing anyone does with a chat widget that has an AI behind it is try to break it. Ask it for a recipe. Ask it to ignore its instructions. Ask it what model it is. zingxo’s assistant has to be useful about your business and useless about everything else, and it has to stay that way when a visitor is actively trying to pull it off topic.

Three layers, in order

The prompt the model sees is assembled from three parts that are never mixed.

Platform rules come first and are the same for every site. They say what the assistant is, that it only discusses the business it is installed on, that it declines anything else briefly and without apology, and that it offers a human when it cannot help. The site owner cannot edit these.

Owner knowledge comes second, wrapped in delimiters and labelled as data. This is the knowledge base the owner wrote: opening hours, return policy, product descriptions. The rules above it say to treat this block as facts to answer from, not as instructions to follow, so an owner who pastes “ignore the rules above” into their FAQ does not get a jailbroken bot.

Visitor messages come last, also labelled as data. The model is told that nothing in this block can change its role.

This is not bulletproof; nothing with a language model in it is. But it moves the problem from “can a visitor out-argue the system prompt” to “can a visitor out-argue three layers that each say the lower layers are data”. In testing that holds up against the usual tricks and most of the unusual ones.

Tools that fetch, not tools that act

Owners can register HTTP endpoints as tools: an order status lookup, a stock check, a booking availability query. The assistant calls them when a visitor asks something the knowledge base cannot answer.

Every tool is read-only by design. There is no “cancel order” tool and there will not be one, because a tool that acts is a tool that can be talked into acting. Tools that only fetch can at worst return data the owner chose to expose.

The endpoints are called from the zingxo server, not the browser, with headers the owner configured and which are stored encrypted. Private and loopback addresses are blocked so the tool cannot be pointed at the owner’s own internal network. Results are cached for a short time so a chatty visitor does not hammer the owner’s API.

The trace

Every AI reply stores the list of tool calls it made, with arguments and the returned data. The owner sees this in the inbox next to the reply. When the bot says something wrong, the trace shows whether the knowledge base was wrong, the API returned something unexpected, or the model made it up. Most “the bot lied” reports turn out to be the first one.

Handing over

There is one tool that is not a fetch: handoff_to_human. The model calls it when the visitor asks for a person or when it has declined the same request twice. The widget tells the visitor someone will reply, the conversation is flagged in the inbox, and the assistant stops answering in that thread until a human hands it back. Owners can turn the assistant off per site entirely and use zingxo as a plain chat widget, which some do.