Anthropic Quietly Rebuilt Tool Calling for Claude. Here Is What Changed

A Four-Person Electrician Firm and the Back Office That Could Not Keep Up

The electrician firm I want to walk through has four licensed technicians, one office manager, and a volume of incoming work that generates more administrative load than the office manager can handle comfortably on her own. Customer inquiries arrive through the website contact form, through direct calls, and through text messages at all hours. Each inquiry typically asks about availability for a specific job type, wants a ballpark estimate, and needs a follow-up appointment scheduled if the estimate seems reasonable.

Before the firm started using AI automations for back-office work, answering a single inquiry about a panel upgrade involved checking the job calendar manually, looking up the current pricing sheet for 200-amp service work, estimating material costs from a supplier price list saved as a PDF, and drafting a reply that pulled all of that together. On a busy day with 15 incoming inquiries, this was three to four hours of work. Not three to four hours of skilled electrical work. Three to four hours of information retrieval and typing, the kind of work that drains the office manager's capacity without producing anything that could not be templated.

The firm started running AI agent automations about eight months ago using standard tool calling: one function call per action, JSON parameters passed back and forth between the model and the functions, results fed back into context as the model decided each next step. That setup helped, but it broke in specific ways that revealed a deeper problem with how the agents were working. Understanding those breaks is the key to understanding why what Anthropic just shipped matters for businesses operating at this scale.

What Actually Broke When the Agent Tried to Handle Multi-Step Quote Requests

The pattern that caused the most problems was multi-step quote requests: an inquiry that required checking the calendar, looking up current wire pricing from the supplier, checking whether a specific panel brand had any known compatibility issues worth mentioning, and assembling a draft reply with an estimate and available appointment slots.

Under the old tool calling architecture, this was five or six separate function calls executed sequentially. The model called the calendar check function and got back a list of open slots with associated metadata about each appointment, including location data, technician assignments, and job type classifications that were not relevant to drafting the reply. That full result loaded into context. Then came the pricing lookup, which returned a catalog page that included the relevant wire pricing along with surrounding catalog content for adjacent products. That full page loaded into context too. Then the compatibility check, another full result. By the time the model had what it needed to draft the reply, its context window contained three large result blobs, most of which were not relevant to the specific inquiry.

Two problems followed from this. First, cost: every unnecessary token in the context window is a charge, and the accumulated metadata from five sequential tool calls was generating significant token usage per inquiry at a point when the firm was processing dozens per week. Second, consistency: the model's behavior when its context is congested is less predictable than when it has clean, relevant information to work with. Occasionally a reply would include information that seemed to have leaked from a previous inquiry, or would cite a material cost from a page section that applied to a different product than the one being quoted. These were not catastrophic failures, but the error rate required manual review of every AI-generated draft before it went out, which partly defeated the time-saving purpose of the automation.

The Architecture Change: One Script That Invokes Many Functions at Once

The Anthropic upgrade that changed this is programmatic tool calling. Instead of the model being the glue between individual function calls, you give it an environment where it can write a single piece of code that invokes multiple functions using loops and conditionals. The noisy intermediate results, the full calendar metadata, the surrounding catalog content, the compatibility page, stay inside the code. Only the extracted, relevant information reaches the model's context window.

The translation to the electrician scenario: instead of calling the calendar function, processing the result, calling the pricing function, processing that result, and so on, the model writes one short script. The script queries the calendar and filters to the three nearest open slots. It calls the pricing lookup and extracts just the line item for 200-amp copper wire. It checks the compatibility database and returns only a flag and a brief note if an issue exists for the specified panel brand. It assembles these three filtered outputs into a clean object containing exactly the information needed to draft the reply.

The full calendar metadata never touches the model's context. The surrounding catalog content never touches the context. The model works from a filtered summary of exactly what it needs. The result is fewer tokens used per query, more consistent behavior across queries, and the ability to process more concurrent inquiries without the context congestion that was causing the occasional bleed-over errors.

Turning it on required two configuration changes: adding a code execution tool to the agent and setting an allowed-caller parameter on each existing function to specify that the code execution tool is authorized to call it. No structural rebuild of the automation. No new functions. Two parameter changes that activated a fundamentally different execution path.

There is also a clear conceptual reason this works better than the old approach. Research on how language models reason shows they are far more reliable when writing code than when forced to emit rigid JSON schemas one function call at a time. Forcing the model to act as the glue between API calls through JSON is like asking a gifted writer to compose their best work in a language they learned last month. The underlying capability is there, but the format severely constrains the expression. Code is the format the model actually thinks well in, and the results show it consistently.

What the Workflow Actually Looked Like After the Switch

