Stop Giving Your Agent Tools. Give It a Sandbox - Mikyo King, Arize AI

Mikyo King, head of open source at Arize AI, explains code mode, an agent architecture where the model searches for tools and composes them in a sandboxed programming environment instead of loading large tool catalogs into context. He covers why it works, how Arize built it into Phoenix with Bash, Python, SQL, and UI control, its hidden costs around secrets, permissions, durability, and double sandboxing, and Harbor evals showing 43% fewer tokens and 31% lower cost.

6 min read
Stop Giving Your Agent Tools. Give It a Sandbox - Mikyo King, Arize AI
source: https://www.youtube.com/watch?v=dAoOYFx7ZYw

The context problem with classic tool calling

In a classic tool-calling agent, the model receives a large catalog of tools up front, and every call and its raw output is pushed into the context window. As tasks grow longer and more emergent, this produces context rot, more turns, and eventually the need for compaction. Each extra turn adds latency and cost and delays the moment a user gets value.

What code mode changes

Code mode replaces the tool menu with two capabilities: the agent can search for a specific tool, and it can execute tools inside a programming environment. Calls can run sequentially, in parallel, fanned out, or wrapped in conditionals. Several tools can run in a single turn, and only the result that is actually needed returns to the context. Mikyo King frames this within a broader shift. The boundary between engineers and non-engineers is dissolving, because coding agents can build bespoke software on demand. Foundation models are trained on coding benchmarks such as SWE-bench precisely for this kind of work, so it makes sense to align agents to build the software they need dynamically.

Why code mode works

  • Progressive disclosure: tools are discovered and understood only when needed, rather than loaded all at once. Native tool search in model providers is moving in the same direction.
  • Composability: chaining and fanning out tool calls enables far more complex and efficient workflows. The same principle underlies composition of sub-agents.
  • Token efficiency: intermediate outputs stay in the sandbox. The model can trim and search data dynamically and bring back only what it needs.
  • Emergent behavior: the agent can write its own tools. Consider removing personally identifiable information from a set of records. A traditional agent has no tool for this, and attempting it in the context window leaks sensitive values such as credit card numbers. Code can process the records programmatically without exposing them.

How Phoenix uses code mode

Arize built an agent and harness inside Phoenix, its open source observability platform, with several surfaces:

  • Bash, for composing Linux primitives like sed and grep with the Phoenix CLI, and for offloading results to files for later use.
  • A Python sandbox, with the REST CRUD endpoints for operations such as fetching traces and manipulating datasets hoisted into it, so the agent can compose create, read, update, and delete operations.
  • SQL, for aggregate questions such as finding every LLM span above a given P95 latency. Without SQL, the agent would have to paginate through all traces to answer.
  • UI control: a programming paradigm bound to the interface, running in a web worker with two-way data binding to the browser. The agent can change the time range, read data from the front end, and perform complex interactions, which Mikyo describes as emergent computer-use behavior.

The hidden costs

Code mode is not free. Generated code is untrusted, and hosted sandboxes consume CPU, memory, and lifetime budget. Network egress is a serious concern once the agent can reach the open web. Secrets must be vaulted so that using them inside a sandbox, for example to call an external service from code, never returns them to the context window. Permissions tend to be overbroad. They may be correct for the first five operations and wrong on the sixth, or wrong only once operations are composed.

Operational complexity grows as well. Sandboxes do not always boot cleanly, and failures are harder to debug because you are debugging code rather than individual tool calls. Tool parameter accuracy becomes a larger problem when the parameter is itself code. Tool discovery adds a handshake step before the model knows its catalog. As code mode appears both in MCP servers and in agent harnesses, double sandboxing emerges. Outputs are serialized as JSON from one sandbox, parsed, and fed into another code-mode environment, which adds overhead and complexity.

Open problems

Durability is unresolved. If a large script breaks midway, there is no way to resume from that step. Determinism and mathematical work may force a reconsideration of language choice, since JavaScript is strong for LLM-generated code but weaker for math. Multimodal output is also difficult. Moving images or binary data out of the sandbox without serializing the whole payload into context may require a signed handoff mechanism. Finally, frontier models excel at code mode, but if you swap in a smaller model to cut costs, its capabilities may not reach the same level.

Evaluating code mode with Harbor

Arize evaluated code mode by dogfooding Phoenix and running agents through permutations in the Harbor framework. Agents run in sandbox environments with clear instructions and network access disabled. Each task runs across multiple trials to absorb flakiness, since agents in indeterminate systems can take different trajectories. Evals are written as Harbor verifiers that return a binary reward, one for pass and zero for fail, in an RL-style setup. Pass at k is tracked for each task that should pass.

Compared with the baseline, code mode reduced tokens by 43% and cost by 31%. Sandbox overhead was real, but latency stayed roughly constant. The improvement held across surfaces, including Claude Code, MCP, and the CLI.

Improving agents from trajectories

Capturing both trajectories and evals makes it possible to hill climb agent behavior. Introducing a new tool can initially reduce efficiency. By examining which parts of the instructions push the agent in the wrong direction, teams can explain the failure to a coding agent and iterate on the eval results to make agents better.

The core payoff is fewer turns, lower cost that makes it practical to bring any model, and emergent behavior that supports long-horizon tasks. The practical recommendation is to give your agent a sandbox and then evaluate it rigorously.

Share post

Stay In The Loop! Subscribe to Our Newsletter.

Get updates straight to your inbox. No spam, just useful content.

Recommended for You

MCP Doesn't Suck. Your Agent Does. — Jan Čurn, Apify

MCP Doesn't Suck. Your Agent Does. — Jan Čurn, Apify

Jan Čurn, founder and CEO of Apify, argues that the backlash against MCP targets the wrong layer. Context bloat and token burn come from naive agent harnesses, not the protocol. He reviews the industry's three main fixes (sub-agents, progressive tool discovery and Code Mode), explains why agents work well with CLIs, proposes MCP for remote access and CLIs for local use, and demos mcpc, Apify's open-source universal MCP CLI client, alongside early Connector Evals results.

What Is Loop Engineering? Building Better AI Agents

What Is Loop Engineering? Building Better AI Agents

Martin Keen explains loop engineering as the next step beyond prompt engineering: designing systems where AI agents act, observe, adjust, and repeat toward verifiable goals. The discussion covers goal design, triggers, context and persistent state, tools via MCP and APIs, verifier subagents, and why humans must remain in the loop to manage comprehension debt, intent debt, and cognitive surrender.