This is Part 1 of a four-part series on agent sandboxing. Part 2 covers what goes wrong when agents run without the right protections. Parts 3 and 4 cover sandboxing patterns and scale.

“Agent infrastructure” means completely different things depending on who you ask. A background agent that picks up bug reports and opens pull requests is a different animal than a live coding session where a developer watches the agent iterate in real time. Running ten of either is a different problem than running a hundred thousand of them. Most infrastructure debates never resolve because people skip past two questions: what kind of agents are you running, and how many?

The industry does not have a shared vocabulary for agent execution. We keep saying “agent” to describe workloads with fundamentally different lifecycle, state, and isolation needs, then wonder why the infrastructure advice conflicts.

This post defines that vocabulary. Six execution modes name the distinct ways agents run in production today. Four scale archetypes describe the volumes at which they operate. Together, they give you a framework for deciding what you actually need to schedule, isolate, and sandbox these workloads.

Six ways agents run in production

Before you can pick infrastructure, you need to name what your agents do. Six patterns cover how agents operate in production today. Most companies use two or three simultaneously, each with different lifecycle, state, and resource characteristics.

Headless batch

Interface: Triggered by a schedule (cron), a CI pipeline, a ticket assignment, or a manual API call. No UI during execution. The user sees results after the fact: a pull request, a report, a Slack notification.

Pattern: The agent runs a task in the background inside an execution environment. It starts, does its work, and finishes. The environment is created for the task and destroyed on completion. Nobody is waiting. A CI job runs a script you wrote. A batch agent writes its own script, then runs it.

Lifetime: Minutes to hours. Ephemeral.

In production: Ramp Inspect (50%+ of merged PRs from batch agents), Wix Gandalf (support ticket to PR, fully autonomous), CoreWeave Sandboxes (thousands of parallel RL training environments).

Interactive

Interface: Anything where one user interacts with one agent. A chat thread (Claude on claude.ai, ChatGPT, Slack bot), a terminal (Claude Code, Codex CLI), a browser IDE (Devin, Replit, Lovable), or an editor extension (Cursor, Windsurf). The user sends input and gets responses, sometimes watching the agent work in real time, sometimes waiting for a reply.

Pattern: The dividing line within this mode is the workspace. Does the agent need files on disk, running processes, and in-memory state? The answer splits interactive into two sub-modes with different infrastructure needs.

Stateless (no workspace): The agent receives a message, reasons about it, calls tools if needed (database queries, API lookups, document search), and sends a response. Between messages, nothing is running. Conversation history lives in a database, loaded on each request, discarded from memory after the response. The most common agent pattern in production, and the simplest to run, because the agent is stateless compute. A load balancer, an inference endpoint, and a conversation store handle it at any scale. The security model is about tool access control and inference guardrails, not kernel isolation.

Stateful (with workspace): The agent needs an actual environment. When you use Claude Code, it reads and writes your files, runs cargo test, and edits based on the results. When you use Devin, it has a full cloud Devbox with a browser, terminal, and editor. One user, one session, one workspace. Sub-second responsiveness is the baseline. Cold-starting a new environment on every interaction is not viable when a user is watching. Each user needs their own workspace that is warm (no cold starts), stateful (survives idle periods), and eventually isolated (if running on shared infrastructure). Warm pools, checkpoint/restore, and per-user sandboxing all exist to solve this problem.

The boundary between the two is code execution. A customer support agent that queries a database and responds is stateless. A data analysis agent that writes Python, runs it in a sandbox, and returns a chart has crossed into stateful territory: it now needs a workspace. Building stateful infrastructure for a stateless agent wastes resources. Running a stateful agent on stateless infrastructure loses state.

Variants:

• Human-in-the-loop with long pauses: the agent proposes an action and waits for approval. Sometimes for days. The workspace needs to survive the pause.
• Always-on personal agent: an agent that persists across sessions, knows your codebase and preferences, and resumes instantly after days of inactivity.

Lifetime: Seconds per request for stateless. Minutes to hours for stateful sessions. Days for the approval variant. Indefinite for the personal agent.

In production (stateless): Nubank (131M customers, mobile app), Fifth Third Bank (175K calls/week, voice), Claude on claude.ai, ChatGPT, enterprise Slack/Teams bots.

