What changes between an assistant that answers questions and one that acts on your systems — and what has to be in place before it is allowed to.
The step change
An assistant that answers questions is a text problem. An assistant that can call a tool is a systems problem, and the difference is not incremental. The moment a model can invoke a function against your infrastructure, it is an actor in your environment with whatever permissions you handed it.
The mechanics are straightforward. The client tells the model what tools exist and what arguments they take; the model, mid-response, emits a request to call one; the client executes it and returns the result; the model continues with the answer. The model never touches your system directly — your code does, on its instruction.
That last sentence is the whole security posture. The model proposes; your code disposes. Everything worth engineering is on your side of that line.
Tool descriptions are the interface
The description you write for a tool is not documentation. It is the only thing the model has to decide whether and how to call it, which makes it part of the prompt and subject to the same discipline.
Be specific about what the tool does, what each argument means, what units it expects, and — crucially — when not to use it. A vague description produces a model that calls the tool in situations you never intended, with arguments it guessed. Two tools with overlapping descriptions produce a model that picks between them at random.
Keep the surface small. Ten well-described tools work better than forty, because the model is choosing from a list and a long list is a harder choice. If a workflow needs many steps, expose the workflow as one tool rather than the steps.
The model is not reading your code. It is reading the sentence you wrote about your code.
Run it read-only for longer than feels necessary
The first deployment should be able to look and not touch. Not as a formality — as observation. You want a log of every tool call the agent attempted, in production, against real questions from real users, before anything can change state.
That log is consistently the most useful artefact of the whole project. It shows which tools get called for questions you did not anticipate, which descriptions are being misread, and which retrievals come back empty. It is also the honest answer to "is this actually useful", which is worth establishing before you take on the risk of writes.
What must exist before write access
Confirmation on anything consequential. For actions with real effect, the agent proposes and a person approves. The approval should show exactly what will happen, not a summary of it.
An audit trail outside the conversation. Who asked, what the model proposed, what was executed, what came back, and when. Written where it survives the session, in a form your existing operations processes already read. A chat transcript is not an audit trail.
Its own identity and permissions. The agent gets a service account scoped to what it actually needs. Not a shared credential, and not an administrator's. When something goes wrong you need to be able to answer "what could it have reached", and that answer should be short.
A way to turn it off. One switch, known to the operations team, that stops tool execution without redeploying anything.
None of this is specific to AI. It is what you would require of any automated actor with credentials to a production system. The novelty is only that the thing deciding which call to make is a language model, which makes the reasoning harder to predict — and the audit trail correspondingly more valuable.
Written by the software delivery team. Published articles carry a named author once attribution is confirmed.
