Tool Calling: How Agents Act on the World

From text to action

A foundation model, left to itself, does exactly one thing: it predicts the next token. That is a remarkable capability, but it is inert. A model that has reasoned its way to the conclusion that a ticket should be closed, an email sent, or a refund issued still cannot close, send, or issue anything. It can only produce the sentence describing what it would like to happen. Every deployment that does real work has to answer the same question: how does the text a model generates become an action in a system that has consequences?

Tool calling is that answer, and it is the single most important primitive underneath the entire agentic stack. The idea is disarmingly simple. Alongside the user's request, you give the model a set of tool descriptions: named capabilities, each with a schema for its inputs. When the model judges that answering in prose is not enough, it stops writing prose and instead emits a structured request naming a tool and the arguments to call it with. Your application reads that request, runs the corresponding function, and returns the result for the model to incorporate.

This one mechanism is what turns a chat model into something that books, queries, files, and updates. It is the foundation under agents, which are little more than a model looping over tool calls toward a goal, and it is the mechanism the Model Context Protocol standardizes so that tools can be shared across applications. Understand tool calling precisely and most of the agent landscape stops looking like magic and starts looking like an engineering problem with well-defined edges. The rest of this article is about those edges, and about the one boundary an architect must never blur.

How tool calling works

The loop has three beats: request, execute, observe. First you provide the model with tool schemas, typically as part of the request, each describing a capability the model may draw on: a name, a natural-language description of when to use it, and a machine-readable contract for its arguments. The model reads the user's intent against that menu. When it decides a tool fits, it does not answer the user; it emits a structured tool-call request that names the tool and supplies arguments conforming to the schema.

Your application, not the model, then executes. It parses the request, validates the arguments, runs the underlying function against whatever real system sits behind it, and captures the result. That result is fed back to the model as a new message, and the model observes it: it may answer the user now, or it may decide another tool call is warranted and go around the loop again. The conversation continues until the model produces a final text response with no further calls.

   user intent
       |
       v
 +-----------+   1. tool-call request   +-------------+
 |   model   | -----------------------> | application |
 |           |   name + arguments       |  (executor) |
 |           | <------------------------ |             |
 +-----------+   3. observe result      +------+------+
       ^                                        |
       |                                        | 2. execute
       |          loop until done               v
       +-------------------------------- real system / API

Two things are worth fixing in your mind here. The model's contribution is a proposal, expressed as data, not an action. And the loop is driven by the application: it decides whether to honor a request, what to run, and what to return. Everything an agent does is this cycle repeated, which is why getting the cycle right matters more than any prompt.

The model does not execute

This is the sentence to carry out of the article: the model does not execute anything. It emits a request to call a tool. Something else, your application code, decides whether to run it and then runs it. The model has no hands. It cannot reach a database, an API, or a shell; it can only produce a token sequence that your runtime chooses to interpret as a call. That gap between requesting and executing is not an implementation detail. It is the primary security control in the entire system, and it exists whether or not you use it deliberately.

Because the boundary is real, you get to decide what happens at it. Between the model's request and the actual execution you can validate arguments against the schema, check that the caller is authorized to use this tool with these inputs, enforce least-privilege credentials, rate-limit, require human approval for consequential actions, and log the whole exchange. None of that is available if you collapse the gap.

The failure mode to fear is the tempting shortcut: a handler that takes the model's requested arguments and passes them to a shell, an SQL string, or a payments API with no check in between. That design hands an attacker who can influence the model's context a direct line to your systems. The containment patterns that harden this boundary, sandboxing, egress control, and approval gates, are covered in guardrails and sandboxing; the point here is narrower. The boundary is where your security lives, so build on it rather than around it.

Structured output underneath

Tool calling is, mechanically, a special case of structured output. When the model requests a call, it is not writing free prose; it is producing a payload that must conform to the tool's declared schema: the right field names, the right types, required arguments present, no invented parameters. Modern instruct models are trained to emit this shape, and providers often constrain decoding so the output parses. But the guarantee you actually get is syntactic, that the arguments form valid, schema-shaped data, not semantic, that the values are correct or sensible.

That distinction sets your engineering agenda. Because arguments must match the schema, the same validation discipline you apply to any structured output applies here, and it is your responsibility, not the model's. A schema that constrains tightly does real work: enums instead of free strings, explicit types and ranges, required fields marked required, and formats declared so a malformed date or an out-of-range amount is rejected at the boundary rather than executed.

