---
id: "concept-layer-1-compute"
type: "concept"
source_timestamps: ["00:03:00", "00:05:29"]
tags: ["compute", "security", "sandboxing"]
related: ["concept-the-agent-stack", "entity-e2b", "entity-daytona"]
definition: "The foundational infrastructure layer providing safe, isolated, and auditable environments for agents to execute code."
sources: ["s52-orchestration-layer"]
sourceVaultSlug: "s52-orchestration-layer"
originDay: 52
---
# Layer 1: Compute & Sandboxing

## Definition
The foundational infrastructure layer providing safe, isolated, and auditable environments for agents to execute code.

## What this layer must provide
Agents cannot run on a user's local laptop, in unsupervised production environments, or without auditability. They need isolated execution surfaces with clean teardown semantics. This is currently the **most mature** layer in [[concept-the-agent-stack]] and bears the actual production load for agents today.

## The architectural fork: ephemeral vs. persistent
A key philosophical split exists within this layer:

- **Ephemeral sandboxes** (championed by [[entity-e2b]]) treat the execution environment as disposable — spin up for a single task, run the code, immediately tear down. E2B is built on Firecracker microVMs and has raised approximately $32M.
- **Persistent sandboxes** (built by [[entity-daytona]]) assume a long-lived environment where agents can install dependencies, create files, and return to the same state later — implying a degree of agentic persistence. Daytona raised a $24M Series A.

## Adjacent specialists
- **Modal** for GPU-heavy workloads.
- **Browserbase** for headless browser automation.

## Strategic implication
The choice between ephemeral and persistent is **not a style preference** but a core architectural bet on how long agent sessions will run and whether state matters for that workload. Long-running research agents likely want persistence; quick task workers likely want ephemeral.

See [[concept-the-agent-stack]] for the broader taxonomy.