Why One-Call Sandbox Provisioning Is the Right Primitive for Customer-Scoped Agent Memory

A per-user AI agent sandbox provisioned via a single API call is the right starting point for customer-scoped memory. That call must establish one customer’s execution boundary, persistent workspace, credential policy, and session scope together. The environment should pause without losing files and resume for later sessions, so onboarding can run on its own without relying on scattered application settings for isolation.

What agents actually need from a sandbox: execution, memory, credentials, and tool access as one problem

The category error is treating sandboxes as compute units and bolting on customer namespacing afterward. An agent serving a customer needs more than a safe place to run code. It needs a durable place for that relationship. Its files, git state, prior conversations, learned preferences, and authority to use tools all belong to the same customer. Isolation therefore shapes the architecture from the start.

Those responsibilities depend on each other. An execution boundary keeps untrusted or model-generated code away from the host and neighboring tenants, but it cannot compensate for a memory file left in a shared directory. Likewise, a private workspace does not protect a customer if another agent can use that customer’s OAuth connection. A failure in either layer defeats the separation promised by the other.

The OpenAI Agents SDK distinguishes conversational Session memory, which stores message history, from distilled Memory artifacts stored under memories/ in the sandbox workspace. History records the conversation, while distilled memory lets future runs reuse lessons from it. The useful unit is consequently a scoped environment provisioned once per customer and reused across tasks throughout the relationship.

Why namespacing inside a shared runtime is not isolation

A customer prefix changes a name while leaving the boundary unchanged. On a shared filesystem, paths such as per-user memory directories still rely on application code to choose the right place. A misconfigured path or a subagent writing to the wrong relative directory can contaminate another customer’s context. The naming scheme describes ownership but does not enforce it.

The same gap appears in tool access. A Composio-managed OAuth connection attached to a shared agent runtime belongs to whichever session the application wires it into. Sharing the runtime does not automatically bind that connection to the initiating customer.

Hermes Agent writes skill documents from what it learns and makes them better across sessions. If those documents accumulate in a shared backend that other customers’ agents can read, the shared store defeats customer-scoped learning. The skill’s filename does not change who can reach it.

MicroVM isolation may be more than some tasks need. That objection covers only the code execution part of the customer relationship. Even an agent that writes no code still needs context that lasts and limits on which tools it can use. The boundary must enforce those requirements regardless of how dangerous the task looks.

How do you provision an isolated agent environment for each customer with one API call?

One-call provisioning makes the customer boundary a single decision. The call returns an environment with execution scope, workspace, session ownership, and credential policy all tied to the same customer. That is more than a convenience wrapper around setup tasks. It makes the platform keep those links in place, so application code no longer has to keep four separate configurations in sync.

Cloudflare’s Dynamic Worker Loader demonstrates this principle at the execution layer. It creates a Worker in its own isolate sandbox from code supplied at runtime, without a pre-warmed pool or cross-request state leakage. One call creates one isolated execution context. That shows how provisioning can work, though execution isolation alone does not give a customer a workspace that lasts.

The SDK illustrates the memory side through client.create() with a manifest and a LocalSnapshotSpec. The resulting sandbox owns its memories/ and sessions/ directories. Capabilities such as Memory() are configured on SandboxAgent separately from the creation call. The distinction is important because one-call provisioning does not mean every policy literally becomes a parameter on one function.

When the environment is created, the policies already in place must be bound to it. The harness may run inside or outside the sandbox, but the durable workspace remains inside its boundary. Credential injection must follow that same scope rather than depend on a fresh choice at every agent-loop startup. The call is the point where those parts become one customer’s environment.

Why persistent-but-pausable is the right persistence model for customer-scoped memory

Ephemeral sessions discard the continuity that customer memory needs. An agent cannot build on preferences, completed tasks, and corrections if its workspace disappears after each request. The SDK’s memory documentation identifies three benefits of retaining lessons across runs, including less agent exploration, fewer user corrections, and shorter task descriptions. All depend on those lessons reaching the next run.

Always-on compute solves retention at the wrong cost. A customer relationship can last far longer than any individual task, with long gaps between sessions. Keeping allocated resources continuously billed during those gaps ties the cost of memory to elapsed time, including time spent waiting. An agent waiting on a model exposes the same mismatch within a session.

Upstash Box supports the pattern of pausing when idle and waking weeks later with files intact. Active-CPU billing avoids charging for waits by charging for consumed CPU time. These are separate features, and a platform needs to keep state at a cost that works for both short waits and long absences.

The SDK makes the dependency on workspace continuity concrete. Conversation files accumulate during a live session and are processed at session close into MEMORY.md and memory_summary.md. Later runs can reuse those artifacts only if the memory directory is still there. Its multi-agent layout also separates memories_dir and sessions_dir by agent type, with separate SQLiteSession identifiers. Those internal divisions organize agents within a customer’s workspace. They do not replace a customer-specific root.

How the credential and tool-connection layer must follow the sandbox boundary

An agent might remember the right Slack channel for a customer yet send messages through a connection shared beyond that customer’s scope. Its knowledge is private, but its ability to act is not. Credential policy must therefore follow the same boundary as the workspace.

