AI Agents · entry 02/05

Tool use & function calling

Tool calling is a structured request the model emits and your runtime executes — nothing ever runs inside the model itself.

The mechanics, end to end

Tool calling is less mystical than the demos suggest. You send the model a list of tool schemas — names, descriptions, typed parameters — alongside the conversation. When the model judges that a tool would help, it stops writing prose and emits a structured call: a tool name plus JSON arguments. Your runtime — not the model — looks up the function, executes it, and appends the result to the conversation as a new message. The model reads that and continues: another call, or a final answer. Run this exchange in a loop and you have an agent; every framework is decoration around this exchange.

The model executes nothing

The model's entire power is emitting text shaped like a request. Execution, authentication, permissions, rate limits — all of it lives in your runtime, which means all of it is enforceable by you. The model can ask to drop a table; only your code can do it, or refuse, or log it, or route it to a human first. This seam is where every serious safety control attaches, and it cuts both ways: no mystique — "the AI deleted it" means your handler did — and no excuse, because every call passes through code you wrote.

A schema is a prompt

{"name": "get_invoice",
 "description": "Fetch one invoice by ID. Returns amount_cents,
   status (draft|sent|paid), due_date. Fails with NOT_FOUND
   if the ID does not exist.",
 "input_schema": {
   "type": "object",
   "properties": {"invoice_id": {"type": "string"}},
   "required": ["invoice_id"]}}

The model chooses tools by reading names and descriptions in context, so tool design is prompt engineering with a compiler. Name the action, not the implementation (get_invoice, not query_db_v2). Say what comes back and how it fails. Keep arguments few — every extra parameter is another chance to guess wrong — and keep tools orthogonal: two near-duplicates split the model's confidence and double its error surface.

Errors are part of the interface

Results flow back into the context, so an error message is really the next prompt. "date must be YYYY-MM-DD, got 03/14/2026" produces a corrected retry; "internal error 500" produces flailing. The same goes for success: return compact, structured output, not twenty kilobytes of raw JSON that buries the one field that matters and spends context on noise.

Failure mode

The kitchen-sink toolbox. Forty overlapping tools with one-line descriptions feel like capability, but every schema occupies context, and every overlap dilutes the choice — the model picks the almost-right tool, fails oddly, and the team responds by adding a forty-first. Capability comes from fewer, sharper, better-documented tools. If a human skimming your tool list cannot predict which one to use for a given job, neither can the model.