Enter the era where AI agents stop drowning in endless tool invocations and start wielding concise scripts that do the heavy lifting behind the scenes. The recent experiment conducted by the Agent Swarm team illustrates a striking shift: a single, self‑contained script replaced twenty‑six discrete tool calls, slashing the token footprint from roughly eight hundred thousand to just over six thousand. This transformation is not a theoretical curiosity; it emerged from real production data, measured against live workflows and schedules. By moving the bulk data processing into a sandboxed subprocess, the agent only receives a compact summary object, keeping its context light and responsive. The approach aligns with the broader industry movement toward “Code Mode,” where agents are granted a generated API instead of raw tool endpoints, allowing them to write and execute code locally. The result is a dramatic reduction in latency, cost, and complexity, opening the door for more sophisticated agent behaviors without the usual overhead. Beyond pure savings, the pattern improves reliability because fewer moving parts means fewer points of failure, and it enhances maintainability since the script version can be updated centrally without touching each agent’s prompt. In the following sections we break down how the experiment was set up, what the numbers reveal, and why this pattern matters for anyone building or operating autonomous agents at scale.

Every time an agent makes a tool call, the raw JSON payload flows directly into its conversation history, where it competes for limited context space alongside the model’s own reasoning tokens. When a task requires dozens of calls—such as enumerating workflows, schedules, and their recent executions—the cumulative payload can balloon to hundreds of thousands of tokens, effectively crowding out the model’s ability to think, plan, or generate nuanced responses. In the Agent Swarm setting, a naïve implementation of the workflow‑triage check would have issued twenty‑six separate requests: one to list all workflows, another to list all schedules, and then a distinct call for each workflow’s run history. Each of those responses, sometimes stretching into tens of kilobytes, would remain in the agent’s memory until the conversation ended or the context was trimmed. This not only inflates the cost per turn but also introduces latency as the model must parse and discard large blobs before it can focus on the next instruction. By contrast, encapsulating the same logic inside a script lets the subprocess handle the data transfer, perform any needed filtering or aggregation, and return only a distilled result. The agent’s prompt stays short, the model can devote its full attention to higher‑level reasoning, and the overall turn becomes faster and cheaper. This illustrates a fundamental principle: moving bulk data processing out of the model’s context is not just an optimization—it is a prerequisite for scalable, reliable agent behavior. The technique also simplifies debugging, because failures are isolated to the script’s sandbox rather than scattering trace fragments across the agent’s context, making it easier to pinpoint the root cause without sifting through megabytes of JSON.

The script at the heart of the experiment, identified globally as da3b5c7b‑b9a6‑4f9e‑be9e‑f682aca48ea0, is deliberately minimalist: it contains no external frameworks, no dependency management, and no elaborate abstractions. Instead, it consists of a straightforward for loop that iterates over the list of workflows, launches up to six concurrent requests to fetch each workflow’s run history, and collects the results into a single array. A couple of Date.parse calls normalize timestamps, and a final sort orders the entries by recency before the script returns a compact JSON object summarizing which workflows are active, which have failed, and which appear dormant. Because the entire operation runs inside a sandboxed subprocess, the large payloads generated by each workflow_listRuns call never leave that isolated environment; they are processed, reduced, and discarded locally. The agent that invokes the script receives only the final summary—roughly twenty‑six kilobytes of text, translating to about 6,450 tokens when encoded for the model. This stark contrast to the naive approach, where each of the twenty‑six calls would dump its raw JSON straight into the agent’s context, demonstrates how a few lines of procedural code can replace dozens of tool invocations while preserving all the information needed for downstream decisions. The script’s simplicity also means it can be audited, versioned, and reused across any agent in the swarm without worrying about compatibility layers or runtime mismatches.

To validate the savings, the team ran both the scripted version and the raw‑call version against the actual production catalog, which at the time comprised twenty‑four workflows and sixty scheduled jobs. The raw‑call baseline was constructed by sequentially invoking the three core tools—workflow_list, schedule_list, and workflow_listRuns for each workflow—and recording the wall‑clock time and token consumption of each response. Because the raw responses vary in size depending on recent activity, the team took the observed total and extrapolated a conservative floor estimate, assuming each call returned at least the minimum viable payload. The scripted path, by contrast, was executed once, its output captured, and the resulting character count converted to tokens using the model’s tokenizer. All measurements were performed on the same hardware and network conditions to eliminate environmental variance, and the timing was measured with high‑resolution timers that captured both the subprocess execution and the overhead of marshaling the result back to the agent. The raw‑call duration was estimated by summing the individual latencies observed in a separate micro‑benchmark, while the script’s duration was measured directly from start to finish. This careful separation of measured and estimated components ensures transparency: the token reduction figure is grounded in actual data, whereas the cost projection relies on a clearly explained extrapolation that readers can replicate or adjust.