In production (stateful): Claude Code, Codex CLI, Cursor, Windsurf (local workspace: your filesystem), Devin (cloud workspace: persistent Devbox), Lovable (cloud workspace: live preview per user), Replit Agent (cloud workspace: 200-minute sessions), Trigger.dev (durable workspace: checkpoint/restore).

Multi-user platform

Interface: A web application where each user sees their own workspace, preview, or development environment. The user does not know (or care) that hundreds of thousands of other users are on the same platform.

Pattern: One platform, many concurrent users. Each user gets their own isolated execution environment. The platform handles routing, isolation, and lifecycle management across all of them. Startup latency, density, isolation, and lifecycle management are all hard problems, and this pattern faces them simultaneously at volume.

Standard infrastructure breaks here.

Lifetime: Minutes to hours per user session. The platform itself never stops.

In production: Lovable (hundreds of thousands of projects/day, live preview), Modal (1M concurrent sandboxes), E2B (Firecracker microVMs, under 200ms startup), Daytona (full dev environments, sub-90ms from warm pool).

Always-on autonomous

Interface: A monitoring dashboard and alerting system. No direct user interaction during normal operation. The user sees the agent’s actions through dashboards, audit logs, and incident alerts.

Pattern: The agent runs continuously inside a persistent execution environment. It watches for events, detects anomalies, and acts without being asked. There is no session concept. The agent must survive restarts, node failures, and infrastructure changes. If it fails at 3am and nobody notices, incidents pile up undetected. These agents need health checks, restart policies, persistent state, and their own monitoring. They look like services, not jobs.

Lifetime: Indefinite.

In production: PayPal autonomous SRE (3,000 microservices, 450M users, 2B daily API interactions), Wix Gandalf (continuously monitors and self-heals production systems).

Multi-agent orchestration

Interface: A CI/CD dashboard or workflow UI showing sub-agent progress. The user sees the pipeline state: which sub-agents have completed, which are running, which failed. Intervention is at the orchestration level, not the individual agent level.

Pattern: A coordinator agent delegates work to specialist sub-agents, each in its own execution environment. The coordinator is long-running and sits outside the sub-agent environments. Results from one sub-agent become inputs to the next. A failure in one sub-agent should not take down the coordinator or the others. Separate failure domains.

Lifetime: Minutes per sub-agent. Hours for the orchestration.

In production: Ramp (CI pipeline with triage, coding, and review agents in separate environments), Daytona (up to 100,000 parallel forks for coordinated solution exploration).

Event-driven reactive

Interface: None. The agent is invisible to users. It is triggered by system events: a webhook, a field update, a new ticket. The user sees the result (a field updated, a ticket routed) without knowing an agent was involved.

Pattern: No running process between events. When a trigger fires, the agent wakes up inside a fresh execution environment, does the work, and shuts down. Between events, it consumes nothing. Scale to zero. The challenge is cold start: if initialization takes ten seconds, the agent cannot respond to events where users expect immediate feedback.

The distinction from always-on is the cost model (no process between events). The distinction from stateless interactive is the interaction model (fire-and-forget, not synchronous).

Lifetime: Seconds per event. Aggregate volume can be enormous.

In production: Airtable (event-driven agent fields that wake on user updates), WEX (40,000 IT tickets/year through reactive agents).

Now add scale: four archetypes

Knowing what your agents do is half the answer. The other half is how many you are running, and for whom. A headless batch agent on your laptop is a cron job. A thousand of them across six teams is a governance problem. Same mode, different world.

Solo builder

One to ten agents on a laptop or a single cloud instance. Claude Code, Codex CLI, Goose. The operating system kernel schedules processes. There is no orchestration problem.

The hard problem at this scale is context engineering: getting the right information into the agent’s prompt so it produces useful output. Rules files, memory systems, eval suites, skill libraries. Four million developers use Codex CLI weekly. Most of them are here. Most infrastructure discourse ignores them.

Any execution mode works at this scale without special infrastructure. Headless batch is a cron job on your laptop. Interactive is your terminal. Event-driven is a script triggered by a file watcher. The agent is the hard part, not the infrastructure.

Team fleet

Ten to a hundred agents on shared infrastructure. A team has a Jira-to-PR bot, a code review agent, a nightly triage pipeline. These look like CI/CD workloads with a language model in the loop.

