Agentic chatbots for customer support

We build support chatbots that can take an action, not just answer a question. Each one gets a written list of what it may do on its own and what it must escalate, it says so plainly when it does not know, and it is tested against people trying to break it before it meets a customer. The code is yours.

One we built was asked to hand over its backend.

It was on a service company's site, answering visitor questions about recruitment, marketing and IT work. Someone tried prompting techniques, then code, to get it to reveal what was behind it. It refused, logged the attempt, and flagged it for a person. Nobody was watching at the time. It held because that exact failure had been designed for months earlier, while the thing was still a diagram.

That bot is still running.

What is an agentic chatbot?

An agentic chatbot is one that can do something on your systems, not only reply. It reads what the customer wants, checks the real state of an order or an account, takes an action it has been permitted to take, and hands over to a person when the request falls outside its boundary.

A chatbot that can only answer from a help centre is a search box with manners. Useful, much cheaper, and a different product. The moment it can change something, the questions that matter change with it.

What should it be allowed to do on its own?

Less than you would expect, written down before anything is built.

The list has two columns: actions it may take without asking, and actions it must escalate. Issuing a refund sits in a different column from drafting one for approval. Cancelling an order sits in a different column from flagging a cancellation request. Every capability you grant is one that fires on the day the model misreads someone, and the damage is whatever you connected it to.

OWASP ranks this sixth in its 2025 Top 10 for LLM Applications as Excessive Agency: systems handed more autonomy, permissions or tools than the task needs. It is the failure that looks like nothing until it looks like a refund run.

Where does your customer data go?

We tell you, in writing, before it goes anywhere.

Which model handles the conversation. Which provider stores it and for how long. What is sent to a third party and what never leaves your systems. Whether anything is retained for training. Most of a support chatbot's value is in the conversations it holds, and those are your customers' words about your business.

This is the part that is easy to skip and hard to unwind. The longer version is here, and it is the same discipline whoever builds the thing.

What happens when someone attacks it?

It refuses, logs what was tried, and tells someone. That is the design goal, and it is the one thing you cannot bolt on afterwards.

Prompt injection is first on the OWASP list for a reason: input that changes what the model does, in ways the person who built it never intended, and it does not have to look like an attack or even be readable by a human. A support bot is an unusually exposed place for it, because its whole job is to accept whatever a stranger types.

Testing that is a specific exercise rather than a vibe. We run it against every bot we build, and we run it against systems other people built, which is a separate two-week piece of work that ends in a written report.

What does it cost to run?

The build is priced on what the bot has to reach and what it is allowed to do. An agent that answers from your help centre is a smaller project than one that looks up orders and issues refunds.

After that, the code is yours: the repository, the documentation and deployment access. It runs on infrastructure we manage, and one yearly fee covers maintenance, hosting and the AI usage behind it. Stop paying it and you keep the code, but it stops running until you host it somewhere else.

Tell us the three questions your support inbox answers most often, and we will tell you which of them a bot should be allowed near.