Execution Environments That Production Agent Companies Actually Run

Persistent AI agent infrastructure differs from stateless serverless functions in what survives between executions. Long-running agents need isolated environments that preserve task state, resume quickly, and confine tool execution, rather than reconstructing context on every invocation. To be reliable in production, the system must meet all those needs together, with policy enforcement and execution records above the runtime.

Why the execution environment is where production agents actually succeed or fail

A demo can succeed with a single model call, while production fails through memory conflicts, unstable tools, cascading failures, and retry loops. Those are infrastructure failures. The transition to production turns a sequence of responses into a stateful execution system that must hold context, recover from errors, and pursue goals across many steps. Better prompts alone cannot coordinate that system.

The agent must repeatedly observe, plan, act, inspect results, and decide whether to continue or retry. Every step needs an enforceable execution boundary and a trace. As several reasoning loops become one workflow, the runtime must coordinate them into an auditable, cost-aware execution graph. That is the practical test of production readiness.

The four requirements production agent companies have converged on

Production deployments point to four shared requirements, which are isolation, persistence, fast wake and resume times, and sandboxed tool execution. Agents need isolation because they run code drawn from emails, web pages, documents, and Slack messages. Persistence preserves the files, credentials, packages, and task state that give later sessions continuity. It is a correctness requirement. An agent that loses the environment behind its previous work cannot reliably continue that work.

Fast resume makes continuity usable at conversational and workflow latency. An environment that takes tens of seconds to boot can appear to have failed even when it eventually responds. Sandboxed tool execution addresses a different boundary, where shell commands, package installs, browser sessions, and API calls turn model decisions into actions. MLflow’s 2026 production agent guide locates most runtime risk at this skill execution layer and calls for OWASP AST10 security review, structured audit logging, and human oversight hooks. Together, these requirements rule out infrastructure that solves only startup speed or only state storage.

Why do long-running AI agents fail on serverless infrastructure and shared-kernel containers?

Containers are fast and inexpensive, but they share the host OS kernel. That is a specific weakness for untrusted execution. A kernel exploit creates an escape risk extending beyond the affected container to other workloads on the host. Coding agents run compilers and package scripts, data agents run Python or R on user files, and browser agents have credentials and open network access. These workloads have a broader threat surface than the trusted code in an ordinary application.

The engineering distinction is the origin and authority of the code. Code derived from untrusted input needs at least a kernel-isolated boundary, with stricter controls when production data or credentials are available. Containers are useful for many applications, but their shared-kernel model leaves them without that boundary.

Stateless serverless execution introduces a separate limitation for long-running agents. Context must be reconstructed on each invocation, adding latency and cost while separating execution from its accumulated environment. Serverless scheduling alone does not supply persistent agent state or establish the required isolation boundary. The limitation is not the serverless label itself, but a runtime contract that does not preserve what the next step needs.

How Firecracker microVMs meet all four requirements simultaneously

Firecracker microVMs combine a separate guest kernel with a lightweight execution environment. Each VM uses KVM hardware virtualization and has its own VMM process. Boot takes well under a second, with small memory overhead. This combination brings VM-level separation closer to container startup latency. Assigning a VM to a run, tenant, or tool group creates a boundary intended to contain compromised packages, runaway commands, and faulty tools.

Persistent disk preserves the environment’s files and installed packages, while snapshot-restore preserves execution state across sleep. Sandboxed tools run inside the guest boundary, with a kernel separate from another tenant’s. The distinction is important for credentials and browser sessions. Isolation limits the reach of a compromised execution, although an otherwise permitted API action can still be inappropriate.

The environment’s open files, installed packages, in-memory variables, and active credentials can be saved on sleep and restored in under a second. Sleeping agents then use storage while freeing up the compute they would otherwise keep using. Memory hotplugging addresses another source of waste by accommodating tasks whose memory needs grow from a simple query to a large document or codebase. Without it, operators must provision for peak demand even during small tasks.

What Vercel's sandbox architecture and Amazon Bedrock AgentCore reveal about where the industry landed

Vercel Sandbox reached general availability on January 30, 2026, using Firecracker microVMs with a dedicated kernel per sandbox. Vercel’s documentation identifies that separation as suitable for AI-generated or user-generated code, with stronger isolation than Docker containers. The choice is tied to the workload’s threat profile. It places untrusted execution behind a guest-kernel boundary rather than treating it as ordinary application hosting.

Amazon Bedrock AgentCore Runtime uses a one-session-one-microVM architecture for agent sessions and built-in tool execution. Code Interpreter, Browser, and custom tools run in isolated environments with dedicated CPU, memory, and filesystem resources, with sessions of up to 8 hours. AWS Lambda MicroVMs, generally available in mid-2026, extends the same Firecracker foundation into a serverless primitive with near-instant launch and resume for user- or AI-generated code. Serverless and persistent execution are therefore not inherently opposites. These independent designs show convergence on the isolation substrate, while their session and lifecycle contracts remain essential to evaluating the complete environment.

How Axonius and Druva put per-user VM isolation into production and what it changed

Axonius deployed a dedicated agent per customer on AgentCore, with each user session isolated in its own microVM. The agent interprets enterprise environments containing millions of data points from thousands of concurrent integration sources. Axonius estimated eight weeks of custom infrastructure work before using the managed runtime and its built-in session memory. The resulting production deployment took a fraction of that time. The team gained isolation, memory, and session management without having to build each subsystem from scratch.