Existing infrastructure handles scheduling here. A container orchestrator can run batch agents as jobs, always-on agents as long-running services, and event-driven agents as scale-to-zero functions. Simpler setups work too: a systemd service on a VM, a cron job on a shared server, or a serverless function on any cloud. The patterns are familiar because these are the same workload shapes teams already run for CI/CD, monitoring, and webhooks.

What changes when you add a language model is what the workload does during execution. A traditional CI job runs a script you wrote. An agent writes its own script, installs packages, calls external APIs, and makes network requests the job definition never anticipated. The infrastructure handles scheduling fine; the question is whether it handles what the agent does inside the job, which is a security question, not a scheduling question.

The gap at this scale is not infrastructure. It is the feedback loop between what the agent produces and how humans review it. A Slack notification from your CI job, or a PR comment that tags the right developer, solves more immediate problems than a new scheduling layer.

Enterprise platform

Hundreds to ten thousand agents spanning multiple teams. A platform team owns governance, not the agents themselves. Product teams build agents. The platform team provides guardrails.

The pain moves above the scheduler. Who is the agent acting on behalf of? Which agents can access which tools? How do you isolate one team’s agents from another team’s data? How do you attribute cost per team? Container orchestration handles the compute. The governance layer on top of it does not exist yet.

Enterprise consumers at this scale usually run on Kubernetes or plan to. Their blockers are identity, access control, and auditability.

Interactive, multi-user, and orchestrated agents cause the most trouble here. They need per-user environments, sub-second responsiveness, and cross-agent coordination that standard primitives were not designed for.

Hyperscale hosting

A hundred thousand agents or more, serving external users. Lovable, Modal, Devin, E2B, Daytona. At this scale, container orchestration cannot handle the density, startup latency, or isolation requirements. A purpose-built scheduling layer above Kubernetes becomes necessary.

Few companies hit this scale today. Post 4 in this series covers it in detail.

Why the combination matters

Neither dimension tells the full story alone. Knowing you run interactive agents does not tell you whether you need warm pools (depends on scale). Knowing you are at enterprise scale does not tell you whether you need per-user environments (depends on execution mode). The infrastructure decision sits at the intersection.

The same execution mode looks different at different scales:

Execution mode	Team scale	Enterprise scale	Hyperscale
Headless batch	Cron job. Standard.	Hundreds concurrent. Needs cost attribution.	Thousands parallel. CoreWeave built custom orchestration.
Interactive (stateless)	One chatbot. Standard.	Customer support across products. Needs tool governance.	Nubank: 131M users.
Interactive (stateful)	One developer, one session. Fine.	Per-user environments across teams. Needs identity.	Hundreds of thousands concurrent. Lovable broke the ReplicaSet controller.
Multi-user	Not applicable at this scale.	Internal platform. Needs tenant isolation.	The entire business. Modal rebuilt their scheduling backend.
Always-on	One monitoring agent.	Dozens across teams. Needs governance.	PayPal: 3,000 microservices, 450M users.
Orchestrated	CI pipeline.	Multi-team workflows. Needs cross-agent visibility.	Daytona: 100K parallel forks.
Event-driven	Webhook handler.	Hundreds of event-driven agents. Needs tool governance.	Airtable: millions of field updates per day.

A split emerges from the table. Headless batch, stateless interactive, always-on, and event-driven agents map to workload shapes that already exist: jobs, stateless services, long-running daemons, and functions. Most enterprises running agents today operate in this group.

Stateful interactive, multi-user, and orchestrated agents are different. They need per-user environments, sub-second startup, cross-agent coordination, and lifecycle management that most enterprises have never had to build. Agent pilots stall here. Not because the agents stop working, but because the infrastructure around them was never designed for workloads that create their own environments, act on behalf of humans, and execute code they wrote themselves.

Now you have the vocabulary. You can name what your agents do, how many you are running, and where you sit on the scale. The rest of this series uses that vocabulary to answer two questions. First, what goes wrong when these workloads run without the right protections? Every execution mode has a specific threat that isolation alone does not stop. Second, what does the right sandboxing look like at each scale, and where does standard infrastructure end and purpose-built infrastructure begin?