Execution Environment
Where tool calls become bounded reality: sandboxes, containers, worktrees, filesystem scope, network and secrets. Trust made practical — the model doesn't avoid secrets, it never gets them. Compute is not the environment: identity lives in the environment, and the wall can be drawn around the input instead of the process.
The execution environment is where tool calls become bounded reality. Filesystem scope, network access, credentials, sandboxing, containers, browser sessions, cloud workspaces — this layer decides what an action can actually touch.
Trust becomes structural
This is the layer where trust gets practical. There's a profound difference between two sentences:
- "Please do not touch the secrets." — an instruction, hoping for compliance
- The process has no secrets in its environment. — an architecture, guaranteeing it
The first is the instructions primitive doing its best. The second is the execution environment making the failure impossible instead of discouraged. The model can ask to run a command; the harness decides where that command runs, what it can see, what it can change, and which actions need a human's approval first.
The vocabulary of this layer: sandbox, dev container, git worktree, browser profile, cloud workspaces. Entire companies exist here — E2B and Daytona sell sandboxed execution for agents, and Docker now ships a dev sandbox. When a coding agent runs each task in an isolated worktree, that isn't a deployment detail. It's a harness primitive.
Compute is not the environment
The vocabulary above collapses two things that a working factory keeps apart. Dex Horthy and Vaibhav Gupta, describing the stack under a software factory on AI That Works, draw them as separate layers: compute — where the process runs, EC2 or Kubernetes or a stack of MacBooks — and the dev environment on top of it: the toolchains to compile and test, a preview of what was built, the shared services a real application depends on, and identity.
That last item is the one that belongs on this sheet. Gupta's placement is deliberate: identity provisioning lives in the environment, not in the harness. The environment carries who the agent is, and who it is decides which API keys and which scopes it can reach. That is the "process has no secrets" architecture from above, generalised — the boundary is not drawn around each tool call but around the environment the whole run inhabits.
And the boundary need not be a container at all. Boundary's own factory runs on owned MacBooks with no sandbox, and the reason is a trust decision made one layer up: raw user feedback is never executed. The factory's agents write the reproductions, and only those run. The wall was moved from around the process to around the input — which is a legitimate place to put it, provided the sheet says out loud that it was moved.
One clean sandbox is not enough
The environment gives the agent a place to work. But real tasks have lifecycles that outlive any single session: they pause, they resume, they fork, they fail. They need a plan, a log of what was tried, continuity — so the next step starts where the last one ended instead of redoing everything from scratch.
If the only place all of that lives is inside the model's context window, then a crash — or just an ended session — loses it all. The system needs something more durable than "yeah, I think I remember that one."