Tool Use: When Language Triggers Actions

A model can describe sending an email in perfect detail and nothing will happen. The description is text. Something else has to read it and act.

That gap is small, easy to talk past, and it is where responsibility for every real effect in a tool-using system lives.

What actually happens

You give the model a list of operations it may ask for, each with a name, a description and expected arguments. Something like get_weather(location) or refund_order(order_id, amount).

When the model judges one relevant, it does not execute anything. It emits a structured request:

{"tool": "refund_order", "arguments": {"order_id": "A-3391", "amount": 40}}

Your application receives that. It reads the name, checks the arguments, decides whether to proceed, and if it does, calls your own function. Whatever comes back can be handed to the model so it can carry on.

A model does not call a tool. It produces a request, and software decides whether that request becomes an action.

The shorthand "the model called the tool" is convenient and it hides the step that matters. If your implementation routes a structured request through application code, which is the usual arrangement, say so, because the difference shows up the moment something goes wrong.

Why the distinction is load-bearing

The code that reads the request is where responsibility for the effect sits.

A request for a refund of forty pounds is a sentence until your code runs it. If the amount was wrong, the model produced a bad proposal and your application made the payment. Both facts matter, and only the second one moved money.

This changes what you build. You are not trying to make the model incapable of asking for the wrong thing; it will sometimes ask for the wrong thing, in the same way it sometimes writes a wrong sentence. You are deciding what your code does when it receives a request it should not honour.

Concretely, the receiving code has work to do before anything runs:

• Is this a tool I actually expose? A name in the response is not proof the operation exists.
• Do the arguments hold up? Types, ranges, referenced identifiers. This is structured output territory, and it applies here directly.
• Should this run at all, now, for this user? Permission is a separate question from whether the request is well-formed, and it has its own page.
• What happens when the tool fails? Timeouts, errors and partial results are ordinary, and the system needs an answer for each.

The part that surprises people

Describing your tools well matters more than it sounds. The model chooses among them using the descriptions you wrote, so a vague description produces a plausible wrong choice rather than an error. That is a documentation problem wearing the costume of a model problem.

The other surprise is scope. It is tempting to expose one flexible operation that takes a query and does whatever is needed. A narrow tool with three arguments is easier to validate, easier to authorise and easier to reason about afterwards than a general one that can express anything.

Where this goes next

This page covers one handover: request to action. Two questions sit either side of it.

Whether the model or your program decides what happens next is a different distinction, covered in AI agents vs AI workflows.

What happens between receiving a request and letting it produce an effect, including permission and verifying the effect actually occurred, is from agent intent to governed execution.