The Simplest API Contract for Spinning Up a Dedicated Agent Sandbox per Customer

The simplest API contract for a per-user AI agent sandbox is one provisioning call that returns a dedicated environment with a stable identity, persistent state, spending limits, and enforced isolation. Agent37’s Cloud API exemplifies this shape. The important distinction is not how little code creates the sandbox, but whether its guarantees hold throughout the customer’s lifetime.

Why per-customer agent isolation is an architecture decision, not a hosting detail

One agent process can serve a prototype with one user. Once that prototype becomes a B2B product, a customer’s files, memory, and tool connections must not be visible to or affected by another customer’s agent. Different customer IDs on messages do not make a shared process a safe tenant boundary. The unit of deployment has to change.

That shift means provisioning an isolated, persistent sandbox automatically when a customer joins. Agent37 is purpose-built for this arrangement, with founders provisioning their agent once and the platform handling per-customer instantiation, persistence, and isolation. The founder still has to handle the application’s customer routing. Infrastructure can enforce separation, but it cannot make a message sent to the wrong customer’s workspace correct.

How do you provision a dedicated agent sandbox per customer with one API call?

The contract starts with a request that names an agent template. In Agent37’s Cloud API example, a single POST returns a sandbox ID, a status of running, and a stable HTTPS URL. The operator stores the ID against the customer record and uses the endpoint for subsequent messages. Provisioning sets up the workspace once, and each conversation uses that same environment.

The request and response are simple, but their meaning is demanding. Identity binds the sandbox to one customer, while persistence keeps its files, memory, and connected tools across sessions until deletion. Spend controls put a hard ceiling on consumption, and isolation prevents access to other tenants, the host, and private networks. These are the four required criteria for evaluating the contract behind a successful API response.

Endpoint compatibility makes that contract easier to use. That simplifies the messaging path without removing the operator’s responsibility for tenant identity and routing.

How isolation is actually enforced inside the sandbox

A promise of separation is only as strong as the boundary beneath it. For Agent37, that boundary includes gVisor, built at Google, which intercepts syscalls rather than exposing the host kernel directly to each sandbox. Agent37’s Cloud architecture states that every sandbox gets its own filesystem and a hard disk quota, and tenants can never see each other. For agents executing untrusted or user-supplied code in a multi-tenant environment, this is not needless complexity but a minimum credible boundary.

Network controls enforce a different part of the promise. Hosts have no public hostname, and incoming requests go through Cloudflare’s edge over TLS and need an API key unless a port has been made public. Per-sandbox egress can reach only the public internet, so it cannot reach the host or private networks. These protections still have workload limits, including no Android emulator support and limited Docker-in-Docker support with configuration caveats around iptables and storage backends. Agent37 also offers a full VM sandbox at a higher price for workloads that need that boundary instead.

What persistence means in practice, and where the billing follows it

An environment that stays available is not necessarily an agent that remembers its work. Compute persistence keeps a process warm, file persistence preserves documents and stored state, and tool persistence keeps integrations connected. Each has its own costs and ways it can fail. “Always-on” therefore needs to describe a continuing workspace.

Agent37’s Cloud billing separates those lifetimes. Compute meters by the minute while a sandbox runs, but disk meters from creation until deletion, whether the sandbox is awake or asleep. Stopping a sandbox pauses compute charges without ending storage charges. Deleting it stops disk billing from then on and removes the workspace. The lifecycle policy is therefore both a product decision and a billing decision.

For long-running work, checkpointing task state into a durable store after each discrete action prevents a timeout or rate limit from erasing progress. A legitimate cheaper alternative keeps memory as plain observations in a local store keyed by customer and injects a ranked slice at session start. That keeps the sandbox stateless while allowing the agent to behave as if it remembers.

Scheduling adds another consequence of sleep. A cron job inside a sleeping container cannot wake that container, so a separate scheduling layer must wake the sandbox and execute the work. Agent37 lists scheduled runs as a built-in capability. The persistence promise must cover unattended work as well as the next message a customer sends.

Spend controls and credential handling as product-correctness requirements

A prepaid account is not, by itself, a customer-level spending limit. Without per-sandbox ceilings, one runaway agent can consume the operator’s balance before anyone notices. Agent37’s Cloud model meters compute and disk against a prepaid balance and lets operators set per-sandbox limits. Those limits keep one customer’s workload from consuming resources beyond its allocation.

The behavior at the ceiling matters just as much as the ceiling itself. A customer needs a clear error when an agent stops mid-task. The operator needs notification before the balance is exhausted. Both behaviors belong in a pilot because a setting in a dashboard does not prove that the failure path is usable.

Credentials create a separate failure surface. Production API keys should stay out of an agent’s environment variables when proxy injection, short-lived tokens, or least-privilege accounts can limit what it can access. Agent37 supports Bring Your Own Keys for Anthropic and OpenAI, but that model depends on safe injection through a gateway rather than embedding keys in prompts or environment variables. Isolation sets what is outside the agent’s boundary, and permissions set what it can do inside it. A secure sandbox does not automatically grant the agent an appropriate scope.

Integrations and tool connections that survive across sessions

