How tool results feed back into reasoning

A tool's result is not appended to the transcript as an afterthought, it feeds directly back into the same reasoning that decided to call the tool in the first place, shaping the very next decision.

If a grep comes back with nothing, the next step is genuinely informed by that empty result: try a different pattern, look somewhere else entirely, or conclude the thing being searched for does not actually exist yet in this codebase. If a bash call fails, the real error output, not just the fact that something went wrong, is what the following step reasons from.

Because this feedback loop is scoped to the current turn, nothing from a completed turn is silently replayed into the next one beyond the conversation history itself; a follow-up question starts a fresh loop informed by everything said and done so far, not a re-run of previous tool calls.

This is part of what makes a correction mid-session effective, described in Correcting course mid-turn: your feedback becomes part of the same reasoning stream the next tool call draws from, not a separate instruction bolted on top of an otherwise unchanged process.

Nothing about this feedback mechanism is visible as a distinct step in the transcript; it is not a tool call of its own, it is simply how the model arrives at its next tool call given everything genuinely known so far, including the result that just came back.