An agent checks the weather, queries a database, and writes a file. It looks like the model is doing things. It is not — the model cannot do anything. It produced some structured text saying what it would like done, and an entirely separate piece of software decided whether to comply.
The Short Answer
The LLM selects. The agent executes.
The model decides which tool to call and with what arguments. It has no ability to run anything. The agent — the orchestration code around the model — receives that request, decides whether to honour it, executes it, and returns the result.
Responsibility is split, and confusing the halves produces both architectural and security mistakes.
The Three Actors
| Actor | Decides | When |
|---|---|---|
| Developer | Which tools exist at all, and what each is permitted to do | Design time |
| LLM | Whether a tool is needed, which one, and with what arguments | Per request |
| Agent | Whether to actually execute, and what to do with the result | Per tool call |
The first row constrains everything downstream. A model cannot request a tool it was never told about. If no file-deletion tool is defined, no amount of prompting produces file deletion — the capability does not exist in the system.
What Happens in One Tool Call
| Step | Who | What happens |
|---|---|---|
| 1 | Agent | Sends the user’s request plus tool definitions — usually JSON schemas describing each tool’s name, purpose and parameters |
| 2 | LLM | Determines a tool is needed and emits a structured block naming the tool and its arguments |
| 3 | LLM | Stops. Generation ends. It cannot proceed further |
| 4 | Agent | Parses the request, validates it, decides whether to execute |
| 5 | Agent | Runs the actual code — the API call, the query, the file operation |
| 6 | Agent | Appends the result to the conversation as a tool result |
| 7 | Agent | Calls the model again with the updated context |
| 8 | LLM | Reads the result and either answers or requests another tool |
Step 3 is the one people miss. The model does not call a tool and wait. It ends its turn. Everything after that is the agent’s work, and the model has no awareness that any time passed or that anything was executed until it sees the result in its next input.
What “The Model Decides” Actually Means
Worth being precise, because the language implies more agency than exists.
The model is not reasoning about whether to use a tool in any deliberate sense. It is doing what it always does — predicting tokens. Tool definitions appear in its input, and models are trained such that when the input suggests a tool is appropriate, the highest-probability continuation is a structured tool request matching the schema.
Two consequences follow:
- Tool selection can be wrong in the ways generation is wrong. The model may pick an inappropriate tool, invent an argument, or omit a required parameter. Some providers constrain decoding to enforce schema validity, which prevents malformed output but not poor judgement.
- Tool descriptions are prompt engineering. The description is what the model reads when deciding. Vague descriptions produce poor selection. This is the highest-leverage thing to fix when an agent picks wrong tools.
What the Agent Controls
The orchestration layer holds every decision that has real-world effect.
| Control | Purpose |
|---|---|
| Validation | Check arguments against the schema and against business rules before executing |
| Authorisation | Decide whether this caller may perform this action |
| Approval gates | Pause for human confirmation on destructive or high-impact operations |
| Rate limiting | Prevent runaway repeated calls |
| Iteration cap | Terminate the loop after a maximum number of turns |
| Error handling | Decide whether to retry, return the error to the model, or abort |
| Result shaping | Trim or summarise large outputs before they re-enter context |
| Logging | Record what was requested and what actually ran |
Result shaping deserves attention. A tool returning fifty thousand tokens of output will consume the context window and may push earlier turns out. Agents commonly truncate, paginate or summarise results before feeding them back.
Why the Split Is a Security Boundary
This is the most important practical consequence, and the reason the distinction is not merely terminological.
A tool request from the model is not authorisation. It is a suggestion produced by a text predictor that read some input — and that input may include content the model did not originate.
If an agent processes a web page, a document or an email, instructions embedded in that content can influence what the model requests next. This is prompt injection, and the model has no reliable way to distinguish instructions from its operator from instructions inside material it was asked to read.
The mitigation is architectural rather than model-side:
- Validate every tool call independently of why the model requested it
- Scope tool permissions narrowly — a read tool should not be able to write
- Require approval for irreversible actions — deletion, payment, external communication
- Treat tool output as untrusted input, since it flows back into the model’s context
- Never derive authorisation from model output — the agent must know independently who is permitted to do what
Point five is the one that gets violated. An agent that executes whatever the model requests has effectively given control to whoever can influence the model’s input.
Constraining Tool Choice
The developer can narrow the model’s discretion through a tool-choice setting, though names differ across providers.
| Mode | Effect |
|---|---|
| Auto | Model decides whether to use a tool — the default |
| Required | Model must call some tool, cannot answer directly |
| Specific | Model must call one named tool |
| None | Tools disabled for this request |
Forcing a specific tool is a useful pattern for structured extraction — you are using the tool schema to constrain output format rather than to perform an action.
The Agent Loop
An agentic system is fundamentally a loop the agent runs:
while the model requests a tool:
validate the request
execute the tool
append the result to context
call the model again
return the model's final response
The loop is the agent’s. The model contributes one step at a time and has no view of the loop’s existence.
This works because the model is stateless. Each call is independent, and the agent reconstructs the full context — original request, every tool call, every result — on each iteration. The model appears to be conducting a multi-step process while actually reading an accumulating transcript fresh each time.
Termination is the agent’s responsibility too. Without an iteration cap, a model that keeps requesting tools produces an unbounded loop, which is why every production agent has a maximum.
Function Calling and Tool Use
The terms are used interchangeably and refer to the same mechanism. “Function calling” was the earlier name; “tool use” became common as the pattern extended beyond calling functions to searching, browsing and file operations. Both describe a model emitting a structured request that external code executes.
Key Takeaways
- The LLM selects the tool; the agent executes it — the model cannot run anything
- The developer decides which tools exist — a model cannot request what was never defined
- The model ends its turn after requesting a tool; everything after is the agent’s work
- Tool selection is token prediction against a schema, not deliberate reasoning
- Tool descriptions are prompt engineering — the highest-leverage fix for poor selection
- A tool request is not authorisation — this is the security boundary
- Prompt injection can influence what the model requests; validation must be independent
- The loop belongs to the agent, including termination and iteration limits
Frequently Asked Questions (FAQ)
Q: Does the LLM or the agent decide which tool to call?
The LLM decides which tool and with what arguments, emitting a structured request. The agent decides whether to honour that request and performs the actual execution. The model has no capability to run anything itself.
Q: Can an LLM execute a function directly?
No. A model produces text, including structured text describing a tool call. Execution requires code outside the model to parse that request and run the corresponding operation. This separation is fundamental to how tool use works.
Q: What is the difference between function calling and tool use?
They describe the same mechanism. Function calling was the earlier term; tool use became common as the pattern expanded beyond function invocation to include search, browsing and file operations. Both mean the model emits a structured request that external code executes.
Q: How does the model know which tools are available?
The agent includes tool definitions in each request, typically as JSON schemas describing each tool’s name, purpose and parameters. A model cannot request a tool that was not included in its input for that call.
Q: Why does my agent pick the wrong tool?
Most often because tool descriptions are vague or overlapping. The description is what the model reads when selecting, so it functions as prompt engineering. Sharpening descriptions and making tool boundaries distinct usually resolves it faster than changing models.
Q: Is it safe to execute whatever tool the model requests?
No. A tool request is a suggestion from a text predictor whose input may include untrusted content. Prompt injection can influence what the model asks for, so the agent must validate independently, scope permissions narrowly, and require approval for irreversible actions.
Q: Who ends the agent loop?
The agent. It continues calling the model while tool requests come back, and terminates when the model produces a final answer, an iteration cap is reached, or an error condition triggers. Without a cap, an agent can loop indefinitely.
Q: Can I force the model to use a specific tool?
Yes, through a tool-choice setting. Options generally include letting the model decide, requiring it to call some tool, requiring one named tool, or disabling tools entirely. Forcing a specific tool is a common way to constrain output into a structured format.
Related Reading: