Why Nexus drives tools through code, not calls

There is a design decision at the centre of Nexus I want to explain. Not because it is unusual — the industry is converging on it — but because the reason we made it is different from the reason others are talking about it, and that difference matters.

When a Nexus Runtime needs to operate your systems, the agent does not call tools one at a time. It writes a program. The program executes in a sandbox. Only the result comes back.

Most people talking about this pattern are talking about token efficiency. That is real. But token efficiency is not why we built it this way.

The tool-call loop and why it breaks

The standard pattern for AI agents is the tool-call loop. The model reasons, emits a structured tool call, receives the result, reasons again, emits another call — one action at a time, round-tripping through inference after each step.

This works for simple tasks. It breaks for real operational workflows, in two distinct ways.

The first is mechanical. Real workflows require conditions, sequences, and data that flows between steps. An agent that needs to check whether an order is in a cancellable state before calling cancel — and then confirm the result — needs to evaluate step one before acting on step two. Re-invoking inference for that conditional logic is using a language model as a slow, expensive if-statement.

The second is deeper. Each round-trip is a new reasoning decision. The agent correctly following your rules on step three might not follow them on step seven — not because the rules changed, but because attention drifts, context shifts, and each inference pass is independent. The operational knowledge governing the workflow is not compiled into the execution. It is re-applied, probabilistically, on every turn.

That is not a performance problem. It is a correctness problem.

What writing a program actually changes

Consider what the upstream AI experiences. It sends one message — an intent — and receives one result. It never sees a tool catalogue, never waits for intermediate results, never holds partial state across multiple round-trips. One call in. One conclusion out.

Everything between — the domain reasoning, the program, the execution, the data processing — happens inside Nexus. None of it enters the upstream AI's context. The downstream complexity is invisible to the upstream caller, by design.

The model reasons once. It produces a complete expression of intent — a program that encodes the logic, the conditions, the data transformations, the sequence of operations — and hands it to the execution environment. One reasoning act. One execution. One result.

Intermediate data stays in the execution environment. The program filters, joins, and processes — then returns only the conclusion. The model sees the result, not the journey. The system querying ten thousand records to find the three that match a condition sends three records back, not ten thousand.

The efficiency gains are a side effect. The real property is this: a program is a stable, auditable, complete expression of what the agent decided to do. It can be read and inspected. A sequence of tool calls that produced the same outcome cannot — the reasoning that produced each call is gone.

What a program cannot enforce on its own

This is where the naive version of the argument breaks down — and where I want to be precise.

A program executing in a sandbox is only as governed as the reasoning that wrote it. If the agent writes code that violates an operational rule — cancels a dispatched order, bypasses a required verification step, reaches an endpoint that caller is not permitted to reach — the sandbox will execute it faithfully. The sandbox enforces infrastructure boundaries: memory caps, execution timeouts, no host access. It does not know your business rules.

Code execution moves the action surface from "what tools the agent calls" to "what code the agent writes." That is a larger attack surface. Sandboxing alone is not sufficient.

What is sufficient is a layer that governs what the agent is allowed to reason about before it writes anything.

In Nexus, that layer is the domain contract. Before the agent writes a single line of code, it reasons inside a typed model of your domain: entity lifecycles, state transition rules, hard boundaries, access constraints per caller. Not retrieved at query time. Not embedded in a system prompt the model can drift from. Loaded at startup, present on every turn, governing the reasoning before any code is written.

A forbidden operation does not get written into the program because the agent knows — from the contract it reasoned inside — that the operation is forbidden.

Two gates. The contract governs what the agent reasons. The sandbox governs what the code can reach. Together they give you not just efficient execution, but governed execution.

Why we are talking about this now

The convergence is real. Anthropic has published on code execution with MCP. Cloudflare has shipped Code Mode. The academic lineage goes back to CodeAct at ICML 2024. They are arriving here for the right reasons — the efficiency case is correct, the composition argument is correct.

What I think is the more important claim — and the one they have not yet fully made — is the governance argument. The efficiency case for code execution is interesting. The correctness case — that a domain-governed, sandboxed program is the right primitive for AI that operates real systems — is what we built Nexus on.

The question is not just whether your agent reaches your systems. It is whether it operates them correctly. That second question is what a program inside a domain contract, executing in a sandbox close to your data, is designed to answer.

Nexus is a toolsystem agent (powered by Claude) — an AI whose job is to operate your systems correctly, on behalf of other AIs. Built on dataBridges and APIFront.