The brief I get most often this year is some version of "we want a chatbot on the site, but one that can actually do things." Book the viewing. File the enquiry. Change the plan. Cancel the order. The founder has usually tried a FAQ bot, watched visitors ask it to do something, and watched it apologise.
An agentic chatbot is the fix, and it is also where most of these projects go wrong. Answering a question is cheap to get wrong. Taking an action on a real account is not. So before I write a single prompt, I sit down with the client and sort every action the assistant might take into buckets. This post is that sorting exercise, with the rules I have ended up with after shipping a few of them.
Sort every action into one of three buckets
The first bucket is reading. Search listings, look up an order, compare two plans, summarise a policy page. If the assistant gets this wrong, the visitor sees a bad answer and asks again. Nothing changed.
The second bucket is writing to your own database in a way you can reverse. Saving a draft, adding something to a shortlist, tagging a lead, scheduling a post for later. A mistake here is annoying but fixable, and the fix is usually a delete.
The third bucket is anything that reaches outside your system. Sending an email to a landlord. Charging a card. Publishing to a connected social account. Cancelling a subscription. You cannot unsend an email, and you cannot un-publish something a thousand people already saw.
On Keyhold, the property assistant lives almost entirely in bucket one. It compares listings, explains coverage, answers questions about the rental process. The one thing it does that matters is start an enquiry, and that is a bucket three action because a real agent reads it. So that single action gets more engineering than everything else the assistant does combined.
If you cannot place an action in a bucket, you are not ready to give the assistant that action.
The model proposes, your code decides
I give the assistant a small set of tools, each with a strict schema. The model fills in the arguments. Then my tool handler treats those arguments exactly the way it would treat a request from an untrusted browser, because that is what they are.
Every handler checks three things before it does anything. Is this user allowed to do this at all? Does the thing they are referring to belong to them? Are the values sane, meaning a real listing id, a date in the future, a message under the length limit? None of those checks live in the prompt. They live in code, next to the same permission helpers the rest of the app uses.
This is the same argument I made in Prompt Injection Is a Permissions Problem. A visitor can paste whatever they like into the chat box. If the only thing standing between that text and your database is a sentence in the system prompt saying "never do X", you have no security at all. The model is a very good intern. It is not an authorisation layer.
Structured output helps here, and the provider docs on tool use are worth reading properly rather than skimming. Schema enforcement guarantees that the arguments are the right shape. It does not guarantee they are correct. A listing id can be perfectly well formed and belong to someone else.
Confirm in the interface, not in the prompt
For bucket three actions I render a confirmation card in the chat. The assistant drafts the enquiry, the visitor sees the exact text, the recipient, and the listing it is attached to, and nothing goes anywhere until they press send. The button calls a normal endpoint. The model is not in the loop for the final step.
This sounds obvious, and yet the first instinct of almost every client is to let the assistant "just do it" because the demo looks smoother. The demo also looks smoother right up until the assistant sends a viewing request for the wrong flat and the visitor has to explain to a letting agent that a robot did it.
On Threadovo the same principle covers publishing. The strategist can plan a month of posts and draft all of them. Pushing a post to someone's actual Instagram or LinkedIn account is a separate step with its own approval, and the approval has a timeout so a workspace that wants full automation can opt into it deliberately rather than by accident. The assistant proposes. A human, or a rule the human set, decides.
If you want a general reference for the categories of risk here, the OWASP Top 10 for LLM applications is the list I point clients at. Excessive agency has its own entry for a reason.
Give your agentic chatbot fewer tools than you want to
The temptation is to expose your whole API. Resist it. My working rule is that every tool should be something I would happily publish as a public endpoint with the same permission checks, and that the assistant should have fewer than ten of them.
Fewer tools means fewer ways to be wrong. It also means the model picks the right one more often, because the choice is smaller. When a client asks for a new capability, the first question is whether an existing tool already covers it with a different argument. Usually it does.
Each tool also gets a cost. Reads are cheap. Anything that calls a third party or generates content is metered, in the same way I described in credit-based billing for AI features. A visitor who finds a way to make your assistant loop on an expensive tool should hit a ceiling, not your invoice.
Log it like a payment
Every tool call gets written to a table before it runs and updated after. Which user, which conversation, which turn, which tool, the full arguments, the result, and how long it took. The log earns its keep on the Tuesday afternoon when a client messages "the bot did something weird for a customer" and you need to reconstruct exactly what happened in under five minutes, with the customer still waiting.
It also gives you the one thing that makes these systems improve over time: a list of every action the assistant proposed that a human rejected at the confirmation step. I read that list once a week. Most weeks it points at a tool description that was vaguer than I thought, and occasionally at an action that should move up a bucket.
What to ask before you hire someone to build this
If you are a founder shopping this out, the questions that separate someone who has shipped one from someone who has watched a tutorial are short.
Ask how they decide which actions need confirmation. Ask where permission checks live, and if the answer mentions the prompt, keep looking. Ask what the assistant does when a tool fails halfway through. Ask to see the audit log from something they built. Ask how many tools it has, and be suspicious of a big number.
You do not need to rebuild your product to add this. The assistant sits beside the app you already have and calls the same code, which is the approach I laid out in how to add AI to your existing web app without rewriting it. The model is the easy part. The work is deciding, action by action, what you are comfortable letting software do in your name.