The raw‑call floor estimate came in at approximately 815,000 input tokens, a figure driven largely by the repetitive transmission of workflow run histories that can each span several thousand lines of JSON. The scripted version, after completing its internal aggregation, yielded a measured output of 25,811 characters, which the tokenizer mapped to roughly 6,450 tokens. This represents a token reduction of about 99.2 %, meaning that for every hundred tokens the naive approach would consume, the scripted approach needs less than one. When the same numbers are expressed in monetary terms using Claude Sonnet 5’s pricing— the model that powered the measurements—the raw path would have cost on the order of several dollars per invocation, whereas the scripted path costs mere cents. Importantly, the reduction ratio remains stable across different models because it is rooted in token count, not in any particular provider’s rate table. Whether the agent runs on GPT‑4, Gemini‑Pro, or an open‑source LLM, the scripted method consistently delivers a two‑order‑of‑magnitude shrinkage in the amount of data that must occupy the model’s context. This consistency makes the technique a portable lever for cost control that teams can apply regardless of which language model they choose to serve as the agent’s reasoning engine.

Translating the token savings into real‑world economics reveals why the pattern matters for production systems operating at scale. Using the live pricing table pulled from the swarm’s internal cache, the scripted workflow‑triage call was priced at roughly $0.02 per execution, while the extrapolated raw‑call baseline hovered near $2.50—a difference of more than two orders of magnitude. In a scenario where the triage runs every fifteen minutes across a fleet of thousands of agents, the annual savings would climb into the six‑figure range, freeing budget that could be redirected toward model fine‑tuning, richer feature development, or additional safety guardrails. Latency improvements were equally pronounced: the script completed in about 13.12 seconds, whereas the sequential raw‑call approach, when estimated from individual tool latencies, would have taken well over a minute to finish. That difference not only reduces user‑perceived delay but also lowers the chance of hitting timeout thresholds in orchestration pipelines. Moreover, because the script runs in a isolated subprocess, its execution time does not contribute to the agent’s turn‑taking budget, allowing the model to allocate its full inference time to higher‑level planning rather than waiting for I/O. Together, these economic and performance gains make a compelling case for adopting code‑mode patterns wherever agents need to interrogate large, repetitive data sets.

The findings echo earlier work from Anthropic and Cloudflare, yet they provide a concrete, production‑grade validation that bridges the gap between benchmark numbers and everyday operations. Anthropic’s November paper demonstrated that replacing a series of tool calls with a generated MCP API could shrink a 150,000‑token workload to just 2,000 tokens—a 98.7 % reduction achieved by keeping intermediate results out of the model’s context. Cloudflare’s subsequent “Code Mode” posts showed similar effects, reporting that a search‑and‑execute pattern spanning over 2,500 API endpoints fell from 1.17 million tokens to roughly 1,000 tokens. The Agent Swarm experiment reproduces that magnitude of improvement using a real‑world administrative script rather than a synthetic benchmark, confirming that the benefits are not limited to toy examples. It also highlights an important nuance: the savings scale with the volume of data each tool call returns. When a tool fetches a modest configuration blob, the absolute gain may be small; but when the tool returns extensive logs, run histories, or telemetry streams, the advantage becomes dramatic. This insight helps teams prioritize where to apply code‑mode refactoring—focus first on the high‑volume, repetitive calls that dominate token consumption, and leave low‑overhead calls untouched unless they participate in a larger fan‑out pattern.

For developers building AI‑driven automation platforms, the experiment offers a clear architectural guideline: treat the agent’s context as a precious resource that should be reserved for reasoning, planning, and goal formulation, not for shoveling raw data back and forth. By delegating data‑intensive tasks to sandboxed scripts or generated APIs, agents can maintain shorter conversation histories, which in turn improves the coherence of long‑running dialogues and reduces the likelihood of context‑overflow errors that force costly truncations or resets. The pattern also dovetails nicely with emerging standards such as the Model Context Protocol (MCP), which encourages the exposure of tool capabilities through typed, callable interfaces rather than raw endpoints. When agents are supplied with a strongly typed API, they can compose complex workflows using familiar programming constructs—loops, conditionals, error handling—while the underlying platform takes care of serialization, transport, and result consolidation. This shift not only enhances developer productivity but also improves observability, because the script’s logs, metrics, and error traces are captured in a dedicated execution environment that can be monitored independently of the agent’s reasoning loop.