• Schema-valid does not mean correct. The model can produce a perfectly well-formed call to the wrong record or with a plausible but wrong amount. Structure catches malformed; it does not catch mistaken.
• Design schemas to make bad calls unrepresentable. Narrow types, enumerated options, and required fields shrink the space of arguments the model can even express, which is cheaper than validating loosely and repairing after.
• Validate on receipt, every time. Parse and check arguments against the schema before execution, and return a structured error the model can read and retry from when they fail.

Get the schema layer right and a whole class of reliability problems never reaches your systems. The tool contract is not documentation; it is an enforcement surface, and it is the first line of defense at the boundary the previous section described.

Calling patterns

Tool calling is one mechanism, but it is exercised in a few distinct shapes, and choosing the right one is part of designing an agent rather than an afterthought. The axes that matter are how many calls the model may request at once, how much freedom you give it over whether to call at all, and whether a single turn or a multi-step loop is doing the work.

Parallel calls cut latency when work is genuinely independent, but they need care: the model can request calls that quietly depend on one another, and executing those out of order produces subtly wrong results. Tool-choice control is the underused lever. Forcing a call is how you make an extraction reliably return a schema-shaped object; disabling calls with none is how you keep a summarization or planning step from acting when it should only think. And the multi-step loop is the agent itself: the same request-execute-observe cycle run until a goal is reached, which is why loop control, a step budget, and a stop condition are as important as the tools on offer.

The reliability problem

Tool calling works well enough to build on and badly enough to respect. The model is deciding, under uncertainty, which capability to invoke and with what arguments, and it can be wrong in several distinct ways. Naming the failure modes precisely is the first step to guarding against each, because they have different detections and different fixes.

• Wrong tool chosen. The model picks a plausible but incorrect capability, often when descriptions overlap or tools are too numerous. Detect it by logging tool selection against outcomes; reduce it with sharp, non-overlapping descriptions and a smaller, well-scoped tool set.
• Hallucinated or malformed arguments. The model invents a parameter, supplies a wrong type, or fabricates a plausible value such as an ID that does not exist. Schema validation at the boundary catches the malformed cases; existence and authorization checks catch the fabricated-but-valid ones.
• Calling when it should not. The model acts on a request that needed no tool, or takes a consequential action prematurely. Guard with tool-choice control, conservative prompting, and approval gates on anything that writes.
• Failing to call when it should. The model answers from its own parametric memory instead of consulting the tool that holds ground truth, producing a confident but stale or invented answer. Detect it by comparing answers against source systems; reduce it by forcing a call where a fresh lookup is required.

The reassuring part is that none of these failures needs a smarter model to contain. They need a disciplined boundary: validation, scoping, gating, and observability sitting between the model's request and your systems. The reliability of an agent is far more a property of that boundary than of the model behind it.

The architect view

Step back and the picture is clear. Tool calling is where a language model stops being a text generator and starts touching your enterprise: your CRM, your warehouse, your payment rails, your customers. That makes the set of tools an agent can call one of the most consequential surfaces in the system, and it deserves to be governed as a first-class capability rather than assembled ad hoc by whichever team ships first.

Governing it well means treating each tool as a controlled interface with four properties in place before it reaches production:

1. Schemas as contracts. Every tool declares a tight input schema that constrains what the model can even request, reviewed like any production API contract.
2. Validation at the boundary. Arguments are checked against the schema, and against existence and authorization, on receipt, before anything executes.
3. Permissioning and least privilege. Each tool runs with the narrowest credentials that do its job, scoped per user or per agent identity where feasible, with consequential actions behind approval gates.
4. Audit. Every call logs its tool, arguments, result, and the identity on whose behalf it ran, so the boundary is observable and reviewable after the fact.

The thread running through all four is the boundary between requesting and executing. The model proposes; your application disposes; and the strength of your system is the strength of what you put in that gap. An enterprise that internalizes this treats tool calling not as a model feature but as an integration and access-control problem, which happens to be the discipline your organization is already good at. Build the boundary strong and observable, and agents become a governable extension of your systems rather than an unbounded new risk. To watch the loop run against real tools, the Agent Studio in the Lab puts agents through exactly this cycle.