What Is Tool Calling and How Does It Let an AI Take Real Actions?

I am tool calling. In one sentence: I let a language model stop just talking and start doing -- reading a file, running a command, hitting an API, searching a codebase -- by giving the model a fixed menu of actions it can request, with a name and a defined set of inputs, and then actually carrying out the one it asks for and handing back the real result. Without me, a model can only produce text. With me, that text can become a file read, a search, a deployment check, or a database write.

What I actually do, in order

A model is a text predictor. Left on its own, it can describe what it would do -- "I would check the file for X" -- but it cannot actually open the file. It has no hands. I am the hands.

My job runs the same way on every request:

1. Offer a menu, not a free-for-all. Before the model does anything, it's told exactly which tools exist, what each one is named, and what parameters each one accepts. It cannot invent a tool that isn't on the menu, and it cannot call a real one with parameters that don't match the schema. 2. Let the model decide, but only decide. The model looks at the conversation and picks which tool to call and with what arguments. It does not run the tool. It emits a structured request -- "call this tool with these inputs" -- and stops. 3. Gate the request. Before anything executes, the request passes through a permission check. Some actions run freely. Some need confirmation. Some are blocked outright regardless of what the model asked for, no matter how it phrased the request. 4. Execute for real, against real state. If the request clears the gate, the actual action happens -- the actual file gets read, the actual command runs, the actual API gets called. I don't simulate this step. 5. Hand the real result back. Whatever actually happened -- file contents, command output, an error, an API response -- goes back to the model as the next piece of context, and the model continues from there, often calling another tool based on what it just learned.

How I actually work here

In this operation, I'm the reason an agent can grep a codebase for a pattern instead of guessing what the code says, the reason it can run a test suite and read the actual pass/fail output instead of asserting the code probably works, and the reason a permission boundary can exist at all -- because the model never touches the real system directly, it only ever requests an action, and I'm the layer that decides whether that request gets carried out. Every red-line, every "this needs explicit approval first," every "this class of action always executes freely" rule in this operation is enforced at the point where I decide whether to run what the model asked for. The model's intent and the system's actual behavior are two different things precisely because I sit between them.

I also don't require the model to get it right on the first try. If a tool call fails -- wrong arguments, a missing file, a permission denial -- that failure goes back to the model as a real result too, and the model can adjust and try again. The loop of call, observe, adjust is the whole mechanism; it isn't a single request-response, it's a conversation with the real system mediated through me.

Where I fail

This is the part that matters more than the part above, so I'm not going to bury it.

I can be handed a name that sounds safe and isn't. A tool called update_config and a tool called delete_and_reset_everything look identical to a permission system that only checks the tool's declared danger level, not what it actually does under the hood. If the mapping between a tool's name and its real blast radius is wrong or stale, I will happily gate the wrong thing at the wrong strictness.

The model can call the right tool with subtly wrong arguments, and I have no independent way to know the arguments are wrong. I validate that the arguments match the schema -- right types, right shape -- not that they mean the right thing. A file path that's syntactically valid but points at the wrong file passes every check I run and still does the wrong thing.

I only see the tools I was told about. If a capability exists on the underlying system but was never declared to me as a tool, the model can't call it and I can't gate it -- but that also means a change to the underlying system that isn't reflected back into my tool definitions creates silent drift between what the model thinks it can do and what's actually true.

A confirmation prompt only works if the confirmation is meaningful. If a human is asked to approve a tool call and the call's real consequences aren't legible in the prompt -- vague description, hidden side effects, technical jargon nobody parses under time pressure -- the approval step exists procedurally but doesn't actually catch anything. A rubber-stamped gate is not a gate.

I can be starved of context about consequence. I know a tool was called and what came back. I generally don't know the downstream blast radius of that action -- whether this file is read by one script or fifty, whether this API call is idempotent or not. Without that context built into the tool's own gating rules, I enforce permissions on the action's name, not its actual weight.

Tech-Tips

- Name tools for what they do, not what they sound like. A tool's permission tier should be derived from its actual effect, re-verified whenever its implementation changes -- not frozen at whatever the name implied on day one. - Validate meaning, not just shape, wherever the cost of being wrong is high. Schema validation catches malformed input. It does not catch a well-formed path pointing at the wrong resource. Add a semantic check for any tool where that gap is expensive. - Keep the tool manifest and the real system in lockstep. A capability the model can't request is a capability I can't gate. Every new real capability needs a corresponding tool definition, deliberately, not as an afterthought. - Make confirmation prompts state the actual consequence, in plain language, every time. "Confirm this action?" with no detail trains humans to click through. State what will actually happen if approved. - Log every call and its real result, not just the model's stated intent. When something goes wrong, the useful record is what actually executed and what actually came back -- not what the model said it was going to do.

Evidence: This piece describes the tool-invocation and permission-gate pattern as used throughout our internal agent operation (declared tool menus, argument-schema validation, red-line/confirmation/free-execution permission tiers, and call-observe-adjust loops) -- no vendor or specific product is named, per the moat-protection and STORY-FORMAT conventions. Evidence class: internal operating record and Owner attestation, 2026-08-25.