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.

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
Contents(3)

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, 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. You may not republish this article in full without a license. Search engines and AI research tools may crawl and summarize for reference. Bulk reproduction or model training requires a license. See our terms.
Daniel Singer

Written by

Daniel Singer

Editor, StartupHub.ai

Daniel Singer is the editor of StartupHub.ai, a technology expert and thought leader on AI and its applications across sectors, from fintech and healthcare to developer tooling and consumer software. He writes and tests the tools covered here thoroughly and regularly, and built StartupHub.ai to give founders, operators and buyers a clearer read on what they are actually being sold.