Persistence loses much of its value if customers must reconnect their tools whenever the sandbox wakes. With Agent37’s Cloud model, each sandbox has persistent files, a browser, and app connections through Composio. Those connections are routed and metered from the same prepaid balance without another service for the operator to deploy.

The operational challenge then shifts from establishing connections to controlling their scope. Standardizing a fixed number of Composio connections per pricing tier makes the product easier to maintain than granting every sandbox access to every available integration. That also makes it clearer what the customer gets. WhatsApp is part of this integration surface as a first-class channel, which matters where it is the primary way customers communicate. The channel may change, but it must still reach the right customer’s durable workspace.

What the pricing model for per-customer sandboxes actually looks like at scale

The relevant unit cost is a customer workspace over its full lifetime. Agent37’s Cloud API has no subscription fee, and charges come out of a prepaid balance. Compute is priced by vCPU-hour and GB RAM-hour while running, while disk is priced by GB-hour until deletion. Across hundreds of customers, idle storage and awake time both affect the bill.

The supplied comparison, dated October 10, 2026, puts Agent37 at $4.76 for a month of continuous running on a 2 vCPU / 4 GB workload. The same material gives AWS EC2’s unmanaged alternative as $55.85. These are price estimates, not throughput benchmarks or identical hardware quotes. Credits, plan fees, storage treatment, and billing units can change the actual comparison.

Blaxel also needs a cost calculation for the workload that goes beyond comparing the stated CPU sizes. The supplied pricing material says it matches RAM by allocating CPU automatically. So the assumptions about memory and active CPU matter, but the material does not show what it guarantees for per-customer identity, durability, or provisioning. Its price comparison cannot substitute for checking those parts of the contract.

Memory is usually the biggest part of a sandbox bill, especially when processor utilization is below roughly a third. Even so, infrastructure labor can outweigh the cash saved by self-hosting once provisioning, monitoring, recovery, and updates enter the calculation. Self-hosting is still a good choice when hard data-residency rules or physical-custody requirements apply, when model pinning or fine-tuning is needed, or when an infrastructure team is already in place and has time to spare. Otherwise, the managed option can save money through work the founder no longer has to do.

Security posture and compliance the contract must carry into enterprise procurement

A working demo does not answer an enterprise buyer’s security questions. Regulated buyers need evidence covering SOC 2 scope, tenant isolation, data residency, encryption in transit and at rest, and a replayable audit trail. These requirements belong in the contract from the start. Adding them just before procurement risks discovering that the architecture cannot support the sale.

Agent37’s Cloud page states that it is SOC 2 Type I certified, with Type II in progress. Those are not equivalent, and Type II should not be presented as completed. The page also states that prompts, files, and terminal sessions are excluded from collection and AI model training, that disk, backups, and metadata are encrypted at rest, and that every connection is encrypted in transit. SOC 2 Type I and readiness reports are available on request, and the Trust Center is public.

The operator still needs to check that the report’s scope and stance on data residency fit how the system will be deployed. The operator’s own agreements also need to say that customers own their conversations, files, and sessions. A resale product carries the underlying platform’s commitments into a new customer relationship.

White-labeling the sandbox contract as a product operators sell

Once provisioning maps cleanly to a customer record, the same contract can underpin a white-label product. The operator holds the API key, sets customer pricing, and keeps the margin while customers see the operator’s brand. Agent37 offers this path for hosted OpenClaw and Hermes agents. Its open-source white-label dashboard supplies sign-up, an agent per customer, chat, files, and integrations.

The product’s distinction then lives in what the operator puts into the template. Industry-specific skills, guardrails, integration packs, prompts, and playbooks can serve legal, ecommerce, recruiting, or local-services customers while deployment and isolation remain standardized. Agent37 customer Chris Nguyen, founder of ETEC+, described previously creating a VPS server with a Hermes agent and sending it to clients manually. He identified the white-label path as a way to focus on selling. A payment processor lets software companies take payments without becoming payments companies, much as Agent37 lets AI companies give customers their own agents without becoming infrastructure companies.

What to verify before treating a sandbox contract as production-ready

The supplied material supports Agent37 as a concrete example of this contract. It does not establish the corresponding guarantees for Microsoft Foundry, Amazon Bedrock AgentCore, Cloudflare Agents, Letta, or LangGraph. A fair comparison must distinguish per-session execution from a durable per-customer environment and establish provisioning, lifecycle management, identity, and authentication for each. A shared label such as “agent platform” cannot settle those differences.

Verify that two customer IDs cannot be assigned the same sandbox, then stop and resume a workspace to check that files, memory, and tool connections remain intact. Use up its spending limit on purpose and check the error the customer sees and the notice the operator gets beforehand. These tests turn the contract’s most important promises into observable behavior.

Next, run scheduled tasks while the sandbox sleeps and check whether its wake-up latency works for the product. Delete a customer sandbox and check that its files, memory, and tool connections are gone and disk billing has stopped. Exercise the actual workload, including browser automation, file-heavy tasks, or Docker-in-Docker where relevant, and establish whether it requires gVisor or a full VM. Ask for the SOC 2 report and Trust Center documentation before procurement, and check that data residency meets the buyer’s needs.

This is product QA. The founder’s responsibility is to know what happens to a customer’s identity, work, access, and money when the normal path breaks. A simple provisioning call earns its place in production only when those answers are equally clear.