Each agent = isolated machine (Cursor approach) or shared with smart resource management

At L5, organizations running agent fleets at scale face a fundamental architectural choice: does each agent get its own isolated machine (strong isolation, higher cost), or do multiple agents share machines with smart resource management (weaker isolation per agent, lower cost, higher density)? Both approaches work at scale; the choice depends on the organization's security requirements, cost constraints, and the types of tasks agents run.

The isolated machine approach - one physical or virtual machine per agent task - provides the strongest security guarantees. Cursor's engineering blog describes this as their production approach for running background agents: each agent task runs in its own Firecracker microVM on its own physical host. There is no sharing of memory, kernel, or storage between tasks. If one agent task is compromised or behaves unexpectedly, it has zero ability to affect any other task. This isolation level is appropriate for tasks that handle sensitive code, process secrets, or make financial decisions. The cost is significant: you are paying for a full machine for each agent, regardless of how much of that machine the agent uses.

The shared machine approach runs multiple agents on the same node with resource management controls (Kubernetes resource limits, cgroups, separate namespaces) to isolate them from each other. This is higher density and lower cost. A single node running 20 agent containers can process 20 simultaneous tasks at a fraction of the cost of 20 separate VMs. The isolation is not as strong - agents share the kernel, and container escape vulnerabilities can theoretically allow one agent to affect others on the same host. But for many use cases, especially tasks that do not handle particularly sensitive data, this risk is acceptable.

In practice, most organizations at L5 use a hybrid approach: different isolation tiers for different task types. Routine development tasks (write a test, fix a lint error, update documentation) run on shared machines with container isolation. High-sensitivity tasks (working in the payments service, modifying authentication code, handling credentials) run on isolated machines. The routing logic that assigns tasks to the appropriate tier is itself an interesting engineering problem that defines the quality of the hybrid architecture.

A third axis became practical in June 2026: where the model itself runs. Open-weight models now match hosted frontier coding models closely enough to run the agent on your own hardware - GLM-5.2 (Z.ai, MIT-licensed, beating GPT-5.5 on SWE-bench Pro at roughly one-sixth the cost), Kimi K2.7-Code (Moonshot, day-one vLLM and SGLang support), and DeepSeek V4 all run on-device via llama.cpp or vLLM. This sovereign local runtime gives the same capability with no vendor lock-in, which matters for the isolation decision: a self-hosted model in your own VPC keeps both code and weights off third-party infrastructure. The motivation is no longer hypothetical - Anthropic disabled hosted access to Fable 5 and Mythos 5 worldwide on June 12 to comply with a government directive (CNBC), so teams that need continuity should evaluate a local open-weight tier alongside the isolated-machine vs. shared-machine choice.

• The cost difference between approaches is large - isolated VMs for 100 simultaneous agents can cost 5-10x more than containerized agents on shared nodes; for large agent fleets, this cost difference is a significant budget consideration
• Isolation model defines your security guarantee - the choice between Firecracker VMs and shared containers is a choice about the strength of the security guarantee you can make; organizations with strong security requirements need VM-level isolation, not just container-level isolation
• Disk I/O sharing is the key performance bottleneck - Cursor's engineering team identified disk I/O (not CPU or memory) as the bottleneck when running hundreds of agents on shared machines; the architecture choice must account for storage isolation and IOPS allocation
• Bin packing efficiency matters at scale - 1,000 agent tasks on isolated VMs requires 1,000 VMs; the same tasks on shared nodes might require 50-100 nodes, each running 10-20 agent containers; the infrastructure management overhead of 1,000 VMs vs. 100 nodes is substantial
• The hybrid architecture scales better than pure approaches - a pure isolated-VM approach is too expensive at very high agent counts; a pure shared-container approach creates security concerns for sensitive tasks; the hybrid gives organizations a principled way to scale both security and cost simultaneously

1. Classify your agent task types by security sensitivity - Create a taxonomy of agent task types and assign each a sensitivity level. A simple three-tier model works: low (documentation, test writing, code explanation), medium (feature implementation, dependency updates), high (payment processing, authentication code, credential management). This taxonomy drives routing decisions.
2. Start with the shared-container architecture - Deploy all agent tasks as containers on shared nodes initially. This is simpler to build and operate. Measure actual isolation needs based on the types of tasks your agents run. Most teams will find that the majority of their agent tasks can safely run in shared containers.
3. Add a high-sensitivity tier with Firecracker - For the high-sensitivity task class, add a second tier using Firecracker microVMs. Firecracker provides near-VM isolation with container-speed startup (125ms boot time). Deploy a separate pool of Firecracker hosts for sensitive tasks, with the task router directing high-sensitivity tasks to this pool.
4. Implement the routing layer - Build or adopt a task routing service that inspects each submitted task, classifies it based on the taxonomy, and assigns it to the appropriate tier. The classifier can be rule-based (any task touching the payments/ directory is high-sensitivity) or ML-based for more nuanced classification.
5. Address disk I/O sharing at the shared-node tier - Provision shared nodes with NVMe-backed local SSDs and configure per-container I/O limits using cgroup blkio or the Kubernetes I/O throttle feature. Monitor disk IOPS per container during peak load to verify that I/O-intensive agents are not starving I/O for other agents on the same node.
6. Measure isolation effectiveness - For both tiers, run isolation verification tests quarterly: attempt container escape techniques against shared-tier nodes, verify that cross-VM access is impossible on Firecracker-tier nodes. These tests provide ongoing assurance that the isolation model is working as intended.

Defaulting to isolated VMs for everything based on theoretical security concerns. Isolated VMs for all tasks is the right choice if you have regulatory requirements or handle particularly sensitive code. For most teams, most agent tasks are low-sensitivity and shared containers are appropriate. Over-engineering isolation from day one creates unnecessary cost and complexity before you understand your actual security requirements.

Under-provisioning IOPS on shared nodes. If multiple agents on the same node are all reading large codebases simultaneously, they share the node's disk IOPS budget. Without per-container I/O limits, a single I/O-heavy agent can starve all other agents on the node. Always configure per-container I/O limits on shared nodes, and size the node's total IOPS budget based on the number of agents you plan to run per node.

Not auditing the routing logic. A routing system that is supposed to send sensitive tasks to isolated VMs is only effective if it correctly classifies sensitive tasks. Audit the routing logic quarterly by sampling tasks and verifying they are routed to the correct tier. Misclassification that routes sensitive tasks to shared containers silently degrades the security posture.

Treating Firecracker as a drop-in replacement for Docker containers. Firecracker requires different infrastructure than Docker: a Firecracker host needs the KVM kernel module, Firecracker-specific networking (TAP devices), and a different image format (ext4 filesystem images rather than OCI images). The operational complexity of running Firecracker is higher than Docker. Plan for this complexity in staffing and runbook development.

No cost allocation between tiers. Running two tiers (shared containers + isolated VMs) creates two cost buckets. Without attribution, you cannot tell whether the sensitive-task tier is appropriately sized or whether tasks are being misclassified to the more expensive tier. Implement cost tagging that tracks compute spend by tier and by task type.