A Cloud Sandbox Can Finish the Job. Who Owns the Next One?

The Laptop Can Close. The Business Still Has to Open Tomorrow.

On September 24, Docker introduced Cloud Sandboxes: isolated environments for long-running AI work that can move from a developer's laptop to cloud compute. A task can continue after the laptop closes. Each sandbox gets a microVM, and Docker says its tools, secrets, and network policies can be configured for the job. In its same-day press release, Docker described Kits packaged as OCI images, with access rules carried as part of the package.

That's a meaningful infrastructure development. It addresses a real production problem: running a capable system for hours on someone's personal machine is neither a dependable availability plan nor a good isolation boundary. Docker is building for workloads such as coding tasks, migrations, and long-running tests. For those jobs, a portable, constrained place to execute is valuable.

But an isolated place to finish this job is not the same thing as an AI coworker responsible for the next job. If you're deciding how to put AI to work across your business, confusing those two layers will leave the owner playing dispatcher after every successful run.

The distinction is not sandbox versus no sandbox. You may need both a persistent Teammate and isolated execution for a risky task. The question is what remains when the task is done: who owns the ongoing responsibility, the context, the escalation rule, and the record of why yesterday's decision was made?

What a Sandbox Actually Buys You

Think of an AI sandbox as a bounded workroom. You provide a task and a set of materials. Work happens inside an environment with limits on what it can reach. You review the result, take the output you want, and shut the workroom down or pause it.

Docker's announcement makes several important promises for this workroom: a microVM rather than unrestricted execution on the host; a move from local to cloud execution; controlled access to connected services through a gateway; and secrets that, according to Docker, are injected through a proxy rather than handed directly to the running AI. Its product blog also says a move captures the sandbox filesystem and recreates it on the other side. That's continuity for an active job, not necessarily a standing organizational memory system.

The limits matter too. Docker says cloud sandbox sessions run for one hour by default and up to 24 hours per session. The product is positioned around finishing bounded work, including tasks that outlive the developer's attention. It does not claim to supply your company's role definitions, shared approval decisions, customer commitments, or ongoing business priorities. That's not a criticism; it's the difference between an execution environment and an operating model.

For a software team, the distinction is familiar. A build runner can test a pull request. It cannot decide which customer promise should take priority next Tuesday. A temporary sandbox can execute a migration. It cannot, by itself, own the migration calendar, recognize an exception in a customer's account, or know which human must sign off before records change.

A sandbox is a strong answer to where and within what boundaries work runs. A persistent AI coworker requires answers to whose work it is, what it remembers, when it pauses, and who can change its mandate.

Two Kinds of State That Should Not Be Confused

Docker's portable Kits are an instructive design choice. Packaging the environment, its connected tools, and access rules as a repeatable artifact can keep execution consistent across locations. That is execution state: enough to reproduce how a class of work runs and what it may touch.

A business role also needs operational state: the current account owner, commitments made last week, pending approvals, exceptions to the standard procedure, and the reason an issue was escalated. Some of that may live in a CRM or ticketing system; some in governed memory; some in an audit trail. It should not depend on whether the last sandbox is still running.

Imagine a licensing-compliance business. On Monday, an AI coworker checks a license application, notices a missing attachment, drafts a request to the client, and records that the deadline is Thursday. A sandbox may be the right place to parse an untrusted file or validate the attachment against a checklist. On Tuesday, a new upload arrives. The business needs the same role to see the Monday exception, confirm the attachment answers the original request, and update the case without inventing a new interpretation of the deadline.

If all meaningful state is trapped in yesterday's task environment, Tuesday begins with reconstructing Monday. If the role's state lives in governed systems, the execution environment can be replaced without losing the business thread. That's the division to design for: disposable or movable compute for particular jobs; durable, inspectable responsibility for the role that directs them.

This is also why "it has a filesystem" is not a complete memory strategy. A filesystem can hold files. It doesn't tell you which facts are authoritative, who may edit them, whether a source has expired, or how one Teammate's view of a customer differs from another's. Agentic memory needs governance, not just storage.

The Handoff Is Where Most Deployments Break

A long-running task has a beginning and an end. A business role has a shift schedule, inputs from other people, obligations that survive a shift, and exceptions that may span weeks. The real seam between those shapes is the handoff.

Consider a small business's month-end bookkeeping workflow. An isolated run reads invoices, reconciles entries, and drafts a report. That is a good candidate for bounded execution. But suppose the run finds a charge that looks duplicated. The system must not quietly pick one entry and mark the books complete simply to satisfy a completion metric.

Bad design: One broad account lets the task read, write, and approve the same ledger. The instruction says to "ask before material changes," but nothing prevents a write. When the session ends, the unresolved discrepancy is buried in a transcript nobody owns. Next month, a fresh task starts from a prompt and makes the same guess.

Good design: The finance Teammate has a defined mandate and access limited to reading transactions and preparing proposed adjustments. The ambiguous charge becomes a tracked exception linked to the source records, with a named human reviewer and a due date. A separate approval boundary controls the final ledger change. The Teammate can resume once the reviewer decides, and the decision remains available for the next cycle. The sandbox used for processing can disappear without taking the exception with it.

Notice what each layer contributes. Isolation reduces the blast radius of executing work with documents or connected tools. The operating layer makes the work legible, recoverable, and accountable across runs. Neither substitutes for the other.

