Understanding Native Tools in Bud Agent Builder: Code Interpreter

Every serious agent eventually needs to do something computational — parse a file, reconcile a ledger, transform a dataset, run a model, generate a chart, validate a calculation. The moment an agent moves from "talk" to "act," the question stops being "can the model write Python?" and becomes "where does that Python run, who can see it, and what can it touch?"

Bud Code Interpreter answers that question at the platform level. It gives each agent a real, isolated Jupyter and bash environment for Python and JavaScript, provisioned on demand and torn down on a policy you control. Underneath, code runs inside Firecracker microVMs — the same hardware-level isolation primitive AWS uses for Lambda — so model-generated code never shares a kernel with your host, never reaches your platform's filesystem, and only touches the network if you explicitly allow it.

Code Interpreter is a native tool inside the Bud AI Foundry control plane, sitting alongside the Model Hub, Deployments, Guardrails, Evaluations, Observability, and RBAC. That means it inherits the platform's governance, audit, identity, and deployment model by default. It is also model-agnostic: it works with any model deployed in the Foundry, not a single provider's hosted models. For the layer underneath it, see Bud Agent Runtime.

Enterprises get frontier-class code-interpreter capability without frontier-class lock-in — no forced model vendor, no forced cloud, no untraceable execution, and no separate sandboxing stack to buy, secure, and operate.

Code Interpreter at a glance

Code Interpreter gives an agent a real execution environment for Python, JavaScript, and bash. The mechanics, from the platform's own design:

• Per-prompt-version ownership. Each prompt or agent version that enables the tool owns its own sandbox. Isolation is the default unit of work, not an afterthought.
• Lazy provisioning. A sandbox is created on the first tool call and reused for every subsequent call within its idle window — variables, installed packages, and uploaded files persist for the life of the sandbox.
• Configurable everything. CPU, memory, network egress, and idle expiry are all controls on the prompt version.
• Firecracker microVMs. Boots in seconds, and keeps the host kernel out of reach of model-generated code.
• Audited by default. Every call is recorded in the platform's observability pipeline, tied to the model invocation that produced it.

Design considerations

These principles are what make the code interpreter an enterprise-grade execution layer rather than a developer convenience. Combining sovereignty, portability, and deep platform integration gives a controlled, auditable, production-ready foundation for running model-generated code at scale.

Sovereign by design, not by exception

Most managed code interpreters are hosted-only. Bud's runs on managed infrastructure or a self-hosted equivalent on infrastructure you control — your Kubernetes cluster, your sovereign region, your air-gapped enclave. For regulated, public-sector, and data-residency-bound enterprises, this is the difference between "we can pilot it" and "we can deploy it in production." Execution of model-generated code, often over sensitive data, never has to leave your trust boundary.

Model-agnostic, so it never anchors you to a vendor

Hosted code interpreters generally only run alongside their own vendor's models. Bud's tool attaches to any model deployed in the Foundry. You can swap the underlying model — open-weight, frontier, fine-tuned, on-prem — without re-platforming your agent's execution layer. Code execution stops being a reason you cannot leave a model vendor.

Native to the platform, not bolted onto it

Because it lives inside Bud AI Foundry, the sandbox inherits the platform's identity, RBAC, project scoping, deployment lifecycle, and unified observability. There is no second control plane to secure, no separate billing relationship, and no glue code between your agent framework and your sandbox provider. One platform, one audit trail, one governance model.

Defence-grade isolation as the default posture

Firecracker microVMs give each sandbox its own kernel — hardware-level isolation, not container syscall filtering that a kernel zero-day can escape. On top of that, the network is off by default: a fresh sandbox cannot reach anything until you deliberately open egress. The secure choice is the path of least resistance, which is exactly what enterprise security teams want.

Governable and fully auditable

Every execution is captured in the observability pipeline next to the model call that triggered it. Security, compliance, and platform teams get a complete, queryable record of what code an agent ran, when, and in what environment — without instrumenting anything themselves. This is what turns "agents that run code" from a security-review blocker into an approvable architecture.

Cost and capacity under operator control

Resource tiers, idle timeouts, and a "never expire" auto-pause and auto-resume mode let operators trade cold-start latency against idle cost deliberately, and size capacity to steady-state active sessions. You pick the smallest tier that fits; larger sandboxes provision identically but draw more from your pool. The economics are yours to tune, not a fixed per-session toll set by a vendor.

The technical differentiators

The defensible claims — the ones worth putting in front of a solution architect or a security reviewer.

Firecracker microVM isolation

