Tool call

When a model decides it needs a tool, it does not run code. It emits a tool call: a structured request that says "call read_file with path: src/index.ts." The model then stops and waits. Executing that request is the harness's job, not the model's.

What it looks like

A tool call arrives as a block in the model's response, carrying a unique id, the tool name, and the arguments the model chose:

// A block inside the model's reply
{
  type: 'tool_use',
  id: 'toolu_01A2b3',
  name: 'read_file',
  input: { path: 'src/index.ts' },
}

The model also signals that it is pausing for tools rather than finishing its turn, so your agent loop knows to run the requested tools instead of treating the reply as final.

Why the split matters

Two important consequences follow from the model only *requesting* the action:

• You are in control of execution. Because nothing runs until your code chooses to run it, this is the natural place to put permission checks, sandboxing, and logging. The model can ask; the harness decides.
• The arguments can be wrong. The model picks the inputs, and it can pick badly, a wrong path, an unsafe command. Validating tool-call arguments before executing is not optional in a serious agent.

Every tool call is answered by a matching tool result, which carries the output back to the model so it can take the next step.