Docker's own emphasis on policy traveling with a Kit underscores that distinction. Moving an environment without its restrictions would weaken it. Moving a task without its business context would weaken its usefulness. Portability is not one thing: the environment, permission boundary, and organizational record each need a deliberate home.

A Practical Architecture for a Small Team

You do not need to build a sprawling enterprise control plane to make this work. Start with one recurring function and separate five responsibilities.

1. Define the role outside the task. Write down what the AI coworker is responsible for, what success means, which systems it reads, and which actions it can propose or execute. A sales follow-up role might own lead triage and draft responses but not approve discounts. Keep its mandate versioned and reviewed. This is intent engineering: turning an organizational objective into usable decision boundaries, rather than merely telling the model to "be careful."

2. Choose the right execution boundary for each step. Parsing an attachment, running a code migration, or testing a spreadsheet formula may belong in an isolated environment. Routine event monitoring and waiting for a customer reply require a role that can persist across task runs. Don't keep a risky work environment alive solely because it accidentally holds the only copy of the context.

3. Separate identity, credentials, and approval. The role should have its own identity, limited access, and explicit approval seams for irreversible actions. A valid login is not proof that a particular action is authorized. The same principle applies whether execution happens in a sandbox, an agent server, or a connected business app.

4. Put durable state in named systems. The CRM owns account facts; the ticketing system owns support status; a governed memory surface holds reusable context with source and retention rules. Link task output to those records. Record a human decision as a decision, not as a vague chat recap. Decide what must survive a restart and test that it actually does.

5. Make the handoff observable. Each task should produce an outcome, a reference to source material, a list of exceptions, and the next owner. If a customer file fails validation, route it to a person with a concise explanation. If it passes, the role can move to the next safe step. Store the event trail somewhere the executing task cannot rewrite. This is the seam that lets a business delegate without disappearing from oversight.

6. Rehearse replacement. End one execution environment mid-work and verify recovery. Change a model provider on a test workflow and verify the role's mandate, records, and approvals remain intelligible. If the team must reconstruct everything from one vendor's transcript, it doesn't yet own a durable AI coworker. Model-agnostic design is useful only when the context and control plane can travel too.

These aren't six products to buy. They're six questions to answer before you let a result from one run become the premise of the next.

Where Docker Fits—and Where It Doesn't Have To

Cloud Sandboxes are designed for builders who need isolated, portable execution. For a team with engineers running parallel coding jobs, Docker's launch is directly relevant. Its approach to moving a work environment between laptop and cloud, and to packaging rules with the environment, is a concrete example of structural rather than instruction-only control.

For an operations lead, the useful lesson is broader than this product. You should ask any vendor how it isolates the work, where credentials are exposed, what happens when a task is interrupted, and whether the same permissions apply after a move. Then ask a second set of questions: what persists between tasks, who owns the outstanding exception, and can a human revise the AI coworker's mandate without rewriting yesterday's evidence?

A sandbox vendor might answer the first set well and leave the second to your business platform. A business platform might maintain role and memory well while using external sandboxes for risky work. That's a sensible composition, not a deficiency. The mistake is buying one layer and assuming it silently provides the other.

This is what seam design looks like in practice. Give the AI coworker authority inside a clear lane, a contained place to execute the steps that need it, and an explicit transition to a human where judgment or consequence demands one. As capabilities improve, you can move the seam. You should not have to give the system blanket authority or rebuild the role to do it.

FAQ

Is an AI sandbox the same as an AI coworker?

No. A sandbox is a constrained execution environment for work. An AI coworker is an ongoing role with a mandate, connections, durable context, and handoffs. A coworker may use a sandbox for a particular task; the task environment should not be the sole owner of the role.

Does moving a sandbox to the cloud make it persistent?

It can keep the current work going after a laptop closes. Docker says its move operation carries a sandbox filesystem, and its Cloud Sandboxes support sessions up to 24 hours. That does not automatically create a continuing business role with governed memory and accountability across future tasks.

Should every AI task run in a separate sandbox?

Not necessarily. Match isolation to the risk of the inputs and actions. Untrusted files, code execution, and experimental integrations often justify stronger containment. A recurring role still needs appropriate access controls and human checkpoints even if it uses a sandbox for only some steps.

Can a persistent AI coworker be model-agnostic?

Yes, if its role definition, records, connections, and permissions are not inseparable from one model provider's session. Portability must be tested at the workflow level; switching a model name alone is not proof that the business context survives.

What should I test before trusting a recurring workflow?

Interrupt one task; inspect the exception it leaves; verify a human can decide; then resume on a new run without losing the source, decision, or action boundary. If that fails, fix the handoff before extending the run time.

The Workroom Is Not the Org Chart

Docker's September launch is a reminder that AI work needs somewhere safe and reliable to happen. The next design question is what survives when that workroom closes. An isolated task can deliver a file. An AI coworker can own a continuing responsibility—provided its memory, authority, and handoffs live in a durable operating layer, not only inside the task.

Associates AI Teammates gives businesses a model-agnostic platform for running persistent AI coworkers on agent servers, with Skills, connected workflows, and clear human decision boundaries. If you're ready to build a team that can pick up tomorrow's work without losing today's context, explore Teammates and choose a plan.