The agent runtime is becoming the product

Docker’s new sandboxes are a reminder that serious AI agents need controlled places to act, fail, and disappear.

The thing Docker got right Docker put out Docker Sandboxes this week: disposable, isolated sandboxes for AI agents. That sounds like infrastructure plumbing because it is. Which is exactly why I paid attention. Most agent demos still obsess over the model. Better reasoning. Longer context. Faster tokens. Fine. But the part that keeps showing up in client work is not “can the model think?” It is “where does the model act?” If an agent can write files, run commands, inspect data, call internal APIs, or modify a CRM record, then the runtime is no longer a detail. It is the blast radius. The agent runtime is becoming the product surface. Not the chat box. Not the prompt. The box where the agent gets temporary tools, temporary data, temporary permissions, and then gets thrown away before it can accumulate weird state. The build that made this obvious A few weeks ago I worked on an internal ops agent for a services company. The job was boring on purpose. It watched failed customer onboarding cases, read three sources of truth, drafted the correction, and prepared the update for a human to approve. The first version was a classic workflow: Airtable trigger, Python worker, model call, Slack approval, then a write back into HubSpot and an internal Postgres table. It handled 312 cases in the first test week. Average review time dropped from about 11 minutes to under 4 minutes because the human reviewer was no longer hunting across tabs. Model spend was not the issue. The whole run was under $40. The issue was the middle step. To produce a good recommendation, the agent needed to run tiny bits of code against exported records. Normalize names. Diff address fields. Check payment status. Compare timestamps. In the naive setup, all of that happened in a long-lived worker with too much filesystem access and a few environment variables it did not need. Nothing catastrophic happened. That is not the point. The point is that I was relying on discipline instead of structure. The agent did not need a permanent home. It needed a hotel room with plastic sheets, no minibar, and a checkout time. Why isolation beats permission prompts I have become less interested in asking the model to behave and more interested in making bad behavior boring. “Do not delete files” is weaker than “there are no important files here.” “Do not call the internet” is weaker than “this sandbox has no egress except the one proxy we log.” An agent you trust is usually just an agent whose worst options were removed before it woke up. This is where disposable sandboxes matter. Every task gets a fresh execution environment. The agent receives the minimum input bundle, the specific tools for that task, and a narrow set of credentials if credentials are needed at all. When the task ends, the environment dies. The logs and artifacts survive. The filesystem does not. That changes the engineering conversation from trust to containment. You still need evals. You still need approval gates. But you stop pretending the prompt is a security boundary. The harness I want around every sandbox If I were rebuilding that onboarding agent this week, I would make the sandbox the default unit of work. One ticket, one sandbox. No shared working directory. No reused shell history. No mystery packages installed because a previous run needed them. The harness would look like this: Create a fresh sandbox from a pinned image, not whatever happens to be latest. Mount a read-only input bundle with the ticket, relevant customer records, and policy snippets. Inject short-lived credentials only when the task requires an external call. Run the agent with a hard timeout, token budget, memory cap, and network policy. Export only approved artifacts: proposed patch, reasoning summary, command log, and diff. Destroy the sandbox and keep the audit trail. For a real client build, I would keep the config boring enough that an ops lead can understand it without reading agent theory. Something like this belongs next to the workflow code, not buried in someone’s head: task: onboarding_case_repair image: ops-agent-runner:2026-08-locked timeout_seconds: 420 network: allow: - internal-records-api - approval-webhook filesystem: input: read_only workspace: disposable secrets: scope: case_level ttl_seconds: 600 artifacts: keep: - proposed_patch.json - decision_trace.md - command_log.txt human_approval_required: true This is not fancy. That is why I like it. The model can still be smart inside the box, but the system around it is legible. When something goes wrong, I can answer three questions fast: what did it see, what could it touch, and what did it produce? The part that still breaks Disposable does not mean safe by default. You can still leak data through logs. You can still give the sandbox a secret that is too broad. You can still let it call an internal API that performs writes without a second check. Isolation reduces the mess, but it does not absolve the workflow designer. The annoying edge is artifact review. Agents generate a lot of junk while working: temp files, scratch notes, partial scripts, failed command output. If you keep everything, your audit trail becomes unreadable. If you keep too little, debugging turns into archaeology. On that onboarding build, the useful artifacts were surprisingly small: final diff, source record IDs, validation checks, and the exact commands that changed the recommendation. Everything else was noise after 48 hours. Cost is also not zero. Spinning environments per task adds overhead. For low-value tasks, a sandbox can cost more in latency and orchestration than the model call itself. My rule now: if the agent can only read and summarize, keep it simple. If it can execute code, transform private data, or prepare a write, put it in a disposable box. What I am changing next I am moving my agent builds toward a stricter split: planner outside, actor inside. The planner can decide what needs to happen and ask for approval. The actor gets a narrow job inside a sandbox and returns artifacts. No grand unified agent wandering around with every tool attached. The next real improvement in agent reliability will look like boring infrastructure. Pinned images. Short-lived credentials. Network rules. Artifact retention. Smoke tests. Human approval where the cost of being wrong is high. It will feel less like prompting and more like operating a small, weird, temporary employee who gets a clean desk every morning and loses badge access every evening. If I were starting again on the onboarding agent, I would build the sandbox harness first and the agent second. That would have slowed the prototype by a day. It would have saved me two days of tightening permissions after the workflow already worked. What agent workflow are you running today that would be safer if every task started in a fresh disposable box?

Harshith Vaddiparthy works with founders, operators, and teams on practical AI products, workflows, advisory, training, and mentorship. This no-JavaScript version preserves the page's core information and navigation.