For many teams building AI agents, extending existing Kubernetes infrastructure to run agentic workloads seems like the obvious move. As the control plane powering production applications, it feels well-positioned to support agent execution.
But as these workloads scale, the same primitives holding up those production services begin to strain. Soon, teams end up layering additional systems to provide the execution capabilities that agents require, turning their foundation into a patchwork of workarounds and fragile dependencies.
The solution isn’t abandoning Kubernetes altogether. Rather, it’s zooming out to see the missing piece in the stack: an execution environment built for the way agents behave.
Why Kubernetes Isn’t Designed for Agentic Workloads
Kubernetes became the standard control plane for many engineering teams by reliably operating containerized workloads at scale. Its pod-based architecture makes it well-suited for applications that assume instances are interchangeable, such as long-running microservices and horizontally scaled APIs. Across these workloads, state is decoupled from compute, and deployments follow a predictable pattern.
When teams start running agents in production, treating pods as the primitive for sandboxes feels like a natural extension of their Kubernetes setup. Agents execute code within their own environments, and Kubernetes excels at scheduling containers, managing their lifecycle, and distributing resources.
However, Kubernetes is optimized around a fundamentally different workload model than AI agents require. Agents need short-lived, task-specific environments, and execution patterns can vary significantly. The infrastructure supporting them needs to adapt in real time, all while safely carrying context across steps.
To close the gap, engineering teams begin assembling capabilities from multiple Kubernetes components and third-party tools, creating a substantial operational burden. Instead of focusing on agent improvements, teams spend hours connecting systems, managing complex lifecycles, and troubleshooting across the stack.
As concurrency grows into thousands of agent sessions, this approach starts to break at the seams.
The Hidden Complexity of Running Agents on Kubernetes
Agentic workflows do not move in straight lines. They navigate complex, branching pathways, rapidly chaining tool calls and evaluating intermediate outputs. When engineering teams run these workloads on Kubernetes, they inherit constraints that become increasingly difficult to manage.
Orchestration Complexity
Each agent task needs its own environment, complete with a dedicated filesystem and lifecycle. At thousands of concurrent tasks, engineering teams on Kubernetes end up building the lifecycle themselves, writing controllers to manage provisioning and execution, tracking which sandboxes are active, and cleaning up environments once a task completes.
That ad hoc architecture becomes increasingly difficult to support over time. As agent volume grows, so does the number of concurrent sessions, lifecycles, and ephemeral file systems that teams must coordinate. Each additional orchestration step introduces new failure modes, increasing the risk of orphaned sandboxes that consume storage needed by other workloads.
Provisioning Latency
Agents need a ready-to-use sandbox the moment a task begins. Without one, the agent stalls, and so does everything downstream waiting on its output. To reduce startup time, teams layer pre-built images, warm environment pools, and provisioning logic on top of their Kubernetes cluster.
Yet, this approach still has multiple steps. Consider a coding agent tasked with investigating and fixing a production bug. Before it can inspect the repository, it first needs Kubernetes to create available capacity, schedule the pod, pull its image, and initialize the runtime with the correct configurations.
Even when each step takes only a few seconds, the accumulated delay can turn a single task launch into a meaningful wait, compounding across tasks, slowing workflows down, and limiting throughput.
Isolation Overhead
Agents generate code, run tools, and modify files to complete tasks. Because these actions can produce unpredictable behavior, each execution environment needs strong isolation boundaries. That typically involves gVisor or Kata Containers, along with configuring CNI plugins such as Cilium or Calico to enforce granular egress rules.
These technologies come with their own costs. Kata Containers significantly increases baseline resource consumption. Meanwhile, shared-kernel approaches like gVisor slow I/O performance and create potential escape paths through exploitable API boundaries, filesystem access, and kernel vulnerabilities.
Repeated Context Reconstruction
Across most agentic workloads, the environment becomes part of the working context, accumulating files, dependencies, runtime configuration, and outputs that later steps rely on. Preserving that state on Kubernetes requires assembling additional layers, including PersistentVolumeClaims for the agent workspace, external stores for task state and artifacts, and CSI-backed snapshots for recovery or handoff.
When these custom builds fall short, agents often end up reconstructing context, introducing opportunities for environments to drift between executions. Those inconsistencies make long-running workflows less predictable and handoffs between steps less reliable.
Inefficient Resource Utilization
Agent infrastructure rarely has a predictable traffic pattern. A system can sit idle for hours, then suddenly need hundreds or thousands of environments at once. Supporting that variable demand is becoming a defining infrastructure bottleneck for production agent systems, pushing teams to pre-provision capacity for peak demand.
Determining how much of that capacity to keep in reserve becomes an ongoing infrastructure optimization problem. For example, keeping 500 sandboxes pre-warmed for a morning surge can mean reserving a total of 500 vCPUs and 1 TB of memory before agents begin work. When demand subsides, that unused capacity still consumes reserved compute, turning responsiveness into idle infrastructure cost.
Maintaining a smaller pool shifts the problem to performance. During a surge, agents queue for environments while new pods are scheduled, images are pulled, and additional nodes come online. That provisioning backlog can stall tasks, delaying customer-facing work and time-sensitive automations.
The Agent-Native Runtime Kubernetes Is Missing
The common thread across these challenges is that engineering teams are forced to build the execution layer their agents depend on. Purpose-built sandbox infrastructure removes that burden, enabling teams to operate agents reliably at scale.
Daytona provides that infrastructure. Teams get a fully managed sandbox platform to execute agent workloads at scale, with the option to deploy the runtime directly onto their own clusters while keeping Kubernetes as the control plane.
Instead of rebuilding capabilities from scratch, teams gain a runtime with all of them built in.
Native Primitive Fit
The only way to manage thousands of lifecycles efficiently is by using orchestration purpose-built for the execution model AI agents require. Using Declarative Builder for environment definition, Daytona’s orchestrator provisions and manages self-contained, single-instance sandboxes across cloud infrastructure, VMs, and bare-metal servers. Each sandbox operates with its own resources and lifecycle, giving agents a consistent runtime regardless of the underlying infrastructure.
By embedding these capabilities into the runtime, Daytona frees up engineers to focus on refining agent behavior. This shift accelerates iteration on new workflows and helps teams evolve agent applications over time.
The impact is measurable. Using Daytona, Trajectory saves 15+ hours each month previously spent stitching together solutions on top of Kubernetes. Their team also benefits from more predictable infrastructure operations, making it easier to support new agent workflows.
Sub-90ms Sandbox Provisioning
At scale, provisioning speed becomes just as important as execution speed. Rather than maintaining an idle pool of warm sandboxes, Daytona provisions sandboxes on demand from pre-warmed snapshot templates. With this setup, the platform provisions new Firecracker microVMs in <90ms.
By eliminating startup latency, Daytona keeps interactive agent workflows responsive, enabling agents to chain tool calls, respond to user requests, and launch follow-up tasks without waiting on infrastructure.
That difference becomes significant as agent workloads scale and environments are created more frequently. AfterQuery cut sandbox creation times by 86% after replacing their GKE-based provisioning with Daytona. Their team now launches agent simulations sooner and delivers faster evaluation cycles to customers.
Built-in Isolation
Giving agents more freedom and flexibility without sacrificing control starts with strong execution boundaries. By using dedicated microVMs powered by Firecracker and Cloud Hypervisor, Daytona delivers full operating environments with dedicated kernels, isolated filesystems, and virtualized network stacks.
Those boundaries enable teams to safely execute untrusted code without extra configuration or tooling. If a process fails or behaves unexpectedly, the impact remains confined to that individual sandbox, freeing other agent sessions to continue uninterrupted.
For organizations with strict security requirements, those guarantees often determine where they can deploy their AI applications. Previously, supporting regulated enterprise customers required Athena Intelligence to maintain six specialized sandbox environments. With Daytona, the team consolidated them into a single runtime layer while meeting the security requirements needed for Fortune 500 deployments.
Persistent Execution
Execution environments that preserve progress ensure each decision builds on the work that came before it. Daytona combines stateful sandbox lifecycles with persistent Volumes and Snapshots to preserve each sandbox across sessions. Files, dependencies, runtime configuration, and intermediate outputs remain intact, enabling agents to pause and resume work whenever a task continues.
With that continuity, long-running workflows complete more efficiently. Compute that would otherwise be spent restoring context is redirected toward reasoning over new inputs, processing additional data, and advancing toward completion.
At scale, preserving execution state becomes a force multiplier for teams iterating across thousands of agent workflows. Because its agents execute within Daytona’s stateful environments, the Laude Institute increased experiment throughput by 100x.
Elastic Sandbox Scheduling
The economics of agent infrastructure increasingly depend on how efficiently compute is allocated. Daytona continuously schedules sandboxes on available runners, routing execution across cloud infrastructure, VMs, and bare-metal servers based on available capacity. That way, it keeps resource utilization high without requiring teams to make infrastructure decisions.
The infrastructure becomes responsive to workload behavior, so teams can accommodate variable demand. Idle infrastructure costs drop while resources stay available for sudden spikes. Agent sessions continue during bursts of concurrent activity, so interactive workflows remain responsive as workload volume fluctuates.
That flexibility lets teams expand agentic workloads efficiently. By using Daytona to execute thousands of agent evaluations, WolfBench minimizes idle compute and keeps costs predictable, freeing resources for faster, more frequent testing.
Daytona Turns Agent Prototypes Into Scalable Production Workloads
The question is not whether teams should choose Daytona or Kubernetes. It’s whether the execution layer underneath your agents was designed for the workloads they need to run.
Kubernetes solved the problem of operating containerized applications at scale. Daytona solves the next problem: providing the runtime layer that turns promising agent prototypes into production systems that operate at real-world scale.
If you’re building production-scale agent infrastructure, Daytona can help. Schedule a call with our experts.
