Cloud Agents Should Use (Some) Code Execution

There are two ways to make an agent faster: call the model fewer times, or trim the repeated work from the calls that remain. This approach mainly addresses the former.

Tool calls are not intrinsically expensive; the cost comes from repeatedly injecting their results into a synchronous model loop. The difference becomes clear when we compare how often each approach crosses the provider boundary.

Model: decide what to read
  -> read_section
Model: interpret the text and draft the edit
  -> propose_edits
Model: read the staging result and write the final answer

Model: judge, draft, write the restricted program and response
  -> local SDK locates and validates the target, then stages it

Remove Repeated Model Work

A small, restricted code cell avoids much of that repetition by handling mechanical work such as searching, filtering, comparing, aggregating and transforming data inside one execution. The model still decides what matters and interprets the result, while the host application controls permissions, approvals and merges.

Intermediate pages, duplicate matches and irrelevant records stay inside the execution environment, so the model sees only what it needs for the next decision. This is most useful when the mechanics repeat but the path varies: keeping only matching records or stopping as soon as the answer is clear.

Keep the Remaining Context Small

Reducing model calls is only one part of the optimisation. The calls that remain should also carry less context: tools can be loaded only when needed, and large outputs can be filtered before they reach the model.

Keeping model-visible history append-only and tool ordering stable makes more of the prompt reusable, while applying approval rules at runtime avoids changing the tool definitions. The same foundations make subagents easier to deploy: each can inherit a stable, cacheable base configuration while runtime policy narrows its permissions for the task.

How an Edit Moves Through the System

The code cell can prepare an edit, but it cannot apply one directly. The change moves through three controlled steps:

1. 1

   The model decides and drafts

   The model gets enough context to find the clause, decide the change and draft an explanation, but no access that could alter the document.

2. 2

   The code finds the right section

   The SDK finds one exact target and builds the edit plan locally, without another model call.

3. 3

   The host checks and stages the edit

   Lexifina validates the document, snapshot, target and edit plan before staging it for human review. If validation fails, the draft response is discarded.

Lexifina's guardrails stay active throughout. If the program needs an authorised host tool, it pauses while the application checks permissions and returns a verified result, then resumes without another model call.

Results Across 100 Samples

We compared both approaches across 100 runs, spanning rewrites, discovery, risk analysis, reasoning and co-ordinated edits. Documents, prompts, model family, SDK, tool policy and the no-apply rule stayed fixed.

When to Use Code

There is a crossover point. Generating and validating the program, then starting the sandbox, creates a fixed cost that only pays off when there is enough local work or enough model round trips to avoid. One or two small sequential calls may still be faster as ordinary tools.

Code execution should not be confused with delegation. A code cell keeps tool-heavy work inside one agent, while a subagent gets its own model context for independent reasoning. Its instructions, sandbox, tools and skills can narrow its capabilities, with labelled approvals and client controls allowing a person to inspect, steer or stop it. In short, code cells reduce work within a role; subagents divide responsibility between roles.