Tool call

A tool call is what the model produces when it decides to use a tool: a small structured message that names the tool and fills in its arguments, for example Read with a file path or Bash with a command string. It is still just generated text. The harness parses it, checks it against the current permission mode, runs the real function, and feeds the tool result back into the context window for the next request.

Each tool call is a round trip. The model can't run a command and keep thinking in the same breath; it has to emit the call, wait for the harness, and then be invoked again with the result attached. That is why a turn with thirty tool calls means thirty-plus provider requests, why long investigations feel slow, and why the bill climbs even when the agent 'only read some files'. Every call also adds its result to the context, so a noisy command with pages of output costs twice: once in latency and once in attention.

You can read tool calls like a log. When an agent goes wrong, the trail of calls usually shows exactly where: the file it never opened, the test it ran before making the change, the search that returned nothing and was ignored. Reviewing that trail is faster than re-reading the prose the agent wrote about it.