For AI developers, this is not a narrow product update. It changes the boundary between model capability and application engineering.
The first generation of agents treated tools as prompt content. A developer gave a model a large menu of functions, their JSON schemas and perhaps a few examples. The model then selected a tool, emitted a call, read the result and decided what to do next. That pattern was intuitive, but it created a costly loop: every tool definition occupied context, every action invited another inference pass, and every intermediate result became more text for the model to interpret.
Anthropic’s November 2025 announcement frames its Tool Search and Programmatic Tool Calling features as an answer to that bottleneck. Tool Search lets Claude discover deferred tools when needed, rather than loading every definition into the initial context. Programmatic Tool Calling lets the model write code that coordinates several tools, processes their outputs and returns a compact answer instead of feeding every raw result back into the model.
The immediate prize is lower token consumption and fewer model calls. The larger prize is strategic: companies building agents can begin to treat tool use as a compilation pipeline. The language model plans. A registry resolves available capabilities. A constrained execution environment performs repetitive logic. A policy layer determines what can run. The model receives only the state needed to continue reasoning.
That is a more scalable architecture, but it is also a more demanding one. It turns agent builders into designers of runtimes, permission systems, tool registries and observability layers. The difficult work moves from writing a clever prompt to defining a reliable execution model.
The prompt-centric agent is reaching its limits
In the conventional pattern, the full tool catalog is placed beside the system prompt. This works when an agent has a handful of stable capabilities, such as searching a knowledge base, creating a calendar event or querying a database. It becomes fragile when the same agent must navigate GitHub, Slack, Jira, cloud infrastructure, internal databases and specialised Model Context Protocol servers.
Anthropic gives a practical sense of the scale problem. Its example setup spans 58 tools across five services and consumes about 55,000 tokens before the agent has addressed the user’s request. The company says it has seen tool definitions alone consume 134,000 tokens before optimisation.
That overhead is not simply a cost issue. It creates an attention problem. A model asked to choose among many similar functions must distinguish names, arguments, access scopes and side effects. It can select the wrong tool, use a correct tool with the wrong parameters, or waste effort considering capabilities irrelevant to the task.
The difference is subtle but decisive. In the old loop, the model is both planner and operator. It decides what to do, executes one action at a time through language, absorbs every response and then repeats. In the new pattern, the model can still decide the goal and high-level approach, but software takes on the work that software is better suited to perform: iteration, filtering, aggregation, retries, branching and formatting.
This is why “compiler problem” is a useful framing. A compiler does not ask a programmer to manually reason through each machine instruction. It translates an intention expressed in one form into structured operations in another, subject to type rules, execution constraints and error handling. Agent systems are moving toward a similar split.
Tool Search turns schemas into an index
Tool Search changes the role of a tool definition. Instead of being permanent prompt baggage, a schema becomes an indexed item in a capability registry.
Anthropic’s implementation lets developers mark tools for deferred loading. Claude initially sees the search mechanism and any tools deliberately kept resident, then searches for more specific capabilities when a task requires them. The relevant matches are expanded into full definitions only after discovery.
This is an architectural improvement because it separates availability from visibility. A company may expose hundreds or thousands of approved tools to an agent without forcing the agent to reason over the entire library on every request.
The commercial implication is important. More enterprise integrations have historically made agents harder to operate. Every added system widened the capability set but also expanded the prompt, increased inference costs and raised the chance of accidental tool selection. A searchable registry creates a path to broader integration without treating context length as the only scaling mechanism.
Anthropic reports that, with Programmatic Tool Calling, average usage on complex research tasks fell from 43,588 to 27,297 tokens, a 37% reduction. In another evaluation, it says Tool Search improved tool-use accuracy for Opus 4 from 49% to 74%, and for Opus 4.5 from 79.5% to 88.1%.
Those numbers should be read as vendor-reported internal results, not as a universal measure of agent reliability. Still, the direction matters. If tool selection improves when the model sees fewer irrelevant options, then scaling an agent may depend less on ever-larger context windows and more on retrieval quality.
That shifts the competitive question. The best tool registry will not merely be the biggest directory. It will be the one with the clearest naming, metadata, examples, ownership information, permission descriptions and retrieval signals. Enterprises that treat schemas as an afterthought may discover that their agent failures are catalog failures.
Programmatic Tool Calling moves orchestration into code
Tool discovery solves the problem of finding a capability. It does not solve the problem of coordinating many calls.
Consider a finance workflow that identifies employees who exceeded a travel budget. An agent might need to retrieve a team list, fetch expenses for each person, retrieve budget limits by role, total the results and identify exceptions. In a natural-language tool loop, each retrieval can become another interaction between the model and the system. The model receives the growing pile of expense rows, reasons over them and issues another instruction.
Anthropic’s Programmatic Tool Calling reverses that flow. Claude writes code in a sandboxed execution environment. The code calls tools, loops through records, filters and aggregates data, then returns the useful result to the model. The raw intermediate state can remain in the executor rather than crowding the language model’s context.
This is where the compiler analogy becomes most concrete. Code makes control flow explicit. A loop is a loop, not a sequence the model must remember to repeat. A conditional is executable rather than implied by prose. Data transformations can be checked, tested and logged. Parallelisable calls can be launched together. Idempotent operations can be retried under a defined policy.
For businesses, the benefit is not only lower token usage. It is more predictable unit economics. A natural-language loop ties workflow complexity directly to model interaction. A programmatic execution layer can reserve model inference for judgment, ambiguity resolution and user-facing explanation, while using cheaper deterministic computation for repetitive work.
That division also creates a more defensible product. If every agent company uses broadly similar frontier models, differentiation will increasingly come from the orchestration layer around them: integration quality, runtime safety, evaluation harnesses, policy controls and domain-specific execution logic.
Planning and execution should become separate products
The strongest design principle emerging from Anthropic’s material is not “let the model write more code.” It is to separate planning from execution deliberately.
Anthropic’s analysis of Claude Code use in practice found a comparable division of labour in interactive coding sessions. Users made about 70% of planning decisions on average, while Claude made about 80% of execution decisions. The report examined roughly 400,000 sessions involving about 235,000 people between October 2025 and April 2026.
That pattern is relevant because it suggests a durable operating model for enterprise agents. People and models should usually retain control over objectives, constraints and definitions of success. The system should take responsibility for implementing approved steps efficiently, within a bounded environment.
Boundary separates planning from credentialed execution
This separation forces useful questions that prompt-first agents can obscure:
- Which decisions must remain visible to the model?
- Which intermediate records can stay inside the runtime?
- Which tools are read-only, and which can alter a production system?
- Which actions need human approval before execution?
- Can a failed action be retried safely?
- Can an incorrect action be reversed, or only detected afterward?
The answers determine whether an agent is a productivity assistant or an operational risk.
The critical case: better orchestration can hide more risk
The case for programmatic tool calling is strong when a workflow is large, repetitive and data-heavy. But the same features that improve efficiency can reduce visibility.
A one-call-at-a-time tool loop is inefficient, yet it has a simple virtue: every operation is exposed to the model and often to the user-facing trace. A code executor can combine dozens of actions into a single program. That is precisely what makes it powerful. It is also what can make approvals too coarse.
An agent may receive permission to run a useful looking script that performs many individual operations, some more sensitive than the original request implied. If a tool registry describes a capability poorly, the model can retrieve the wrong function at scale. If output schemas are ambiguous, the generated code can parse results incorrectly. If the sandbox has overly broad credentials, compact execution can turn a small planning error into a rapid sequence of real-world changes.
The correct response is not to abandon the architecture. It is to treat the executor as a policy enforcement point, not a convenience feature.
A production design should attach authorization to each tool call, not only to the generated program. It should apply least-privilege credentials, make side effects explicit in metadata, distinguish read operations from write operations, and require stronger approval for irreversible actions. It should log both the high-level plan and every resolved call. It should also preserve enough intermediate evidence to audit a result without automatically placing all of that evidence back into the model context.
In other words, the runtime needs controls familiar from conventional software systems: typed inputs and outputs, allowlists, quotas, isolation, testing, observability and rollback strategies. The agent is not exempt from software engineering because it can write the orchestration code itself.
How builders should benchmark the new architecture
The most common implementation mistake will be measuring only token savings. A lower-context agent that selects the wrong tool or quietly performs an unsafe action is not an improvement.
Builders should benchmark at least five layers.
First, test retrieval. Given a large and realistically messy tool catalog, can the agent find the intended function and avoid near matches? Include confusing names, overlapping capabilities and stale descriptions.
Second, test execution correctness. Does generated code handle empty lists, partial failures, changed response formats, duplicate records and pagination? This is classic software reliability work, and it should be evaluated accordingly.
Third, test policy compliance. Try requests that combine legitimate tasks with unauthorised actions. Confirm that the runtime blocks disallowed calls even if the model produces valid-looking code.
Fourth, measure observability. A reviewer should be able to answer what the agent searched for, which tool it selected, what arguments it supplied, what data it used and why it produced its final answer.
Fifth, measure economics across end-to-end tasks. Count model calls, tokens, tool latency, execution time and human review time. The winning architecture is not necessarily the one with the smallest context footprint. It is the one that improves completion rates and operational cost without widening risk.
The new moat is execution design
Anthropic’s tool features point toward a future in which model providers compete on more than raw reasoning quality. They will compete on how effectively their platforms let developers bind reasoning to action.
Tool Search makes the capability layer scalable. Programmatic Tool Calling makes multistep execution more software-like. Tool examples and precise return formats make schemas more than machine-readable contracts. Together, they redefine the agent stack around selective context, structured orchestration and constrained execution.
The market consequence is straightforward. Basic tool calling will become table stakes. The companies that win enterprise deployments will be those that can make agents cheaper to run, easier to audit and safer to connect to valuable systems.
That is why AI agents are becoming compiler problems. The hard question is no longer whether a model can call a tool. It is whether an organisation can reliably translate a human goal into a sequence of authorised, observable and economically sensible operations.
Rebeca Smith is not a person. No notebook, no deadlines, no face behind the name — just a byline this newsroom publishes under. Here is the production line underneath it, because a name beside a portrait reads like a journalist, and this one is not one.
The models. Writing: gpt-5.6-luna and qwen3-max. Out on the live web: gpt-5.6-luna and gpt-5.6-terra. Pictures: gpt-image-1 and gpt-image-1-mini. Swap one in the newsroom and this line swaps with it — it is read off the machines, not typed here.
How a story is made
- Research. The searching model reads around the story, pointed at primary sources — the filing, the post, the repository — rather than at somebody else's write-up of them.
- Writing. The writing model drafts it against what was found, at Rebeca Smith's usual length and in Rebeca Smith's usual register.
- The loop. A reviewer reads the draft and sends it back with notes. Then reads it again. A piece can go round several times before it leaves the building.
- Enrichment. A quotation has to appear word for word on the page it is taken from. A chart may only use figures that appear in the source it cites. Whatever fails is dropped, and the reason is kept.
- Fact check. A last pass hunts for claims the article makes and its sources do not.
- A human stop. Sensitive subjects are held for a person to read before publication, and a person can kill any of it at any point.
If that sounds less like a newsroom and more like a factory: quite. It is called Press Factory.
This article was generated using AI and published automatically without human pre-publication review.
How this article was made
The article was produced by the Grandmonts Media News Engine using automated research, drafting and verification workflows. No human editor reviewed the article before publication. Grandmonts Media remains responsible for the published content. Errors can be reported at office@grandmonts.cz.