Evaluating Infrastructure Platforms for Dedicated Per-User AI Agent Deployment

Per-user persistent AI agent deployment at scale requires dedicated isolation, durable state, fast snapshot restore, and storage-only idle billing, supported by per-agent identity and managed deployment tooling. Shared execution pools and stateless functions cannot supply that combination on their own.

Why per-user agent deployment is a fundamentally different infrastructure problem than shared agent services

A chatbot can operate behind a stateless inference endpoint because its immediate job is to produce an answer. A persistent agent must preserve an environment in which work continues across sessions. The deployment unit changes with that responsibility. It is no longer just a request handler, but an agent with durable state, installed tools, and unfinished tasks that must remain available when execution resumes.

Zhang et al. (2026) describe this transition as moving from “conversational answers to persistent work.” Their Workspace + Skill paradigm requires state persistence, reusable procedures, and task closure rather than repeated tool calls without a durable workspace. Meta’s Muse Code shows where deployment is heading, with persistent asynchronous background agents that stay active throughout a session. Persistence is already a deployment requirement.

A stateless function can handle inference, but it cannot itself preserve a browser session, a package installed mid-task, or a workflow paused between sessions. A shared container pool can run code, but kernel sharing does not give independent agents the isolation boundary they need to run untrusted workloads. The developer discovers the architectural mismatch only after building around it.

Isolation as a hard requirement, not a security nice-to-have

Kernel ownership distinguishes a container from a microVM. A Docker container shares the host kernel, while a Firecracker microVM runs its own dedicated Linux kernel through hardware virtualization using KVM. Multi-tenant agents that run untrusted or AI-generated code need the security boundary that comes with a dedicated kernel. Containers do not provide a separate kernel for each tenant.

Agent workloads put this boundary to use because they install packages, run generated programs, and use browser sessions. Isolation also defines what agents may do autonomously. An agent-owned environment can be changed, broken, and rebuilt without doing that work in an environment shared with other tenants. Zhang et al.’s persistent Workspace presupposes an execution substrate where the agent can retain and change its working environment. A deployment model that prohibits those changes restricts the agent’s function.

Deno Sandbox, announced February 3, 2026, in beta, uses dedicated Firecracker microVMs for untrusted or AI-generated code on Deno Deploy’s infrastructure. Docker Sandboxes reached GA in September 2026 with custom microVM isolation for AI coding agents. These choices signal convergence on the same architectural boundary. The evaluation criterion is the dedicated kernel. For a production multi-tenant fleet that executes untrusted code or holds user credentials, shared-kernel containers do not meet that requirement.

What persistent state actually means for an agent, and why it cannot live in a context window

Isolation gives an agent its own environment, but that environment must also survive interrupted execution. Ding et al. (2026) define always-on agents by the durable state they build up through earlier interactions. Their state taxonomy includes retrievable memories, task ledgers, permissions, credentials, commitments, provenance and audit records, shared state, trigger conditions, and externally committed side effects. Conversation history is only part of the system. Losing the other items can leave an agent unable to continue its work correctly even when it remembers the discussion.

These state categories impose different storage obligations. Memories must remain retrievable, while permissions and credentials must remain available within the agent’s security boundary. Task ledgers and commitments preserve unfinished obligations, and provenance and audit records preserve their history. A context window has a finite horizon and requires explicit save-and-restore to preserve these state categories across session boundaries.

In the execution environment, xAI’s Grok Bot architecture names files, browser sessions, and preferences as things that persist across sessions. Installed packages and credentials must likewise survive sleep and redeploy if the agent is to continue multi-session tasks. Remembering that a tool was installed is not equivalent to retaining the tool.

External databases can hold durable state, but relying on them to reconstruct the environment pushes serialization and bootstrap logic onto the developer. The infrastructure implication is a real persistent disk attached to the agent’s own VM, with its files and working environment present when the agent wakes.

Wake latency as a product requirement that sets the acceptable range for snapshot-restore infrastructure

Once an agent can retain its environment, it can sleep between periods of useful work. The next constraint is how quickly it returns. Users need the agent to be present when they resume an interaction. Sub-second or near-sub-second restore supports that continuity. A delay of seconds instead exposes the dormant infrastructure as a cold start.

Snapshot-restore connects this product requirement to the runtime mechanism. The platform boots and initializes a microVM, captures its state, and restores that initialized state when execution is needed. AWS AgentCore Runtime, shipped September 18, 2026, restores snapshots of already initialized agents, keeping cold starts around two seconds regardless of container size. Google Cloud Agent Compute Engine uses checkpoint-restore to save a microVM’s complete state when an agent becomes idle and free up CPU, memory, and I/O capacity for active agents. Both examples establish snapshot-restore as a production pattern, though adopting the pattern alone does not establish acceptable interactive latency.

Restore time is distinct from cold-boot time. Firecracker’s minimal design launches with its own kernel in under 125ms and less than 5MB of memory overhead, but those figures are not a substitute for a platform’s published snapshot-restore latency. A warm pool takes a different approach by keeping compute available for immediate assignment.

The evaluation should therefore look at the path users take when they return. Where snapshot restore is that path, its latency is the relevant measure, together with whether the platform manages snapshot scheduling. Fast cold boots cannot compensate for a missing suspend-and-resume lifecycle.

Why idle-cost efficiency is the economic criterion that determines whether per-user deployment scales

