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.
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.
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."