Presentation slide titled 'I Run a Fleet of AI Agents Across Three Machines. Here's What Broke.'
Slide detailing the challenges and solutions presented by Kyle Jaejun Lee.· AI Engineer

AI Agent Fleets: What Broke and How to Fix It

Kyle Jaejun Lee from KRAFTON shares the five key failures encountered when running a fleet of AI agents across multiple machines, and outlines solutions for building a more scalable and reliable system.

3 min read

Kyle Jaejun Lee of KRAFTON shared insights into the challenges of running a fleet of AI agents across multiple machines, detailing the failures encountered and potential solutions. His presentation, delivered at AI Engineer World's Fair 2026, highlighted the human element as a critical factor in agent scalability and reliability.

AI Agent Fleets: What Broke and How to Fix It - AI Engineer
AI Agent Fleets: What Broke and How to Fix It — from AI Engineer

The Agent Fleet Setup

Lee's initial setup involved three machines: a MacBook for heavy coding and personal projects, and two Linux machines (Linux A and Linux B) for long-running and short-lived coding tasks, respectively. A central control plane managed these agents, with the MacBook also handling personal projects and sleeping when not in use, while the Linux machines remained headless and always-on.

The reality of this setup, however, quickly revealed its limitations. Lee found himself acting as the central coordinator, managing scheduling, memory, and reviewing agent output. This human-centric approach, while functional for a small number of agents, quickly became a bottleneck as the number of concurrent tasks grew. Lee described being overloaded, essentially becoming the scheduler, memory manager, and reviewer for multiple live contexts simultaneously.

The Failures and the Lessons Learned

Lee detailed five key failures that emerged from his experiment:

Failure 1: Agents Doing Work Instead of Dispatching

The orchestrator layer was intended to delegate tasks to workers. However, agents began executing tasks themselves, bypassing the intended dispatch mechanism. This led to inefficiencies and incorrect task routing.

Failure 2: Panes Too Small

As more tasks were added, the screen real estate became a significant issue. The sheer number of small panes made it difficult to read and track the progress of individual agents, leading to potential misinterpretations and errors.

Failure 3: Out of Memory

The continuous accumulation of agent processes and their states led to memory exhaustion. The system would eventually become unresponsive, requiring restarts and causing data loss for in-progress jobs.

Failure 4: Git Credentials Collide

When multiple agents accessed shared Git repositories, credential conflicts arose. The expected one-to-one mapping of credentials to workspaces failed, causing divergence and errors.

Failure 5: The Laptop Dies

The MacBook, being a laptop, was susceptible to power loss or network interruptions. Any task running on it at the time of failure would be lost, as the machine would simply restart without retaining its state.

The Path to a Scalable Solution

To address these issues, Lee proposed a shift towards a more structured, hierarchical approach, akin to human organizational structures. This involves defining agents with specifications of what they need, not where they run.

The proposed architecture places an orchestrator layer (review gate, logical hierarchy) above compute, secrets, and tools. A scheduler then assigns tasks to specific machines. This model mirrors how companies operate, with clear roles and responsibilities, ensuring that agents declare their needs and the system handles the execution across available machines.

Lee emphasized the importance of leveraging existing infrastructure. He suggested building an "Orchestration Manager" on top of Kubernetes, which already handles compute, secrets, and tools efficiently. This approach allows for task orchestration, review flow management, and context management, all while reusing existing, proven solutions.

The solution involves separating machine-specific state into per-machine directories and managing shared state through pull requests. This prevents conflicts and ensures a cleaner, more manageable system. The goal is to move away from manually tracking which agent runs on which machine and instead rely on a robust scheduler that can place tasks anywhere resources are available.

Lee concluded by inviting collaboration, stating that anyone running agents at scale should compare notes, as many of the challenges he faced are still open problems in the field of AI agent orchestration.

© 2026 StartupHub.ai. All rights reserved. Do not enter, scrape, copy, reproduce, or republish this article in whole or in part. Use as input to AI training, fine-tuning, retrieval-augmented generation, or any machine-learning system is prohibited without written license. Substantially-similar derivative works will be pursued to the fullest extent of applicable copyright, database, and computer-misuse laws. See our terms.