Composio handles OAuth flows, token refresh, and credential lifecycle, with permissions scoped per connection. Its model supports authentication when a user’s agent needs a tool rather than requiring globally configured access beforehand. This does not mean every token must exist at sandbox creation. The provisioning step must establish the customer scope into which later authenticated connections belong, so agent-loop code does not choose that ownership afresh.

The connection surface can be broad. Composio exposes tools including Gmail, Slack, WhatsApp, and GitHub through a single MCP endpoint. A common endpoint simplifies access, but it does not erase the need for per-connection permissions, least-privilege access, and audit trails. As integrations grow, the customer-to-connection association becomes more consequential.

Credential containment also need not mean storing secrets in the workspace. A local TLS-terminating credential proxy, combined with egress controls, can inject secrets at the boundary while keeping them off the agent’s reachable filesystem. Customer-scoped connection policy determines whose authority is available, while the proxy controls how the sandbox uses it without exposing the secret itself.

What breaks when teams defer this architecture and try to retrofit isolation later

Retrofitting isolation changes several systems at once. A shared backend has already made assumptions about workspace roots, credential ownership, and session history. Those assumptions stay in place when execution moves into separate environments. Memory, connections, and history must move together into scopes that belong to the same customer.

Distilled artifacts such as MEMORY.md, rollout summaries, and skill documents refer to a workspace layout. Moving them to customer-specific roots means their memory references must change too, and any run still active during the migration can write to the old or wrong place. The transition itself becomes an isolation problem.

Credentials bring a different kind of disruption. Where OAuth connections were established under a shared application identity, moving to customer-specific identities can require reauthorization and customer action. Session history is also difficult to separate after use. The SDK accumulates conversation files and processes them at session close, without a supported path for retroactively assigning that history to a different sandbox boundary.

When skill documents draw on interactions with several customers, splitting up the files does not show which lessons came from which tenant. That makes the retrofit more than an engineering-hours estimate. A product promising private customer context must also account for reduced isolation during the transition, with consequences for trust and compliance. Starting with customer-scoped provisioning avoids that transition cost.

How one-call provisioning connects to onboarding automation and why automability is the other half of the primitive

Correct isolation is only half the product requirement. If each environment must be set up by hand, the architecture works for a demo but becomes hard to run as customers arrive. The provisioning boundary must therefore be available through an API that onboarding can invoke.

The sequence is straightforward. A signup webhook calls create(), receives a sandbox ID, and stores that ID against the customer record. Subsequent invocations route to the same environment. Before the first session begins, the workspace must exist with clean memory and the customer’s credential scope already established. A background job that runs afterward is too late to define the first session’s boundary.

The product still needs the signup trigger and customer-to-sandbox association, but the operator does not need to configure a VPS, Docker, or SSH keys for each customer. A white-label agency illustrates the distinction. Each client can have a workspace connected to Gmail and Slack, with an approval queue for account-manager review, without the founder manually assembling every environment.

The Worker Loader also shows that rapid automated creation is achievable at the platform layer. Cloudflare specifies no limits on global concurrent Dynamic Worker sandboxes or their creation rate. That evidence applies specifically to isolate provisioning. Every implementation must let one new customer trigger one correctly scoped environment without anyone setting up infrastructure by hand.

Choosing the right sandbox technology for persistent per-customer agents: isolation model, billing model, and agent tooling

The decision rests on three linked criteria. The execution boundary must contain the intended workload, the billing model must tolerate idle customer environments, and the tooling must support durable agent state. Strength in one area does not compensate for a gap elsewhere. Fast creation is not enough if every return visit starts with an empty workspace.

For lightweight execution, Dynamic Workers offer V8 isolates with sub-millisecond startup, primarily for JavaScript and TypeScript, with Python and WebAssembly also supported. They work well for stateless or short-lived agent code when the application enforces the customer boundary. OCI containers are fast and widely supported but share the host kernel, making them a better fit for internal tooling or same-trust tenants than fully containing untrusted customer or model-generated code. WebAssembly offers low-overhead runtime isolation but a limited system-call surface, which fits plugin-style tools rather than a full persistent workspace with git state.

Vercel Sandbox is a stronger match when microVM isolation and active-CPU billing are priorities. It uses Firecracker microVMs, and time waiting for network or model calls does not count toward active CPU. Its AI SDK HarnessAgent supports coding harnesses such as Claude Code, Codex, and OpenCode inside the microVM. That supplies execution and harness support, but it is not the same as a complete customer-memory lifecycle.

Daytona has fast starts, SDK support for many languages, and per-second usage-based billing, with a minimum charge for guaranteed reserved resources. That makes it better suited to development environments and CI than long-lived, mostly idle customer agents. The SDK is the more direct fit when agent logic is already SDK-native and the team controls compute, because it supplies memory layout, session scoping, and snapshot resumption across compatible backends.

The recommendation therefore depends on the missing layer. Vercel helps keep execution contained and charges for active-CPU use, the SDK handles agent memory and how sessions are organized, and Upstash Box shows how an environment can pause and resume with its files still there. None of those properties should be inferred from “one API call” alone. The right provisioning primitive binds the chosen layers into a durable customer scope before the first session starts.