Tool Calling

Mechanically the loop is small — send messages and tool definitions, receive either a final answer or a tool request, execute, append the observation, repeat. Everything difficult lives in the details around it. Tool results consume context, so a verbose API response can crowd out the instructions that keep the run on track; summarising or projecting results before appending them is often necessary. Tools fail, time out and return errors, and how you phrase an error back to the model determines whether it retries sensibly or loops.

Tool design is where most of the quality comes from. Tools that mirror a user-visible task ("look up an order by number") outperform tools that mirror your internal API surface ("query the orders table"), because the model is choosing by name and description, not by reading your schema. Overlapping tools invite the model to pick badly, and a catalogue of dozens dilutes selection accuracy for every one of them.

The security boundary is the part to internalise: a tool result is untrusted input. Text fetched from a web page, a document, a database row or another system arrives in the same context as your instructions, and a model has no reliable way to distinguish data from directive. Anything with side effects therefore needs its own authorisation, scoped credentials and — for irreversible operations — a human approval step that the model cannot bypass.