Uploaded June 2026 | Updated September 2026, 3 weeks ago
As AI agents become more capable, the infrastructure they run on is becoming just as important as the models themselves. But are the tools we’ve traditionally used for application infrastructure actually the right fit for agent workloads?
In this session, the Daytona team explores why Kubernetes, while excellent for running stateless services, was not designed to meet the unique requirements of modern AI agents. The talk traces the evolution of agent runtimes—from simple code execution environments to coding agents, reinforcement learning workloads, and knowledge-work agents—and explains why each generation demands new infrastructure primitives around isolation, performance, state management, concurrency, and security.
The presentation also dives into the architecture of modern sandbox environments, comparing them against traditional Kubernetes deployments across startup time, throughput, statefulness, developer ergonomics, and cost. Learn why sandbox infrastructure is emerging as a critical layer in the AI stack and how teams can prepare for a future where thousands of autonomous agents operate simultaneously across enterprise environments.
Timestamps
00:00 Why Kubernetes Is Not a Sandbox
00:40 The Evolution of Agent Runtime Requirements
01:58 From Code Execution to Coding Agents
02:23 Security, Isolation, and Agent Runtimes
03:00 Reinforcement Learning and Scale Challenges
03:12 The Rise of Knowledge Work Agents
03:52 What Kubernetes Does Well
04:12 Defining the Modern AI Sandbox
04:35 The Three Pillars of Sandbox Infrastructure
05:18 Performance, Throughput, and Concurrency
05:58 Stateful Agents and Runtime Primitives
06:49 Developer Experience and Ergonomics
07:22 Why Traditional Kubernetes Falls Short
07:58 Building a Scheduler for Agent Workloads
08:54 Stateful Infrastructure and Local Storage
10:17 Benchmarking Agent Infrastructure
11:16 Performance and Cost Comparisons
12:00 Managing Spiky Agent Workloads
12:35 Why Sandbox Infrastructure Matters
12:57 Final Thoughts
Key Takeaways
• The infrastructure requirements for AI agents have evolved rapidly, creating needs that traditional application platforms were not designed to address.
• Modern agent workloads require stateful environments, fast startup times, isolation, security controls, and massive concurrency at scale.
• Sandbox infrastructure is emerging as a specialized layer for agent execution, distinct from traditional application orchestration platforms.
• Performance, developer ergonomics, and state management are increasingly important factors when selecting infrastructure for agent systems.
• As organizations deploy larger fleets of agents, runtime infrastructure will become a key differentiator in cost, scalability, and reliability.
--
#AIAgents #Kubernetes #Daytona #AgentInfrastructure #AIEngineering #PlatformEngineering #DeveloperTools #AgenticAI #CloudInfrastructure #ArizeObserve
🔗 Try Arize AX & Phoenix OSS: arize.com
🔔 Subscribe for weekly content on LLMs, agents, and evaluation: youtube.com/@arizeai?sub_confirmation=1
As AI agents become more capable, the infrastructure they run on is becoming just as important as the models themselves. But are the tools we’ve traditionally used for application infrastructure actually the right fit for agent workloads?
In this session, the Daytona team explores why Kubernetes, while excellent for running stateless services, was not designed to meet the unique requirements of modern AI agents. The talk traces the evolution of agent runtimes—from simple code execution environments to coding agents, reinforcement learning workloads, and knowledge-work agents—and explains why each generation demands new infrastructure primitives around isolation, performance, state management, concurrency, and security.
The presentation also dives into the architecture of modern sandbox environments, comparing them against traditional Kubernetes deployments across startup time, throughput, statefulness, developer ergonomics, and cost. Learn why sandbox infrastructure is emerging as a critical layer in the AI stack and how teams can prepare for a future where thousands of autonomous agents operate simultaneously across enterprise environments.
Timestamps
00:00 Why Kubernetes Is Not a Sandbox
00:40 The Evolution of Agent Runtime Requirements
01:58 From Code Execution to Coding Agents
02:23 Security, Isolation, and Agent Runtimes
03:00 Reinforcement Learning and Scale Challenges
03:12 The Rise of Knowledge Work Agents
03:52 What Kubernetes Does Well
04:12 Defining the Modern AI Sandbox
04:35 The Three Pillars of Sandbox Infrastructure
05:18 Performance, Throughput, and Concurrency
05:58 Stateful Agents and Runtime Primitives
06:49 Developer Experience and Ergonomics
07:22 Why Traditional Kubernetes Falls Short
07:58 Building a Scheduler for Agent Workloads
08:54 Stateful Infrastructure and Local Storage
10:17 Benchmarking Agent Infrastructure
11:16 Performance and Cost Comparisons
12:00 Managing Spiky Agent Workloads
12:35 Why Sandbox Infrastructure Matters
12:57 Final Thoughts
Key Takeaways
• The infrastructure requirements for AI agents have evolved rapidly, creating needs that traditional application platforms were not designed to address.
• Modern agent workloads require stateful environments, fast startup times, isolation, security controls, and massive concurrency at scale.
• Sandbox infrastructure is emerging as a specialized layer for agent execution, distinct from traditional application orchestration platforms.
• Performance, developer ergonomics, and state management are increasingly important factors when selecting infrastructure for agent systems.
• As organizations deploy larger fleets of agents, runtime infrastructure will become a key differentiator in cost, scalability, and reliability.
--
#AIAgents #Kubernetes #Daytona #AgentInfrastructure #AIEngineering #PlatformEngineering #DeveloperTools #AgenticAI #CloudInfrastructure #ArizeObserve
🔗 Try Arize AX & Phoenix OSS: arize.com
🔔 Subscribe for weekly content on LLMs, agents, and evaluation: youtube.com/@arizeai?sub_confirmation=1
