The most useful idea in my tool-calling notes is surprisingly ordinary: a model can ask for a function to run, but my application is responsible for running it.
That distinction brings the topic back into familiar backend territory. There is a request, a contract, a handler, and a result. The model helps choose the request; it does not replace the application around it.
Start with an ordinary function
The learning exercise in my notes uses a fictional airline assistant. A customer asks about a destination, and a function looks up a ticket price. The function can begin as a dictionary lookup and later use a database.
The model is given a description of the tool and the arguments it accepts. It does not need the function’s implementation to request a lookup. That separation matters: I can change the storage behind a tool without changing what the tool means to the model.
The function description is therefore part of the interface. A vague name or ambiguous argument makes the request harder to interpret, just as it would for a human integrating with an unfamiliar API.
Follow the round trip
For an application-managed function tool, the sequence is:
- Send the conversation and available tool definitions to the model.
- Receive a tool request with a name and arguments.
- Validate the request and execute the permitted function.
- Return the result with the identifier that connects it to the request.
- Let the model use that result in its response, or request another tool.
A simple lookup may involve two model calls. That is an example, not a fixed rule: a model can answer without a tool or make several rounds of requests. This is the same application-managed loop described in the OpenAI function-calling guide.
A tool description is not permission
The distinction becomes more important when the exercise adds a tool that changes a price. Reading a value and changing a value may look similar in a schema, but they have different consequences.
My engineering takeaway is to keep authorization in the application. The handler needs to check who is allowed to make a change, whether the arguments are valid, and how failures are reported. A persuasive model response is not evidence that a database update happened.
I would also bound repeated calls. A loop needs a stopping condition, an execution budget, and an explicit result when it cannot finish. Those are design requirements for a real application, not features I have verified in this notebook exercise.
What I want to remember
Tool calling joins language understanding to conventional application code. I can inspect the boundary: what was requested, what ran, and what came back.
That gives me a better debugging question than “Why is the AI confused?” I can ask whether the tool was described clearly, whether the arguments were valid, whether the handler succeeded, and whether its result reached the model.
Adapted with AI assistance from my AI Engineer Core Track tool-calling notes. The airline is a course example; this article does not claim a production deployment or a newly executed API test.