The platform team already runs every service on the cluster, so the request sounded small: give the coding agent somewhere to run the code it writes. A pod per task, a namespace per customer, a cron job to sweep up the leftovers. Weeks later, the controller that tracks those pods has its own pager rotation.
Kubernetes is good at the job it was designed for, keeping interchangeable copies of a service alive. An agent's environment is the opposite: a machine that belongs to a single task, runs code nobody reviewed, keeps state between steps and sits idle while the model thinks. Kubernetes alone falls short because each of those needs has to be built on top of it, while Solari, an agent-native runtime, ships them as API calls. This guide walks through the four places the gap shows up.
What Kubernetes Was Built to Run
The gap starts with the workload model, so that is the place to begin. Kubernetes schedules pods, and its controllers keep a declared number of identical copies running. Any copy can replace any other, because the state lives in a database outside the pod.
An agent task breaks that assumption. Its environment is unique to the job, it collects files the next step depends on, and losing it halfway means losing the work. The first place this shows is the lifecycle.
Who Owns the Lifecycle of an Agent Environment
Lifecycle is the gap teams hit first, because nothing in a stock cluster knows when an agent task has finished. So the team writes a controller that creates an environment per task, tracks which ones are live and deletes the orphans a crashed task leaves behind.
An agent-native runtime makes the lifecycle part of the object. A Solari sandbox or VM is created with an idle timeout and a policy for when it expires: pause, which saves its state, or kill. Since every action and every open connection resets the clock, a busy machine is never reclaimed mid-task.
Ending an environment is the easy half; starting one quickly is harder.
How Fast an Environment Has to Start
Start time matters because an agent cannot take its next step until its machine exists. A pod start is a chain: the scheduler picks a node, the node pulls the image, the runtime boots the container. Teams shorten it with warm pools, which means paying for idle capacity sized for the peak.
On Solari the chain is a single API call: sandboxes take 90 ms to spin up, and a VM starts in about a second.
Pausing replaces the warm pool, because a paused Solari VM stops counting against the plan's limit on running VMs until it resumes. Once a pause has settled, a same-host resume takes about 1.3 seconds on staging, five trials. Speed only helps, though, if a misbehaving task stays contained.
Isolation for Code Nobody Reviewed
Isolation is where agents differ most from services, because the code inside was written by a model moments ago. Standard containers share the host kernel and are separated by namespaces and cgroups, so clusters that run untrusted code add gVisor or Kata Containers, plus egress policies.
Solari puts that boundary in the create call instead. Its default dedicated tier gives each sandbox a microVM of its own behind its own hypervisor, and the hardened tier is the same machine with all outbound network blocked. Isolation contains a task; keeping its progress is the last gap.
Keeping State Between Steps
State is the gap that grows with task length, because an agent's environment becomes part of its working memory. On Kubernetes, keeping it means PersistentVolumeClaims, an external store for task state and volume snapshots, all wired by hand.
On Solari, by contrast, state is a lifecycle call. Pausing a VM saves its state so the next connect picks up right where it left off, and sandboxes share the same lifecycle. A running sandbox can also be snapshotted and forked, so an agent can try several fixes from an identical starting point. With the four gaps mapped, the question becomes what stays on the cluster.
Where Kubernetes Still Fits
The table below puts the four gaps side by side.
Even so, Kubernetes keeps its place as the control plane. The agent's API, queue and orchestration logic are ordinary services; they call the runtime for each task the way they call a database, a split the introduction to Solari also describes.
The last row matters once agents leave the terminal. Solari runs browsers, sandboxes and desktops from one account and one API, so an agent that writes code and then checks a web page needs no second vendor.
Choosing the Right Setup
The rule is to keep Kubernetes for the services that coordinate agents and give each agent task an environment from a runtime built for it. A team writing a cleanup controller, a warm pool, a gVisor layer and a volume scheme is rebuilding that runtime by hand. Kubernetes is the established standard with the larger ecosystem; Solari is the younger platform and moves faster on the agent environment itself.
Get Started With Solari
Start by moving the agent's code execution into a Solari sandbox and leaving the control plane where it is. Solari is about 1.7x faster than Daytona on a sandbox's full lifecycle and almost 3x cheaper per sandbox hour, and the Free plan costs $0 with $3 of credits each month. Create a first sandbox from the sandboxes guide and start free.