The first week after the switch, token usage on quote requests dropped by roughly 35 percent compared to the same volume of inquiries the prior week. The manual review rate also dropped: draft replies that needed correction before sending fell from about one in four to about one in twelve. The office manager went from reviewing every draft to spot-checking a sample, and the drafts that did not need changes were going out faster because the automated step was completing in fewer round trips.

The qualitative difference was visible in the draft quality as well. The old drafts occasionally had a generic or slightly misaligned tone because the model was working from a congested context where some of the most recent signals were from a previous inquiry. The new drafts were more cleanly specific to the current inquiry because the model's context contained only what was relevant to the current job. A quote for a panel upgrade in a house with a 20-year-old Federal Pacific panel included the specific note about that panel type's known issues. A quote for a straightforward service upgrade in a newer house did not include that note. The code-level filtering was producing context-appropriate responses without requiring any changes to the underlying prompt.

Tool Search Fixed the Agent Drowning in Schema Definitions

Three months into running the new tool calling architecture, the firm had expanded the agent's toolset. They added a function for checking permit requirements by job type and jurisdiction, a function for pulling recent material cost updates from the supplier's API, and a function for generating invoice drafts from completed job data. The total tool count reached 14 functions.

At 14 tools, loading every schema at the start of each session was eating into the context window budget before the inquiry content even arrived. Each schema definition is not enormous on its own, but 14 of them together represent a fixed overhead that left less space for the actual content of a complex multi-step inquiry.

Tool search solved this. Instead of loading all 14 schemas at the start of every session, a single search tool retrieves only the relevant schemas for the current task. A quote request retrieves the calendar, pricing, and compatibility schemas. An invoice draft retrieves the job data and invoice generation schemas. A permit inquiry retrieves only the permit requirements schema. In each case, the tool loading overhead drops from 14 schemas to two or three, freeing context space for the actual work. Anthropic's documentation describes this as potentially freeing up to 80 percent of the schema overhead from the context window, which matches what the electrician firm saw in practice. The savings per session compound meaningfully at 40 or 50 sessions per week.

What the Ninety Percent Accuracy Number Means for a Real Scheduling Function

Anthropic published results showing that adding worked input examples to complex tool definitions lifted accuracy from 72 to 90 percent on tricky parameter handling. For the electrician firm, the scheduling function was where this mattered most. The function accepted a job type, a duration estimate, a geographic zone, and a priority flag, and it needed all four in exactly the right format to query the calendar correctly.

Before adding examples, the agent occasionally called the scheduling function with the priority flag in the wrong format or with the geographic zone at the wrong level of granularity. These calls failed silently, which meant the model would retry with a slightly different format, sometimes succeeding and sometimes not. The retry behavior added latency and token cost for every failed call, and the latency was noticeable on multi-step inquiries where the scheduling function was one of several calls in a sequence.

After adding three worked examples showing the correct parameter format for the three most common job types, accuracy on scheduling function calls improved dramatically. The examples showed the model exactly how to construct the call for a residential panel job, a commercial service upgrade, and an emergency repair, covering the range of variation in the parameter structure. The model generalized from those three examples to correctly handle new job types not shown in the examples. Failed calls on the scheduling function dropped to near zero. The latency from retries disappeared. The token cost from retries disappeared with it.

Three Configuration Steps That Made the Full Architecture Stick

The full upgrade from old-style tool calling to the new architecture reduced the firm's agent API costs on inquiry handling by roughly 40 percent over the first month, eliminated the bleed-over errors that had required manual review of every draft, and brought the office manager's spot-checking rate down from 25 percent of drafts to around 8 percent.

The three configuration changes that drove the improvement: adding the code execution tool and setting the allowed-caller parameter on each function to activate programmatic calling; switching the 14-function toolset from full-load to tool search with a single retrieval schema, which freed the schema overhead from the context window; and adding three worked examples to the scheduling function, which took call accuracy from roughly 72 to 90 percent.

None of these required rebuilding the underlying automation. They were configuration additions to an existing setup. The cumulative effect was an agent that costs 40 percent less to run, makes fewer errors, and requires less human oversight, without any expansion of what the agent is asked to do. The same inquiries, the same functions, handled more cleanly at a lower operating cost.

For any business that has already invested in building AI automations and is now paying real money to run them, the upgrade path Anthropic shipped is one of the clearest returns on a few hours of configuration work available right now. The tools exist. The parameters are documented. The outcome for anyone running complex multi-step agent workflows is lower cost, more consistent output, and less human intervention to catch the errors that the old architecture produced at a background rate that everyone had normalized but nobody had measured precisely enough to know what fixing it was worth.