A language model can describe a command without knowing what the command will return. Tool use changes that boundary: the model can act, receive evidence from an external environment, and let that evidence alter its next move.
That sounds like a small interface feature. It is actually the transition from producing one answer to following a trajectory through a changing world.
A fluent answer is still a closed world
In AI pair programming, conversation widened the shared task. A developer could state intent, attach context, inspect a proposal, and ask for a revision. But the assistant was still often describing what should happen while the human executed commands and brought the results back.
Reasoning alone has the same limit. A model can decompose a problem, predict an outcome, or write a convincing explanation, yet remain trapped inside the information already present in its context. If a dependency changed yesterday, a test fails only on this branch, or a file contains an unexpected value, more internal reasoning cannot reveal the missing fact.
Early systems had already demonstrated a way out. OpenAI’s 2021 WebGPT work placed a language model inside a text-based browser. The model issued search and navigation commands, collected passages, and used those observations to compose an answer with citations. The browser was not just extra knowledge; it was an environment with a defined action space and returned state.
ReAct made the alternation explicit
The 2022 paper ReAct: Synergizing Reasoning and Acting in Language Models gave the pattern a compact form. Instead of studying reasoning traces and task-specific actions separately, ReAct interleaved them.
A trajectory could contain:
- a thought that tracks the goal or updates a plan;
- an action expressed in the environment’s allowed syntax;
- an observation returned after that action;
- another thought conditioned on the new evidence.
The original work applied this pattern to question answering, fact verification, text games, and web navigation. Its lasting contribution is not a particular benchmark result. It is the protocol: reasoning determines what evidence is needed; action seeks it; observation grounds the next decision.
That makes correction possible. A failed search can narrow a query. An unavailable object can change a plan. A test failure can replace a plausible hypothesis with a precise location. The model no longer has to finish the task from its initial context.
The observation matters more than the tool count
Tool catalogs attract attention because they look like capability. Search, shell, browser, database, calculator, file editing, and deployment APIs each expand what a model can attempt. Meta AI’s 2023 Toolformer paper framed tool use around four decisions: which API to call, when to call it, what arguments to pass, and how to incorporate the result into later prediction.
But access alone does not close the loop. A shell command that returns ten thousand irrelevant lines technically produced an observation, yet gave the model little usable evidence. A browser screenshot the model cannot inspect is not grounding. A test result without the failing assertion leaves the next move ambiguous.
Observation design therefore compresses the environment into a decision surface. It should preserve the fact that matters, enough provenance to trust it, and enough structure to choose the next action. Focused logs, stable exit codes, bounded output, file locations, diffs, screenshots, and explicit approval states are all parts of the tool interface.
Every action creates a system boundary
Once model output can trigger an external effect, it stops being ordinary text. A tool request needs a name, an argument schema, validation, an execution environment, and a defined result. It may also need authentication, a budget, a timeout, human approval, or a rule that forbids the action entirely.
This separation matters because models are probabilistic while tools are operational. The model may propose an action, but the surrounding system decides whether that proposal is well-formed and allowed. The executor—not the model—owns process isolation, credentials, resource limits, cancellation, and the faithful capture of stdout, stderr, exit status, or changed state.
The same boundary protects correctness. If a tool call is malformed, the system should return a legible validation error rather than guessing. If a destructive command requires approval, the system should pause before execution. If an operation times out, the observation should distinguish timeout from failure. If the goal has been reached, a stop condition should prevent another unnecessary cycle.
This is the point where better engineering around the model begins to compound. A precise schema reduces invalid calls. A narrow permission model limits damage. A reproducible environment makes results comparable. A compact observation lowers context noise. None of those improvements requires a larger model, but all of them increase the chance that the model can make a safe next move.
The trace becomes the new review unit
A tool-using system should leave more than a final answer. Its operational trace should show the task, actions requested, tools invoked, meaningful observations, files changed, verification performed, approvals granted, and why the run stopped.
That does not require publishing private chain-of-thought. A reviewable trace can record concise decision summaries and observable events without exposing hidden reasoning tokens. The goal is diagnosis: when a run succeeds, a human can verify the evidence; when it fails, an engineer can locate whether the fault was planning, tool selection, execution, observation, or policy.
Traces also turn one run into reusable system knowledge. Repeated malformed arguments suggest a better schema. Repeated broad searches suggest a repository map. Repeated test confusion suggests better failure output. The harness can improve because the trajectory makes friction visible.
A tool-using model is not yet a coding agent
ReAct established the crucial closed loop between reasoning, action, and observation. It showed how a language model could update behavior from external state instead of treating generation as a one-shot answer.
But a production coding agent needs more than the loop. It needs persistent task state, repository context, safe editing, a runtime, verification, recovery, and human control across many steps. The next article moves from the ReAct protocol to that whole-system boundary: why a coding agent is never just a model with a shell command.
Sources
- Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models
- ReAct project site
- Google Research — ReAct
- OpenAI — WebGPT
- Schick et al. — Toolformer
