How to let users take actions with AI in your app

Most “AI in your product” projects start as retrieval: index the docs, answer questions about them, ship. It works, and then the first user asks the assistant to actually do the thing, and you discover that the interesting half of the problem was the half you skipped.

The gap is not model capability. Every current model will call a function you describe to it. The gap is everything around that call: who it runs as, what it is allowed to touch, whether a human saw it coming, and how you know afterwards that it happened.

Tools, not database access

The tempting shortcut is to give the agent a connection string and a schema. Do not. Your product already has an API with authorisation, validation and business rules in it, built over years, and an agent with its own database connection needs a second copy of all of that. The copy is what drifts, and it drifts silently, because nothing fails when the two disagree. It just does the wrong thing.

Route every action through the same API your own front end calls. You get the rules for free and you get them permanently.

The agent runs as the user, never as a service account

This is the decision that saves you a permission system. If the tool executes in the signed-in user’s own session, carrying the credential they already hold, then your API makes exactly the same authorisation decision it makes for any other request from that person. There is nothing new to keep in step. If they cannot do it without the assistant, they cannot do it with the assistant, and you did not have to write that rule down twice.

A service account is the alternative, and it means the agent can do more than the person talking to it. Every guard after that point exists to claw back the authority you just handed out.

Classify every tool before you switch it on

Split your tools into reads and writes on day one, because they deserve completely different treatment. Reads can run freely: the worst case is a wasted call. Writes change something a person will have to undo. Treat destructive as a third class again, because deleting is not merely writing with a different verb.

In practice this means the safe starting configuration for any product is every read switched on and every write switched off, and the founder turning writes on deliberately, one at a time, once they have watched the reads behave.

Fewer tools than you think

Accuracy falls as the tool list grows. Each additional entry is another chance for the model to pick a near-miss, and near-misses are worse than refusals because they look like answers. Start with the handful of actions your users ask for most, which for most B2B products is creation, assignment and access management, and add more when you can see people asking for them.

The hard part: reporting failure honestly

Here is the failure that matters most, and it is not a security failure. A tool call times out, or is denied, or never runs at all, and the model summarises the turn as though it worked. The user believes the thing is done. They find out it is not done later, in the worst possible way, and the trust you were building with the whole feature is gone in one message.

The fix is structural rather than conversational. Record the outcome from the API response, not from the model’s account of it, and treat those as two different facts, because they come apart exactly when it matters. Then instruct the model that it may only report an action as complete when the tool returned successfully. A failure reported honestly costs a user thirty seconds. A success reported falsely costs you the user.

What this looks like assembled

A user types a request. The model picks a tool from a short, classified list. If it reads, it runs in the user’s browser with the user’s credential and the answer comes back. If it writes, the interface stops and shows a confirmation naming the real arguments, and nothing happens until a human clicks it. The outcome, verified from the response, goes into a log with who asked and what came back. The model gets told what actually happened and says so.

None of that is model work. It is all product work, and it is the reason an in-product agent either becomes something users trust or something they try twice.