12 Tool use and agents

A local LLM becomes much more useful when it can use tools: file search, shell commands, browser automation, databases, code execution, calendars, ticket systems, internal APIs, vector databases, even home automation or edge devices. Tool useⓘtool useagentsThe general pattern of an LLM invoking external functions, APIs, or systems to fetch data or take action, distinct from generating an answer purely from its weights. Chat about this → Open full entry → is what turns a model from a text generator into something that can act.

It also changes the safety model. A chatbot that hallucinates is annoying. An agent with filesystem access can delete things. An agent with browser access can leak secrets. An agent with shell access can damage the machine faster than you can read the logs.

Local agent safety has four layers. Scope the agent tightly: give it only the directories, APIs, network access, and credentials it actually needs. Constrain execution: sandboxes, containers, least-privilege users, confirmations for destructive actions, and schema-validated tool arguments. Treat inputs as hostile: retrieved documents, web pages, tickets, and emails can all carry prompt injection. Keep an audit trail: log tool calls, model versions, prompts, and approvals, without dumping secrets into the logs.

Structured outputs help but are not a security boundary. JSON schemas, constrained decoding, and function signatures make tool calls easier to validate. They do not prove the model understood the request, chose the safe action, or resisted injected instructions. For serious tool use, the policy checks belong outside the model. The frameworks and products where these patterns get built are the subject of the agents layer.