A coding agent asks a search tool where a feature is implemented. Behind that apparently simple call, another copy of the same model searches the repository, chooses new queries and returns selected snippets. The first agent sees an answer; the tool has conducted an investigation.
That is the natural-language search interface in Xiangzhe Xu and colleagues’ August 11 study of tool architecture. There is no special semantic index hidden behind it. The second model uses ordinary shell commands. A familiar tool name has concealed a division of reasoning.
This makes “give the agent better tools” a less straightforward instruction than it sounds. A tool can spare the model repetitive work, or take over decisions the model might have made differently. Where the call ends determines when the caller gets another chance to think.
Three ways to compress the work
A fixed helper can package a known procedure. Anthropic’s 2025 tool-design guidance suggests combining operations that agents frequently need together, such as collecting a customer’s relevant context. The caller asks for the result instead of managing each lookup. This can be a sensible place to encode knowledge of how a service works.
A code tool makes a different arrangement. The caller writes the procedure for this occasion. Cloudflare’s February 20 Code Mode design exposes search and execution tools: generated JavaScript can discover API operations, follow pagination, check responses and chain requests. There may be only one execution call, yet the caller has specified a whole program.
A delegated search adds another possibility. The caller describes what it wants; a second model decides how to pursue it while the call runs. That model can react to discoveries the caller has not yet seen. A fixed helper, generated program and delegated investigator can all produce a compact result. They place discretion in different locations.
There is a real reason to compress. Xu and colleagues compare six interfaces on 65 repository issues, with repeated attempts by three models. Python blocks reduce interaction steps and cumulative input tokens while keeping overall issue-resolution performance broadly similar. Structured tools for smaller operations improve consistency across repeated attempts, but increase steps and input tokens for the stronger two models. These are benchmark findings, not measured customer savings. They complicate the assumption that smaller tools are always easier to use.
The distinction between a machine step and a thinking step helps explain the tradeoff. A program can fetch successive pages until an API says there are no more. Sending every page back to a language model merely to request the next one adds decisions whose answers were already specified. Code can also branch on a result without asking the model again. The boundary need not fall after every operation that touches the outside world.
The decision that cannot be written yet
Other continuations depend on what the result means. In a code investigation, a failed test might reveal that the proposed fix is wrong—or that the assumed responsibility of the module is wrong. A program can collect the failure and its surrounding context. Choosing which explanation to pursue may require a fresh interpretation. If the call continues anyway, that interpretation has either been anticipated in the program or handed to another model.
Even arranging the mechanical part takes more than finding a tool with a relevant name. In HyperAgent, submitted July 31, Zian Zhai and colleagues represent relationships between the inputs and outputs of tools. A desired operation may need an identifier from a different, less obviously relevant operation. The planner works backwards from missing inputs and accounts for values already obtained. Its graph also represents conditions such as an authenticated session that a plain parameter list can omit. This is a research architecture tested in AppWorld’s simulated applications; it does not establish reliability in live services.
That design separates two questions which a broad tool description can blur: can the next operation run, and is it still the right operation? Obtaining the required identifier settles a dependency. It need not settle a changed interpretation of the task. Treating both as one opaque “complete the investigation” call asks its implementation to own both kinds of judgment.
The strongest case for that arrangement is specialization. A search worker can concentrate on the repository while its caller keeps the larger problem in view. Returning every intermediate discovery would defeat much of that benefit. But specialization needs a useful stopping condition: enough relevant context to let the caller reconsider the problem can be a better handoff than a worker’s declaration that it has exhausted its own plan.
The boundary also determines what a model upgrade can change. If a helper’s search strategy is fixed, improving its caller does not rewrite that strategy. If the caller composes the operations itself, more of the procedure remains open to its judgment. A delegated worker introduces a separate model and brief to improve. An apparently stable interface can therefore preserve an old division of intellectual work long after one participant becomes better at it.
That is a reason to examine where a tool returns control, beyond whether its name is clear or its result is correct. The valuable boundary is where further execution needs a decision worth reopening. Sometimes that is after many operations. Sometimes it is before the helper has finished what it was built to do.