The ability to suspend an agent becomes economically useful only if billing follows suspension. In a multi-tenant fleet, the overwhelming majority of agents are idle at any given moment, waiting on users, tool calls, or external systems. Always-on compute billing charges for those pauses. Costs then grow with the total population of provisioned agents, including those waiting between periods of useful work.

Snapshot-restore changes what remains allocated during those pauses. A sleeping agent uses storage instead of a running compute instance, so idle VM-hours become storage-hours. Copy-on-write disk allocation further reduces duplication by allowing agents to share a base image while retaining their own divergences. Across thousands of dedicated environments, those savings add up. Suspended snapshots still consume disk, however, so storage remains an explicit part of the per-user cost model.

A higher per-unit rate with per-second billing and snapshot-restore may yield a lower bill for bursty workloads than a lower rate that requires warm pools or whole-minute billing. AWS AgentCore V2’s 2026 consumption pricing reclaims idle memory after a short inactivity window within a session, reducing allocation from its peak. That design reflects competition on idle-resource efficiency.

For a builder pricing a product, the useful comparison combines storage-only idle billing, per-second compute metering, and copy-on-write disk allocation. Each affects the cost of serving customers who return intermittently. The question for the provider is whether its billing model produces a viable per-user cost at the target fleet size and expected active-to-idle ratio.

How agent identity and credential isolation interact with per-user infrastructure requirements

An agent that acts in external systems needs more than an isolated place to execute. It also needs an identity that distinguishes the agent from the authority delegated by a user. Avatier’s 2026 identity reference describes agents as requiring their own identity class rather than being treated as humans or shared service accounts. The delegation chain identifies which agent acts for which user and within which scope. Infrastructure must preserve those distinctions across the agent’s lifecycle.

In this design, standing agent identity stays separate from per-invocation delegation tokens that carry the user’s authority. This separation is consequential even when an agent is dedicated to one customer because identity and permission are not interchangeable. A shared service account obscures the distinction. An isolated agent runtime provides a contained place for the agent’s identity and the credentials associated with its current work.

The same reference identifies operational risks including over-broad scopes, token theft from runtime memory, prompt-injection attacks, and audit-trail attribution gaps. Kernel-level isolation makes runtime credentials less exposed to other tenants, while isolated persistent disk removes the need to rebuild credential storage through a shared retrieval path on every boot. Neither property resolves all identity risks on its own. They provide the infrastructure boundary within which scoped authority can operate.

The platform must therefore keep per-agent identity and credentials on isolated disk. That identity must survive sleep-wake cycles without requiring re-authentication on every restore. Otherwise, suspension interrupts the agent’s authority to continue work even when its files and task state remain intact.

Developer tooling and deployment workflow as a practical multiplier on infrastructure quality

Architectural capabilities have limited practical value if developers must build a control plane to use them. Provisioning, scheduling snapshots, and orchestrating restores are part of the deployment cost when the platform leaves them unmanaged. That work changes the economics of adoption. The intended workflow is a single push from code to a live, isolated, persistent agent endpoint.

Tool connectivity is a separate part of that workflow. The Model Context Protocol provides a standard layer for connecting agents to tools and external systems, and its ecosystem in 2026 includes over 13,000 public servers. OpenAI deprecated its proprietary Assistants API in favor of the Responses API, which natively supports MCP as a tool-connector standard. MCP compatibility should therefore be a basic requirement when evaluating platforms, rather than an integration they can choose to leave out.

CLI and SDK tooling serve different needs from MCP. CLI commands leave more of the context window available for reasoning, while MCP’s schema overhead supports typed, auditable, multi-tenant-native tool access. Production teams in 2026 use CLI efficiency for development workflows and MCP for customer-facing and compliance-sensitive features. A platform that forces a choice constrains the application architecture. Agent2Agent protocol v1.0, released March 12, 2026, adds an emerging standard for inter-agent delegation, with over 150 supporting organizations under Linux Foundation governance.

The operational evaluation should therefore cover a supplied CLI, SDK, and MCP-compatible endpoint, together with platform-managed snapshot scheduling and restore. Native A2A support can further reduce integration work for multi-agent fleets. These capabilities determine how much infrastructure engineering remains between a sound runtime and a deployable product.

How should developers evaluate platforms for thousands of persistent agents, one per customer?

Developers should first ask whether each agent receives its own dedicated kernel. For workloads executing untrusted code, installing packages, or holding user credentials, the answer must establish a microVM boundary. The next question concerns what survives suspension. A persistent disk must keep files, installed packages, browser sessions, and credentials so developers do not have to rebuild them every time the agent wakes.

Latency and billing must then be evaluated together. The provider should publish snapshot-restore latency, identify whether snapshot scheduling is automatic, and distinguish restoration from cold boot. Sub-second or near-sub-second restore is the target for interactive continuity. To assess cost, developers should consider the per-VM-hour rate together with the expected fleet size and active-to-idle ratio. Fast resumption remains affordable as the customer population grows if storage-only idle billing, per-second compute metering, and copy-on-write allocation keep per-user costs viable.

Identity and tooling complete the assessment. The platform must keep per-agent identity across sessions and have the CLI, SDK, and MCP-compatible endpoint developers need to deploy without building their own control plane. Weeks of orchestration engineering belong in total cost of ownership even when the underlying compute is inexpensive.