Autonomy
Tool use (function calling)
Also called: function calling, tool calling
Definition
Tool use is the mechanism by which a model stops producing text and starts taking action — querying a system, writing a record, sending a message.
The moment a model can call a tool, it has left the sandbox. Every tool exposed is a permission granted, and the blast radius of a bad output changes from an embarrassing paragraph to a modified record, a sent message, or a completed transaction. Tool design, not model choice, is where most agentic risk is actually managed, which is why it deserves at least as much design attention as which model sits behind the workflow.
Every tool is an authorisation
Grant the narrowest capability that does the job: read before write, one account before all accounts, draft before send. Broad tools are convenient to build and expensive to govern, because a tool that can do more than the task strictly requires is a standing risk even on the days it is used correctly, since the excess capability is available to be misused by an error, an injection attack, or simple scope creep in how the agent gets used over time.
Injection becomes consequential here
Text a model reads can instruct it, as prompt injection makes clear. Without tools that instruction is noise, producing at worst a strange piece of text; with tools it is a command executed under your credentials, against your systems, with real consequences. This is the single strongest argument for narrow tool scoping: it does not just limit accidental misuse, it directly limits what a successful attack against the model can actually accomplish once it has manipulated the model's output.
Auditing tool calls after the fact
A complete log of what tool was called, with what inputs, producing what outputs, and in response to what triggering context, is what makes an agentic incident investigable rather than a mystery. Without this log, reconstructing why an agent took a specific action becomes guesswork based on incomplete evidence, which is a poor position to be in when a regulator, an internal audit, or a customer dispute requires a specific and defensible answer about what happened and why.
In practice
- Scope every tool to the minimum action and the minimum data
- Log each tool call with inputs, outputs, and the triggering context
- Require confirmation for irreversible or externally visible actions
- Review granted tool scopes periodically and revoke what is no longer needed
