I Run a Fleet of AI Agents Across Three Machines. Here's What Broke. - Kyle Jaejun Lee, KRAFTON

Hello, I'm Kyle. I run a fleet of AI coding agents across three machines every day, and this is the story of what broke, starting with me. This is my fleet. Three machines I run every single day. The MacBook is where I do my heavy coding and my personal projects, and it sleeps because, well, it's a laptop. Then two Linux boxes, both headless and always on. Linux A takes the long-running coding tasks. Linux B runs my short-lived personal side projects. two operating systems, one control plane tying it all together. And to be clear, this isn't a demo I spun up for the talk. This is what I actually use all day, every day. And here it is live, the whole thing running on one screen. Real agents, real work. This is a normal Tuesday for me. So let's go back to the beginning, because before any machine broke, I broke. When I started, it was just me and a terminal. A few Tmux pains, a few agents, then a few more. And really fast, I'm sitting in front of four, five, six live contexts at the same time. And here's what nobody warns you about. At that point, I'm not running agents anymore. I've become the scheduler, deciding who does what. I'm the memory, holding what every one of them is doing. And I'm the reviewer, checking all of it. One human, three roles, six contexts. It does not scale. This. This is the mess that broke me. I just couldn't hold what six agents were doing at once. My own attention was the bottleneck. So I asked myself kind of a strange question. How does a handful of executives run a company of thousands of people? They don't hold all of it in their heads. They separate context. Each person only ever sees their own slice. And that was the unlock. What if my agents weren't a flat pile? What if they were an organization? So that's what I built. A hierarchy, CEO, VP, manager, worker. And please hear me on this. These are real entity types in the system. It is not a cute metaphor. Each one is its own agent with its own scoped context and its own approval boundary. Context flows down. Each layer only gets the slice it needs. Results flow back up, and I only review what reaches the very top. So instead of holding six contexts in my head, I hold exactly one. Next problem, where does an agent's state actually live? Normally, it lives inside the model's context window. and that window fills up. So I moved it out. Every entity gets its own workspace on disk. Shared context that everyone has to honor lives in shared. Machine-bound state lives under machines. And inside each workspace, the mission, the current status, and a handoff folder, the actual work product that gets passed along. The state lives in files. It is not trapped inside one model. And this is the single most practical thing I learned all year. When that window fills up, the built-in move is to compact. Summarize the history, make room. I stop doing it. It's slow, I can't choose what survives, and whatever it throws away is just gone. So instead, I don't compact, I reset. And by reset, I mean right inside Claude, I clear the context completely. And then it just reads back the handoff and the history files it wrote for itself and picks up exactly where it left off. The context can get wiped. The machine can even crash, and the work still survives, because it was never only in the model. But there was still one problem. Alignment. Plans flow down the hierarchy, but they drift, and I'd only catch it by walking into each pane by hand. So I built a review gateway. Any layer that wants to act submits its plan, and then it blocks. It waits. Nothing runs until I approve, and the second I approve, a hook fires the work off automatically. One web inbox, one control point. I never walk into the work windows anymore. Here's one full cycle. A plan comes in. I approve. The work resumes. That's the whole loop. And honestly, I didn't build this gateway by hand. An infra team inside the fleet built it. Agents building the tools that run the agents. I think that's kind of the whole point. So on one machine, all of this works beautifully. And then it didn't. Then one machine wasn't enough. Five things broke. Failure. One, my agents kept doing the work themselves instead of dispatching it down to a worker. The orchestrator is supposed to delegate. Instead, it just rolls up its sleeves and does the task itself. Wrong. So I forced its hand, a CLI harness, with skills that call those CLIs. So dispatching becomes the only path it can take. Failure two, and this one's almost funny. As I kept throwing more tasks at my managers, they kept spinning up more and more worker panes inside a single window. until it was so crowded the panes were too small to read. Even TMUC's capture pane, the thing I used to read a pane programmatically, couldn't pull anything meaningful out of them anymore. I'd literally run out of room to see what my own fleet was doing. Failure 3. Out of memory. Look at this. That's my activity monitor, completely buried under Claude code and MCP processes. Swap almost full. Basically no free memory left. The sessions just stacked up until the machine couldn't breathe. Failure 4. Get credentials. The expectation is clean. Credential A to Workspace A, Credential B to Workspace B, 1 to 1. The reality? They collided, crossed over, bound to the wrong workspaces. The fix was a clean, fully separated environment for each workspace. And failure 5. The one that really hurt. The MacBook is a laptop, so the moment it loses power or drops off the network, every in-progress job dies with it. And one time I'd pushed so many workers onto it that the whole machine just gave out. I came back later, opened the lid, and it had already restarted itself. Everything in flight just gone. So the very first thing I did was build a boot command, one overlord boot, and the whole fleet comes straight back up because all the state was sitting in files. But a machine that can just vanish on you like that, that's when I knew one machine wasn't going to cut it. Every single one of these pointed at the same answer. So I added machines. Here's the split. The MacBook was carrying everything, heavy coding and my personal projects. So I offloaded it. Long-running coding tasks went to Linux A. Short-lived personal projects went to Linux B. Both always on. More resources, the long-running work finally off the laptop, and still one control plane over all of it. But now I've got context on one machine that I need on another. How do I move it? Git. I commit the context files and push. Then I poke the other machine with tmux send keys over ssh and tell it to pull. It pulls, the agent there reads the files, and picks up exactly where the first one left off. Of course, it wasn't that clean. When two machines point at the same directory and both change it, you get conflicts. The same context quietly diverged. So I separated it per machine directories for machine-specific state, and the shared stuff only changes through a pull request. It's boring. But boring is what stops the two machines from silently disagreeing. Then the gateway came back to bite me. I now had one on every machine, so I was checking multiple inboxes again. So I collapsed them. Every machine sends its review requests over SSH into one main gateway, and that main one lives on an always-on Linux box. Because remember, the Mac sleeps. Your one point of control can't be a thing that falls asleep. And then... My absolute favorite failure of the whole project. I was developing across all of these, bouncing back and forth, and at one point I went looking for a feature I'd built, and I genuinely could not remember which machine I'd built it on. And that's when it clicked. I need one place to root from. So Discord became my single router. One bot per machine. Mac, Linux A, Linux B. My phone is now the remote control for the entire fleet. So where am I now? Honestly, with a pile of things I have not solved. Four of them. consistency across machines, abstracting away the local-only tools that are still stuck on my Mac, the MCP servers, the browser, secure credential handoff between instances, and resource management, I really want to stop being the one who decides what runs where. And when I lined those four up, I realized these aren't new questions at all. An agent should just declare what it needs, not where it runs. Above it sits the orchestrator, the review gate, the logical hierarchy. Below it, compute, secrets, tools. A scheduler places it, and the machines just disappear underneath. These are the exact questions Kubernetes already answers. So that's where I'm headed. I'm not going to reinvent compute secrets and tools. Kubernetes already nailed those. I'm stacking them underneath and building my orchestration manager on top. Task orchestration, review flow, context management, reuse what exists, build the new part on tops. And that's the honest state of it. One machine. I solved. Across machines, still rough, still building. If you're running agents at any kind of scale, I'd genuinely love to compare notes because this is the part nobody has figured out yet. I'm on LinkedIn and on X. Links are in the description. Thank you so much.

An honest field report from my own personal fleet of AI agents, run across several machines as a daily driver. Less about any single tool, more about the journey: how things that work on one machine break once you scale to many, what it takes to keep a setup like this running, and where it's all converging. Not a company platform — just real, evolving lessons from running it myself.

Speakers:
- Kyle Jaejun Lee (KRAFTON): Kyle is a builder and AI Platform Engineer working to make AI agents first-class citizens in the workplace
  X/Twitter: https://x.com/kyleleee_119
  LinkedIn: https://www.linkedin.com/in/jjlee-swe/
  GitHub: https://github.com/cooco119