Inside a tool call: request, arguments, result

Lesson 4 of 5 in The Agent Loop: One Turn at a Time.

One more zoom level: below the turn sits the tool call itself. Every one has three parts. The request names the tool. The arguments are JSON shaped by the tool’s parameter schema. The result is whatever comes back. The division of labour is absolute: the model produces the first two as text — function calling is the API contract that makes that text reliably parseable — and the runtime does everything that actually touches the world: validate, permit, execute, and append.

Three details in that exchange carry more weight than they look.

The id is the thread. A single turn can request several tool calls at once; the echoed tool_use_id is what keeps three parallel results matched to the right three requests. When you read traces professionally, id-matching is how you reconstruct what happened.

The arguments are the model’s only lever. Everything the model can make happen in the world, it makes happen by choosing a name and filling in JSON. That is why argument validation belongs in the runtime — it is the last checkpoint before text becomes action.

The result is just text appended to the context. Read that again, because it is the hinge of the entire security story: the model will read that result on the next turn with exactly the same standing as everything else in its context. There is no separate channel for “data” versus “instructions” — one window, one stream of tokens.

Key terms: tool call, function calling, parameter schema, tool-output poisoning, prompt injection

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.