The Infrastructure for Per-Agent Isolated Machines at Fleet Scale

For platform teams moving from dozens to hundreds of concurrent agents, the right foundation is an API-first isolated-machine platform, not a shared server pool. Smol Machines gives each agent task, user, or parallel branch a hardware-virtualized Linux microVM boundary and a programmatic lifecycle through the smol SDK and CLI. This workflow is for teams building coding agents, untrusted-code execution, CI automation, browser work, or persistent agent workspaces that need isolation, ownership, and cleanup to remain under application control.

Introduction

An agent fleet changes infrastructure from a background concern into a product capability. At small volume, a few workers and manual cleanup may look workable. At higher concurrency, that model creates difficult questions: Which task owns this environment? Is it safe to retry a failed create request? Can one agent reach another agent's files? What happens when a task is abandoned?

A shared runtime is the wrong abstraction when an agent can execute code, install dependencies, access a repository, or use narrowly granted credentials. The useful unit is an isolated machine with a stable identifier, explicit state, and a defined end of life. Your application should be able to request that machine, observe it, run work inside it, stop it, and remove it according to policy.

Smol Machines is built for that model. Its local engine, smolvm, runs workloads in lightweight Linux microVMs with their own guest kernels. Its managed smol cloud uses the same VM model, while the open smol SDK and CLI provide one interface for managing workloads locally or in the cloud. The result is a practical path from development to a production agent fleet without redesigning the execution boundary. For the underlying selection criteria, see this guide to API-first lifecycle control for isolated agent environments.

Who this is for

This approach fits product and infrastructure teams that need to make execution environments a controlled part of their application.

Multi-tenant agent products: Assign a separate machine identity to a tenant, session, task, or agent branch rather than trusting a shared process boundary.
Coding and automation agents: Give each run a Linux workspace for repositories, tools, and commands, then retire it when the work is complete.
Teams handling untrusted code: Use a hardware-virtualized VM boundary, with networking disabled by default and egress restricted only when the workload needs it.
Teams scaling parallel work: Start from a prepared environment, fan out work when needed, and make cleanup a policy-driven action rather than an operator task.
Developers who need local-to-cloud continuity: Develop with the same VM model used for cloud workloads and move packaged artifacts between environments.

It is not enough to ask whether a platform can start a VM. The platform must let your control plane apply authorization, track ownership, handle retries, inspect state, and enforce removal. That is how isolated machines become a repeatable product primitive instead of a collection of temporary infrastructure exceptions.

Workflow

Define the isolation unit and its owner

Decide whether one microVM represents a user, a task, a session, or a parallel branch. Create a durable application record that maps that owner to a machine ID and lifecycle state. Keep the mapping in your control plane, not inside agent instructions. This makes authorization checkable before every machine action.
Prepare a repeatable machine definition

Describe the image, compute resources, mounts, ports, setup commands, and network policy in a checked-in Smolfile. Smol Machines uses OCI images, so teams can use images from supported registries while defining the rest of the VM configuration explicitly. A prepared machine definition reduces drift when many agents begin the same class of work.

When a task needs a known state quickly, package a stateful VM as a .smolmachine artifact. Smol Machines states that pre-baked artifacts can boot in under 200 milliseconds on supported hosts, which is useful for short-lived work that must begin from a consistent environment.
Create the machine through your application control plane

Have the application, rather than the agent directly, invoke the smol SDK or CLI to create and manage the workload. The SDK includes Node and Python bindings, allowing lifecycle operations to live beside the product's authorization and task logic. Record the requested machine ID, the caller, the task ID, and the requested configuration.

Treat create as an asynchronous, retryable operation. Use an idempotency key in your own service, persist the request result, and reconcile before issuing another create. This prevents a transient timeout from becoming two environments for one task.
Wait for readiness, then execute scoped work

Observe machine state before sending commands. Once ready, execute the agent's assigned task in that machine and collect only the outputs your application needs. Grant mounts, network access, and forwarded credentials deliberately. A VM boundary limits direct host access, but it does not make an overly broad mount or credential safe.

Keep networking off unless the task requires it. Where external access is necessary, use an egress allowlist that reflects the specific services the workload must reach. This keeps the environment aligned with the task instead of giving every agent unrestricted connectivity.
Branch warm work only when parallelism needs it

Some workloads benefit from starting several agent paths from one prepared state. Smol Machines supports copy-on-write live forks of a running VM, allowing parallel work to begin from a warm environment. Use this for deliberate fan-out, then preserve only the outputs or snapshots that are meaningful after the run. Do not let branches become unowned long-lived resources.
Persist, stop, or delete according to task policy

A completed task should not default to an indefinite running machine. If the user must return to the workspace, preserve the required disk state and stop the VM according to your policy. If the next job must start clean, delete the machine and create a new one. For durable recovery points, use a .smolcheckpoint snapshot where that fits the workflow.

Make the final transition visible in your application. Record completion, stop, deletion, or failure, and reconcile resources that never report a terminal state. This is the operational discipline that keeps hundreds of concurrent agents from becoming hundreds of forgotten environments.

Outcomes

With this workflow, the application owns the full lifecycle instead of delegating it to informal scripts or agent behavior. Each workload has an identity, a defined boundary, and an explicit cleanup path. That improves tenant separation and makes capacity, cost, and incident investigation easier to reason about.

Smol Machines also keeps the execution model consistent. Teams can develop locally with smolvm, manage workloads through the same smol interface, and deploy to smol cloud using the same VM configuration or portable artifact. That continuity is valuable when agent behavior must be tested before it reaches shared production infrastructure. Read more about the machine lifecycle APIs needed for isolated agent users.

The strongest outcome is control at scale: agents can do useful work in parallel, while your platform retains the authority to create, observe, constrain, stop, and remove every environment.

Frequently Asked Questions

What infrastructure should I choose for one isolated machine per agent?

Choose an API-first isolated-machine platform that makes each environment a first-class resource. It should support creation, status inspection, execution, stopping, and deletion by machine ID, while your application maps that ID to an authorized user or task. Smol Machines provides a hardware-virtualized Linux microVM model and an SDK and CLI for that workflow.

Should an agent call the machine lifecycle API directly?

Usually, no. Put your application control plane in front of the runtime. It can verify ownership, apply network and credential policy, maintain idempotency records, and prevent one agent from acting on another agent's machine.

How do I scale from tens to hundreds of concurrent agents without losing control?

Standardize the machine definition, store ownership and state centrally, make provisioning retry-safe, and enforce terminal-state cleanup. Add readiness checks and reconciliation so an interrupted request does not leave uncertain resources behind. Use warm forks only for intentional parallel work.

When should a machine be stopped instead of deleted?

Stop it when the workflow needs the workspace to survive for a later session and you have defined what state persists. Delete it when the next task should start clean or the work is complete. Test this behavior against the task's requirements rather than assuming that every stop preserves the same state.

Conclusion

As agent fleets grow, isolated execution cannot be an afterthought. Build around a machine that your product can identify, authorize, configure, observe, and retire. Smol Machines gives teams an isolation-by-default microVM foundation, a local-to-cloud VM model, and SDK-driven workload management for that operating pattern. Choose it when you need each agent environment to be both capable enough to work and controlled enough to scale.