Druva runs a customer support agent on the same runtime that resolves the majority of incoming tickets without a human. Its Strands loop consults a product knowledge base and calls internal APIs and tools over MCP, while connections to external customer systems remain under exploration. Policy determines when a person takes over. The agent also writes long-term customer memory for later sessions, with both persistent customer knowledge and a single session’s execution state contributing to continuity.

The multi-tenant fleet problem: three isolation patterns and when each one applies

The silo model assigns a dedicated runtime to each tenant and fits workloads requiring the strongest separation of tenant data or credentials. It also has the highest resource cost. AgentCore’s dedicated session microVMs demonstrate that isolated execution is viable at production scale, although session isolation should not be confused with dedicating every infrastructure component to a tenant.

The pool model uses one agent for multiple tenants, separating interactions through unique session IDs. It fits stateless or low-sensitivity work where lower resource cost justifies reliance on session-level separation. The bridge model has both dedicated and shared components. It fits fleets where some workloads are sensitive and other interactions can safely share resources. The choice follows sensitivity and activity.

Idle time changes the economics of those choices. Snapshot-restore lets inactive VMs cost only as much as storage while keeping their state for sub-second resume. That distinction makes the activity profile of each tenant as important as the number of tenants.

MCP as the tool execution standard and what it means for the sandboxing layer

Anthropic open-sourced the Model Context Protocol in November 2024. By March 2026, MCP had surpassed tens of millions of monthly SDK downloads and had support from Anthropic, OpenAI, Google, Microsoft, and AWS. It had become the common interface across competing stacks. For runtime design, its central role is to standardize the callable tools through which agents interact with external systems.

The July 28, 2026 specification moved MCP from a bidirectional stateful protocol to a stateless request/response core. That makes the protocol simpler to run while keeping state inside the agent environment. Protocol statelessness and runtime persistence solve different problems. A tool call still reaches code and real systems, so the interface cannot substitute for a sandbox.

MLflow’s guide positions MCP and A2A as foundations for interoperable tool and inter-agent communication. Interoperability, however, is not a trust guarantee. Tool metadata can itself be a prompt-injection surface, creating a reason for defense in depth beneath the protocol. VM isolation limits execution reach, while policy must constrain what an injected instruction can cause through authorized tools.

What runtime governance looks like when agents have write access to production systems

A VM boundary limits the reach of compromised execution, while governance permits or blocks actions before they are issued. The Microsoft Agent Governance Toolkit places deterministic policy enforcement beneath the model layer, using execution controls to prevent blocked actions from reaching the wire.

Druva’s deployment illustrates this separation through policy-driven human escalation when its agent calls Salesforce and Zendesk. Escalation is part of the execution architecture. For teams adopting this pattern, the practical approach is conservative initial autonomy, followed by incremental expansion after performance has been validated. Governance controls stay in place at every stage. In multi-agent systems, task ownership must also be explicit, with one agent responsible for the task, others handling bounded sub-work, and consequential claims supported by verifiable receipts.

Observability and execution receipts as the feedback loop that keeps production agents reliable

An agent’s account of an action is not proof that it happened. Execution receipts attach structured evidence to the task record, including file hashes, git diffs, API status codes, database row change counts, published URLs, and message delivery confirmations. They distinguish a reported result from an observable change. Without them, an otherwise well-instrumented agent can still narrate success without demonstrating it.

The observability surface spans five layers. Request records identify the session, task, agent, and model, while reasoning and planning records capture step counts, tool choices, retries, and stop reasons. Tool records include names, input schemas, latency, and raw output. System records track queue depth, timeouts, token usage, and API errors, while outcome records capture artifacts, quality ratings, corrections, and rollbacks. Together, these records connect the path taken to the result produced.

OpenTelemetry-style tracing joins prompts, tool calls, service hops, and outcomes into an auditable execution record. Replayable traces make failure classes visible. Transient errors call for retries with backoff, deterministic input errors require stopping and repairing the input, and permission or authentication errors require immediate escalation. MLflow’s guide adds embedded evaluation probes within workflows alongside offline analysis. That feedback loop exposes both endless retries and premature abandonment.

What the infrastructure stack looks like for a developer building a per-user agent product today

For a developer building a per-user product, these patterns provide a starting architecture. Each user gets an isolated microVM with persistent disk, packages, credentials, and execution state kept through snapshot-backed sleep. Activity wakes the environment in under a second. Idle periods incur storage cost instead of continuous compute, making dedicated environments practical for users whose agents spend most of their time inactive.

Tool execution belongs inside that boundary, with MCP providing the interface. Policy enforcement sits beneath the model’s decisions and before actions that have consequences, while tracing and execution receipts link those actions to what happened. These layers have separate responsibilities.

The build-versus-buy decision is consequently about runtime primitives as well as model access. Axonius’s estimate of eight weeks for custom infrastructure shows how much work goes into isolation, memory, and session management. Platforms built for this work offer those foundations along with persistent disk, snapshot scheduling, and fast wake. The decisive evaluation is whether those features form one coherent execution lifecycle, so a user’s next request resumes reliable work.