Tool-Using Agent — AI Glossary

Reference details

Related terms

• Tool Use
• Tool Definition
• Tool Result

How it works

1. Tool definitions are serialised into the request as schemas — a name, a description, and a typed parameter object — so the model's knowledge of a tool is entirely its description.
2. The model emits a structured call rather than prose, naming a tool and supplying arguments, and this is a trained output format rather than something parsed out of text.
3. The harness validates those arguments against the schema before executing anything, which is the only place a malformed or out-of-range argument can be caught.
4. Execution happens in the harness, never in the model, and the result is appended to the message list as a tool message bound to the call's identifier.
5. Control returns to the model with that result in context, and the loop repeats until it emits a response with no call — so the number of steps is the model's decision, bounded only by a limit the harness imposes.
6. Several calls may be issued in one turn and resolved in any order, which the identifiers exist to disambiguate; and because results re-enter as context, anything a tool returns is untrusted input to the next step.

Example: The permission question, asked early and answered by counting

An agent with read-only tools that returns a wrong answer has produced a bad answer. An agent with send_email and issue_refund that reasons its way to a wrong action has produced a real-world consequence you cannot recall. The tool list, not the model, sets the blast radius — so it is the first thing to scope. Scoping it is a count rather than a judgement. Take a tool list of eight: search, read_file, query_db, list_calendar and get_user are read-only, while send_email, issue_refund and write_file change something outside the agent. Three of eight carry consequences, so 3 / 8 = 37.5% of the surface needs an approval path and the remaining 62.5% does not. Gating all eight produces approval fatigue and gating none produces an unrecallable action; gating three is the only configuration that is both reviewable and meaningful. The count also tells you what a new tool costs: adding one with side effects moves the fraction, and adding a read-only one does not.

Commonly confused with

Tool use is a capability; a tool-using agent is a system that chooses when to invoke it. A pipeline can use tools without being an agent. The agent property is autonomous selection, and that is precisely what makes the permission model load-bearing. That is also why a tool list is a security artifact rather than a capability list: it describes not what the agent will do but the complete set of things it could do, which is the quantity a reviewer actually needs.

When to use it

Reach for it when:

• The task needs live data or real-world effect and the steps are not fixed
• Every tool is scoped, authenticated and individually rate-limited
• Irreversible actions have a human in the loop
• Where the side-effecting fraction of the tool list has been counted and gated

Reach for something else when:

• Tools carry side effects with no approval step
• The tool list is long and unfiltered; selection accuracy drops as it grows
• Tool output is untrusted text flowing straight back into the prompt
• Gating every tool uniformly, which produces approval fatigue and the appearance of oversight

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Tool-Using Agent — AI Glossary.

• Browse models
• Review providers
• Inspect benchmarks
• Explore workflows
• Learn AI concepts
• Read decision guides
• Review trust and methodology
• Start a decision path