Sandboxes are Firecracker microVMs. Each gets a dedicated guest kernel and network namespace, so a guest-kernel vulnerability cannot escape to the host. This is materially stronger than shared-kernel container isolation, and it boots in seconds rather than the tens of seconds a full VM takes.

Per-prompt-version sandbox boundary

Isolation is scoped to the prompt or agent version. Two versions, two end-users, or two threads never share an execution environment by accident — blast radius is contained to a single unit of work by construction.

Stateful sessions with lazy lifecycle

Sandboxes provision on first use and stay warm across turns. Load a dataset once, then ask follow-up questions against it across multiple model turns — no re-uploading, no re-importing, no re-installing. This is where a real interpreter beats a one-shot function call: the model writes and runs many cells over a conversation against persistent state.

Three languages, one kernel

Python and JavaScript ship in every sandbox and share a Jupyter kernel, with a full bash shell alongside. Agents can do data science in Python, manipulate JSON and JS-native payloads in JavaScript, and orchestrate multi-step workflows in shell without switching tools. Many competing code interpreters are Python-only.

Config-driven resource tiers

Eight built-in templates span a cpu ∈ {2, 4} × ram_gb ∈ {2, 4, 8, 16} grid, from a 2 vCPU / 2 GB sandbox for quick lookups up to 4 vCPU / 16 GB for heavier in-memory work. Sizing is a field on the prompt version, not a Dockerfile, a Helm chart, or a node-pool decision.

Custom templates on a hardened base

When the built-in tiers lack a library, you build a custom template through the SDK. It inherits the platform's hardened base image and appends your own RUN, ENV, and WORKDIR instructions. Templates are project-scoped and built asynchronously through a workflow that surfaces pending → building → ready, or failed with an inspectable error. Image-breaking directives such as FROM, CMD, ENTRYPOINT, COPY and ADD are rejected by design, so the security-critical base image and its managed services stay intact — you extend the environment without being able to compromise it.

Three-mode network policy

Egress is disabled by default. Switch to open for full egress, or filtered to apply allow_out and deny_out lists over IPs, CIDR ranges, exact domains, or wildcard domains. An ALL_TRAFFIC sentinel lets you build either a deny-all baseline you selectively open, or a permissive baseline you selectively narrow — with allow rules taking precedence over deny rules. This is policy expressive enough for a security team to actually sign off on.

Ephemeral-by-default data flow

Files uploaded into a sandbox live only until the sandbox is destroyed; there is no persistent storage beyond its lifetime. Anything important is streamed back through the tool's results. The default is "leave no trace," which is the right default for sensitive data.

Features

Use cases

• Conversational data analysis. Load a dataset once, then run an entire investigation across follow-up turns — filters, joins, aggregations, statistical tests — against persistent in-memory state.
• File parsing and transformation. Ingest CSV, Excel, JSON or PDF-extracted content, clean it, reshape it, and stream results back, all inside an environment that cannot touch your platform.
• Ad-hoc calculation and validation. Let the agent verify its own arithmetic, financial maths, unit conversions, or business-rule logic by running code rather than hallucinating an answer.
• Chart and artifact generation. Produce visualisations and computed artifacts on demand inside the sandbox, returned through tool results.
• Multi-step agentic workflows. Use the bash shell to chain CLI tools, manage files, and orchestrate pipelines across turns — the interpreter as an agent's hands.
• Code reasoning loops. When generated code fails, the agent iterates, re-running until it succeeds, instead of returning a broken one-shot answer.

How it compares

Against a hosted vendor interpreter: excellent if you live entirely inside that vendor's models and cloud, but Python-only, model-locked, and hosted-only at a fixed per-session price. Bud wins on sovereignty, model freedom, language breadth, and network governance — the axes regulated enterprises care about.

Against cloud dynamic sessions: a strong, secure primitive, but cloud-bound, and still a building block you have to assemble into an agent platform yourself. Bud delivers the same security posture already integrated with model serving, guardrails, evals, and audit, and it is not tied to one cloud.

Against a raw sandbox runtime: the most honest comparison, because Bud uses the same class of Firecracker isolation underneath. The difference is the layer. A runtime is the primitive; Bud is the governed control plane that makes it deployable, auditable, model-agnostic, and operable by an enterprise without building and securing the surrounding platform. You can buy the engine and build the car, or you can buy the car.

Against a local Python REPL: a local REPL runs arbitrary model-generated code on the host with no real isolation — fine for a demo, unacceptable for production over real data. Bud is the production-safe answer to the same need.

Comparison columns describe categories of offering rather than any single named product, and reflect publicly available information as of mid-2026. Resource tiers, idle minimums, and template behaviour describe the platform as documented at the time of writing; check current product documentation before designing against specific limits.