There is a question behind every serious conversation about AI connections, usually once the opportunity has landed and the practical mind takes over:
“What happens when it gets something wrong in front of a customer?”
It is the right question. It is also the one most vendors answer badly, either with reassurance that explains nothing, or with technical detail that answers a question nobody asked.
Here is the honest version.
Why the stakes feel higher, because they are
A chatbot that answers badly is embarrassing. An assistant that acts badly is a different matter. It might confirm a booking you cannot honour, quote a price you withdrew last month, or promise a delivery window you do not offer.
That difference is real, and it is exactly why the first thing we design is not what the assistant can do. It is what it cannot.
Permission is the design, not a setting
On most software, permissions are a configuration screen someone visits after the build. Here it is the opposite. The permission model is the build: everything else follows from it.
We work through your customer journeys and sort every action into three tiers:
Acts on its own. Low-risk, high-volume, easily reversible. Answering your opening hours, checking whether a slot is free, capturing an enquiry, explaining the difference between two products. If this goes wrong, the cost is a mild inconvenience.
Confirms first. Anything that commits you. A booking that blocks capacity, an order above a threshold you set, a discount, a change to an existing appointment. The assistant prepares it; a person releases it.
Never touches. Anything you decide is human-only, and everything nobody thought to authorise. This is the important half: the default is no, not yes. An action nobody explicitly approved does not happen.
Where the lines sit is your decision, not ours. Many businesses prefer to start conservatively and widen the first tier once they have watched it work.
It works from your information, not its own impressions
A general AI assistant answering questions about your business is guessing from whatever it absorbed about businesses in general. That is where invented answers come from.
A connected assistant queries your actual systems: your live availability, your current prices, your real stock, your published policies. It is not recalling what it thinks is true about your business. It is reading what is true, at that moment.
That single change removes most of what people mean when they worry about AI “making things up.”
“I don’t know” is a feature
We design explicitly for the edges. When a customer asks something outside what the assistant can verify, the correct behaviour is not a plausible-sounding guess. It is to say so and hand over to a person, with the conversation attached so the customer does not repeat themselves.
An assistant that admits its limits is more trustworthy than one that never does, and customers can tell the difference immediately.
You sign it off before it goes live
Before anything is connected, you receive the permission rules in plain language: what the assistant may do alone, what needs you, what it will never attempt, and where it escalates. Not a technical specification: a document you can read and disagree with.
Nothing goes live until you have.
We test against your real scenarios, not ours
We agree test scenarios with you in writing before we build, drawn from situations your business actually encounters, including the awkward ones. The double booking. The customer asking for something you stopped offering. The request that should always reach a human.
That agreed list is also how the build is signed off: it is not finished until it passes those scenarios.
You can see what it did
Every action is logged and reviewable. If a customer says “your system told me X”, you can check what actually happened rather than reconstructing it.
That matters for trust, and it matters practically: the log is how you spot a rule that is too tight, or too loose, in the first fortnight.
When something does go wrong
It will, occasionally, in the way any system does. What matters is the blast radius, and that is what the design controls.
An assistant restricted to reversible actions produces recoverable mistakes. One given open authority produces expensive ones. This is why we start narrow and widen deliberately, not because the technology is fragile, but because trust should be earned in the right order.
You can also change the rules, or switch a connection off entirely, at any time. It is your business.
Why control makes it more useful, not less
It is tempting to read all of this as friction, as though the safest connection is the one that does least.
The opposite is true in practice. A business that knows exactly what an assistant will and will not do lets it handle far more, because the boundaries are understood. The businesses that end up restricting AI most severely are the ones that deployed it without deciding those boundaries first, then got a surprise.
Clear limits are what make delegation possible. That is as true of software as it is of people.
Where to begin
An agent-readiness audit includes exactly this conversation. We map your journeys, identify where an assistant could act, and, just as importantly, where it should not.
You get a written report either way, and if we think the risk outweighs the return for your business right now, we will say so.
Free worksheet: Your first three WebMCP tools (PDF). Pick the three jobs on your website to make ready for AI agents first. No email needed.
Leave a Reply