05. What Happens After the Model Calls a Tool

Kimi’s first model response contained two Bash calls. At that point the model had only expressed desired actions. No local command had yet run.

The path from the response to the next model request contains at least six stages:

One identifier spans the process

Each call needs a tool_call_id, tool name, and arguments. The permission decision, execution result, and model-facing result refer to the same identifier.

If two calls run concurrently and their results are appended only by completion order, the second request can be matched to the first result. Kimi’s Bash_0 and Bash_1 links show why call identity is a concurrency requirement rather than a logging detail.

The runtime cannot trust self-description

A model can label an argument “read only,” but that phrase cannot authorize it. Policy is recomputed from the parsed operation:

• Which principal is acting?
• Which tool is requested?
• Which path or domain is targeted?
• Does the action read, write, execute, or access the network?
• Does approval cover one call or the session?

The model proposes. The runtime decides whether the action may occur.

Four result states

Encoding denial as exit code 1 encourages the model to alter arguments and try again. Encoding an unknown outcome as failure can duplicate an external side effect.

Two successful traces, two runtime tradeoffs

Codex combined path reading and directory listing in one Shell call. Kimi emitted two calls. The compound command crosses one tool boundary. Separate calls are easier to record and retry independently.

Both operations were read-only, so either representation could complete the task. If one operation had a side effect, a compound command would make recovery harder because the runtime might know only the final exit status, not which prefix actions completed.

Event order carries more evidence than the answer

At minimum, a trace contains:

model.completed
tool.requested
tool.authorized
tool.started
tool.completed
model.started
model.completed
turn.completed

Events share trace, turn, and call identifiers plus a monotonic sequence number. The final answer shows what the user received. The event chain shows what the runtime did.

Timeout and cancellation are events

After a tool starts, the runtime may receive user cancellation, a total-budget expiration, or a tool timeout. A cancellation request is not proof that the process stopped. The trace distinguishes cancel_requested from cancelled.

The executor records termination signal, emitted output, and possible external effects. A read-only call can be retried after termination is confirmed. A side-effecting call requires an external status check first.

Each stage has an acceptance condition

Parsing rejects unknown tools. Structural validation returns a machine-readable field path. Authorization records the policy basis. Execution captures exit status and timeout. Recording persists event order. Result delivery preserves call identity.

Fault tests interrupt execution between every pair of stages. If recovery cannot answer which event was durable, whether the tool started, and whether its result is complete, the trace is not sufficient for replay.

After a model proposes a tool, the Agent’s primary work temporarily leaves the model and enters a deterministic runtime path. A correct final answer cannot compensate for a missing validation or event in that path.

One call crosses two trust boundaries

Model output crosses into deterministic software; tool output later crosses from external state into model context.

model output → parse → schema validation → authorization
             → execution → normalization → context insertion

Every stage records input, output, duration, and error class. Valid JSON rejected by policy is not a tool failure. Anthropic's current contract likewise states that the model requests a client tool while application code executes it. Anthropic, How tool use works

Streaming arguments can arrive as interleaved deltas. The runtime buffers by call identifier and waits for completion, parsing, and validation. A test disconnects before the final delta and asserts that no partial call starts.

A timeout proves that the observer received no timely result, not that an external write did not occur. Recovery queries external state or an idempotency record before retry.