The broader market is already moving toward mechanisms that minimize context bloat. Observability platforms are beginning to offer token‑usage breakdowns per turn, prompting teams to spot costly call patterns. Cloud providers are experimenting with inference‑endpoint pricing models that charge per token processed, making every extra byte a direct cost center. Simultaneously, the rise of agent frameworks that support pluggable “code modules” reflects a recognition that the most efficient agents are those that can offload heavy lifting to specialized runtimes. In enterprise settings, where thousands of autonomous agents may be orchestrated to monitor pipelines, reconcile data, or trigger remediation workflows, the cumulative impact of context inefficiencies can translate into millions of dollars of unnecessary compute spend each year. Early adopters who have embraced code‑mode patterns report not only lower operating expenses but also faster iteration cycles, because scripts can be version‑controlled, unit‑tested, and deployed independently of the agent’s prompt engineering process. As the ecosystem matures, we expect to see more tooling that automatically detects fan‑out opportunities and suggests reforing into code‑mode constructs, much like linters flag excessive loops or memory leaks in traditional software development.

For teams eager to capture similar gains, the first step is to instrument their agent logs to capture the size and frequency of each tool call. By aggregating this data, it becomes straightforward to identify the handful of endpoints that contribute the bulk of token traffic—often the list, search, or history APIs that return large arrays or logs. Once those hotspots are isolated, the next move is to prototype a lightweight script that replicates the same logic inside a sandbox. The script should accept the minimal set of parameters needed to drive the calls, perform any required filtering or aggregation internally, and emit a compact summary object that the agent can act upon. It is essential to keep the script’s dependencies minimal and to version it as a standalone asset, perhaps stored in a centralized script registry that all agents can reference by identifier. After the prototype is functional, run a side‑by‑side benchmark using real production data, measuring both wall‑clock time and token consumption, exactly as the Agent Swarm team did. Finally, integrate the script into the agent’s standard toolkit, update the system prompt or configuration to prefer the scripted path when the detected fan‑out exceeds a configurable threshold, and monitor the resulting metrics to ensure the expected savings materialize in live traffic.

While the code‑mode pattern delivers impressive efficiency, there are several common pitfalls that can erode its benefits if not addressed early. One mistake is to over‑engineer the script, pulling in heavyweight libraries or complex build steps that increase cold‑start latency and offset the token savings. Keeping the script dependency‑free and relying only on the runtime’s standard library helps maintain predictable performance. Another risk is to forget about error propagation: if the script fails silently, the agent may receive an empty or malformed summary and make incorrect decisions. Implementing structured error objects, logging exceptions to a dedicated channel, and defining clear fallback behaviours are crucial for reliability. Security considerations also arise because the script runs in a sandbox that nevertheless has access to the same credentials as the agent; teams must enforce the principle of least privilege, scoping the script’s permissions to the exact data it needs. Finally, it is tempting to treat every tool call as a candidate for script conversion, but doing so for low‑volume, tiny payloads can add unnecessary complexity without meaningful gain. A disciplined approach—guided by measured thresholds on token usage or call frequency—ensures that refactoring efforts are focused where they deliver the highest return on investment.

To put these insights into practice, begin by instrumenting your agent’s tool interactions today and run a quick audit to spot the top three contributors to token consumption. Write a minimal script for the most expensive call, benchmark it against the raw version using a representative data slice, and verify that the token count drops by at least ninety percent while latency stays within acceptable bounds. Register the script in a central repository, tag it with a clear version number, and update your agent’s configuration to invoke it whenever the call pattern matches a predefined fan‑out rule. Set up alerts that notify you if the script’s execution time drifts upward or if error rates rise, ensuring that the efficiency gains do not come at the cost of reliability. Finally, share the results with your team and iterate: as new workflows are added, revisit the audit, and continuously refine the threshold that triggers code‑mode usage. By treating the agent’s context as a finite resource and systematically offloading bulk data to sandboxed scripts, you will not only cut costs but also create a more resilient, observable, and scalable automation foundation ready for the next generation of AI‑driven applications.