AGNT5 supports tiered execution sandboxes — process, container, microVM — with different cost, latency, and isolation tradeoffs. The runtime contract (durability, replay, journaling) is identical across tiers; what changes is the boundary between your worker code and other workers’ code.

Tier	Boundary	Cold start	Cost	Use when
Process	Linux user / namespace	ms	lowest	Trusted code only; same tenant
Container	OCI container per worker	hundreds of ms	medium	Default for managed deployments
MicroVM	Firecracker / similar per run	seconds	highest	Untrusted code, agent-generated code, multi-tenant code execution

Pick the weakest tier that meets your security needs. The runtime guarantee does not change; only the blast radius of a compromise does.

The mental model

A sandbox tier is the wall around your worker process. At the process tier, the wall is OS-level isolation — separate user, separate namespace, but everything still runs on a shared kernel. At the container tier, the wall is an OCI container — separate filesystem, separate process namespace, still a shared kernel but with cgroup-enforced resource limits. At the microVM tier, the wall is a hypervisor — separate kernel, separate memory space, separate device access.

Stronger walls cost more — cold start grows from milliseconds (process) to hundreds of milliseconds (container) to seconds (microVM). They also constrain integrations differently. A process-tier worker can share a filesystem mount with another worker; a microVM cannot. A container-tier worker can use host networking; a microVM has its own virtual NIC.

Tier selection is per-deployment, not per-step. Every step inside a deployment runs in the deployment’s tier. A workflow that calls a @function with sensitive logic and a @function that runs an untrusted agent must put both inside the same tier — typically the stronger of the two, since the runtime cannot mix tiers within a single deployment.

Why it works this way

Per-deployment tier selection keeps the routing model compact — the routing key (tenant_id, deployment_id, component_id) already names the deployment, and the deployment’s tier is part of its manifest. Per-step tier selection would mean every dispatch decision involves a tier lookup, every worker manages multiple sandboxes, and the runtime carries a much larger configuration surface.

The tiered model gives you a way to opt into stronger isolation only where it matters. A trusted internal workflow runs at process tier with millisecond cold starts. A user-facing service that runs agent-generated code runs at microVM tier and pays the cold-start cost in exchange for hard isolation. Both share the same SDK, same control plane, same observability.

Edge cases and gotchas

• Tier selection is per-deployment, not per-step. If one step inside a deployment needs microVM isolation, the entire deployment runs in microVM. Split deployments along tier boundaries when you want different isolation for different workloads.
• Cold-start cost is paid on first dispatch to a fresh sandbox. Process tier amortizes near-zero. Container tier pays hundreds of milliseconds when scaling up; warm pools mitigate this. MicroVM tier pays seconds; pre-warming is essential for latency-sensitive paths.
• Some integrations only work in lower tiers. Shared filesystem mounts (the host-mounted path), host networking, and access to specific host devices are typically process or container only. MicroVM workers have their own virtualized stack.
• The runtime contract is identical across tiers. Durability, replay, journaling, retries — none of these change with tier. A workflow’s correctness does not depend on its sandbox; only its blast radius does.
• Agent-generated code runs at the deployment’s tier. When an agent generates and executes code (for example, a Python REPL tool), that code inherits the surrounding sandbox. If you allow agent-generated code, default to microVM unless you have a specific reason not to.
• Multi-tenant code execution belongs at microVM tier. Process and container tiers share a kernel; a kernel exploit reaches every workload on the host. MicroVM is the level that gives you per-run kernel isolation.
• Tier upgrades require redeployment. You cannot promote a running deployment from container to microVM; create a new deployment with the stronger tier and shift traffic.

Related concepts

• Versioning and deployment model — tier is part of the deployment manifest.
• What the runtime owns vs. your code — the runtime provides the sandbox; your code runs inside it.
• Architecture overview — workers are the things being sandboxed.