The promise of AI agents is compelling: autonomous entities capable of executing complex tasks, collaborating, and learning to achieve goals with minimal human intervention. Imagine a fleet of these agents working seamlessly across your infrastructure, tackling coding projects, data analysis, or intricate workflows. This vision, however, often collides with the messy reality of distributed systems and the inherent complexities of managing intelligent, autonomous entities at scale.
Kyle Jaejun Lee from KRAFTON, a company at the forefront of AI integration, recently shared invaluable insights into the practical challenges of running AI agent fleets across multiple machines. In his presentation at AI Engineer World's Fair 2026, Lee highlighted five critical failures encountered in real-world deployments and outlined a robust set of solutions for building more scalable and reliable agent systems. His findings underscore a crucial point: the human element often becomes the central bottleneck in achieving true agent scalability and reliability.
The Vision vs. The Reality of AI Agent Orchestration
Initially, the appeal of AI agents is their ability to offload cognitive load and automate tasks that traditionally require human decision-making. Developers and researchers envision agents as digital team members, each with specialized skills, contributing to a larger objective. However, moving from a single agent prototype to a multi-agent fleet operating across diverse hardware introduces a cascade of system design and operational challenges.
Lee's experience at KRAFTON quickly revealed that while individual agents might perform brilliantly in isolation, their collective behavior in a distributed environment often leads to unforeseen issues. The core problem, as he articulated, was the human operator inadvertently becoming the central coordinator, effectively turning a supposedly autonomous system into a highly manual one. This critical observation forms the bedrock for understanding "what broke" and subsequently, "how to fix it."
Lee's Initial Agent Fleet Setup and The Human Bottleneck
To understand the failures, it's essential to grasp Lee's experimental setup. His initial architecture involved a modest yet representative fleet across three distinct machines:
- MacBook: Utilized for heavy coding, personal projects, and interactive tasks. It would sleep when not actively in use.
- Linux A: A headless (no monitor) Linux machine dedicated to long-running coding tasks.
- Linux B: Another headless Linux machine, designated for short-lived coding tasks.
A central control plane was intended to manage these agents, but in practice, Lee found himself stepping into the role of this control plane. He became the de facto scheduler, memory manager, and output reviewer for every agent across all machines. This human-centric approach, while functional for a minimal number of concurrent tasks, rapidly became a severe bottleneck. As the number of agents and tasks grew, Lee described being utterly overloaded, managing multiple live contexts simultaneously. This manual orchestration, far from the autonomous ideal, highlighted the immediate need for a more structured, automated system.
The Five Critical Failures Uncovered
Lee's practical experiments led to the identification of five key failures that are common pitfalls when attempting to scale AI agent fleets:
Failure 1: Agents Doing Work Instead of Dispatching
The orchestrator layer is designed to act as a conductor, delegating tasks to specialized worker agents. However, Lee observed a critical breakdown: agents began executing tasks themselves, bypassing the intended dispatch mechanism. This led to a chaotic system where tasks were not routed to the most appropriate or available worker, resulting in inefficiencies, duplicated effort, and incorrect task execution. The lack of strict delegation and enforcement meant the system lost its intended structure, becoming a free-for-all where agents overstepped their boundaries.
Failure 2: The Screen Real Estate Dilemma
While seemingly minor, the practical challenge of monitoring multiple agents simultaneously quickly became a major hindrance. As more tasks were added and more agents became active, the sheer number of small panes or terminal windows required to track their progress became unmanageable. It was difficult to read, interpret, and track the status of individual agents, leading to potential misinterpretations, missed errors, and a significant increase in cognitive load for the human operator. This highlighted the need for robust, centralized observability and intuitive UIs, rather than relying on disparate visual feeds.
Failure 3: Memory Exhaustion and State Loss
One of the most insidious problems was the continuous accumulation of agent processes and their internal states. Over time, the system would gradually consume more and more memory, eventually leading to exhaustion. This often culminated in the system becoming unresponsive, requiring manual restarts. Such restarts were not merely inconvenient; they resulted in the loss of in-progress jobs and valuable context, forcing agents to restart their work from scratch and eroding overall system reliability and efficiency. Managing persistent state and resource lifecycles became paramount.
Failure 4: Git Credential Conflicts
In a collaborative development environment, agents often need to interact with shared resources, such as Git repositories. Lee's setup revealed significant issues when multiple agents attempted to access these shared repositories, particularly concerning credential management. The expectation of a simple one-to-one mapping of credentials to individual workspaces failed in practice. Agents would often conflict over access rights or inadvertently use incorrect credentials, leading to repository divergence, access errors, and corrupted states. This pointed to a fundamental flaw in how shared secrets and access controls were being handled in a multi-agent context.
Failure 5: Loss of State on Machine Failure
Hardware reliability is a constant concern in any distributed system. In Lee's setup, the MacBook, being a laptop, was particularly susceptible to power loss or network interruptions. Any task running on it at the time of failure would be completely lost. The machine would simply restart without retaining its previous state, meaning hours of agent work could vanish instantly. This highlighted a critical lack of fault tolerance and state persistence, making the entire fleet vulnerable to single points of failure and severely impacting task completion rates.
A Paradigm Shift: Towards a Structured Orchestration Model
To address these fundamental shortcomings, Kyle Jaejun Lee proposed a significant paradigm shift. He advocated for moving away from ad-hoc management and towards a more structured, hierarchical approach — one that mirrors effective human organizational structures. The core idea is to define agents not by where they run, but by what they need.
This shift emphasizes a clear separation of concerns: agents declare their requirements, and the system is responsible for fulfilling those requirements by dynamically assigning resources and managing execution. This moves the burden of coordination from the human operator to a robust, automated orchestration layer.
Solution 1: Defining Agents by "What" Not "Where"
The proposed architecture introduces a clear hierarchy:
- Orchestrator Layer: This sits at the top, acting as the brain. It incorporates a review gate (for human oversight or automated quality checks) and establishes a logical hierarchy for tasks and agents. This layer defines the overall workflow and ensures tasks are delegated appropriately.
- Compute, Secrets, and Tools: These are the foundational resources that agents need to operate. The orchestrator doesn't care which specific machine provides the compute or how the secrets are stored, only that they are available and accessible.
- Scheduler: A crucial component that sits between the orchestrator and the resources. Its job is to assign tasks to specific machines based on agent needs, resource availability, and system policies. This mirrors how a company assigns tasks to employees based on their skills and current workload, rather than manually telling each employee which specific computer to use.
This model ensures that agents declare their needs (e.g., "I need a GPU, access to Git, and 16GB of RAM"), and the system intelligently handles the execution across available machines, abstracting away the underlying infrastructure details.
Solution 2: Leveraging Proven Infrastructure with Kubernetes
Rather than building a new infrastructure management system from scratch, Lee emphasized the importance of leveraging existing, battle-tested solutions. He specifically suggested building an "Orchestration Manager" on top of Kubernetes. Kubernetes, a powerful container orchestration platform, already excels at managing compute resources, secrets, and tools efficiently. It provides:
- Resource Management: Handles CPU, memory, and GPU allocation.
- Secret Management: Securely injects credentials and sensitive information.
- Tool Orchestration: Manages the deployment and lifecycle of various tools and services.
By integrating the Orchestration Manager with Kubernetes, developers can focus on defining agent logic and workflows, leaving the complex tasks of resource allocation, fault tolerance, and scaling to a proven platform. This approach allows for sophisticated task orchestration, streamlined review flow management, and robust context management, all while reusing existing, proven solutions for the underlying infrastructure.
Solution 3: Robust State Management for Shared Resources
Addressing the issues of memory exhaustion, state loss, and Git credential conflicts requires a deliberate strategy for managing agent state and shared resources:
- Separate Machine-Specific State: Any data or configurations specific to a particular machine should be isolated into per-machine directories. This prevents conflicts and ensures that a failure on one machine doesn't corrupt the state of others.
- Manage Shared State Through Pull Requests: For shared resources like Git repositories, the solution involves adopting a workflow akin to human collaboration. Instead of agents directly modifying shared repositories, they should propose changes via pull requests. This allows for a review process (either human or automated) and ensures that changes are merged cleanly, preventing conflicts and maintaining data integrity. This moves away from the problematic manual tracking of which agent runs on which machine and instead relies on a robust scheduler that can place tasks anywhere resources are available, with state managed in a distributed and version-controlled manner.
The Road Ahead for AI Agent Fleets
Kyle Jaejun Lee's insights from KRAFTON provide a critical roadmap for anyone venturing into the complex world of AI agent fleets. The transition from single-agent experiments to scalable, reliable multi-agent systems demands a shift in architectural thinking, moving from manual human coordination to sophisticated, automated orchestration. By embracing hierarchical design, leveraging powerful platforms like Kubernetes, and implementing robust state management strategies, developers can overcome the initial hurdles and build agent systems that truly deliver on their promise.
Lee concluded his presentation by inviting collaboration, emphasizing that many of the challenges he faced are still open problems in the field of AI agent orchestration. The journey towards truly autonomous and scalable AI agent fleets is ongoing, and sharing experiences and solutions will be key to collective progress. The lessons learned from KRAFTON's journey offer a valuable foundation for the entire AI engineering community to build upon.
Top comments (0)