Speaker A
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.
Kyle Lee shares his experience managing a fleet of AI coding agents across three machines, detailing failures and solutions for scaling and control.
Key Takeaways
- Scaling AI agent fleets requires hierarchical organization to reduce human cognitive load.
- Persisting agent state externally on disk improves reliability and recovery over in-model context compaction.
- Centralized plan approval gateways enable better alignment and automation.
- Multi-machine orchestration demands careful state synchronization and conflict resolution.
- Unified control interfaces like Discord bots can simplify managing distributed AI agents.
Summary
- Kyle runs a fleet of AI coding agents on three machines: a MacBook and two Linux boxes, managing long and short-running tasks.
- Initially overwhelmed by managing multiple agent contexts, he created a hierarchical agent organization with CEO, VP, manager, and worker roles.
- He externalized agent state from model context windows to disk files to avoid slow and lossy context compaction.
- Built a review gateway to approve plans before execution, automating control and reducing manual oversight.
- Encountered multiple failures including improper task delegation, overcrowded tmux panes, memory exhaustion, credential collisions, and machine instability.
- Offloaded tasks from the MacBook to Linux machines to improve resource allocation and reliability.
- Implemented Git-based context syncing and conflict management across machines with per-machine directories and pull requests.
- Consolidated multiple review gateways into a single always-on control point to simplify management.
- Used Discord as a unified remote control interface with one bot per machine for fleet coordination.
- Currently working on solving consistency, handoff abstraction, and resource management challenges, aiming to leverage Kubernetes for infrastructure.
Chapters
- 00:00Introduction and Setup of AI Agent Fleet
- 00:32Real-World Usage and Initial Challenges
- 00:53Overwhelmed by Multiple Agent Contexts
- 01:28Building a Hierarchical Agent Organization
- 01:59Externalizing Agent State to Disk
- 02:43Implementing a Review Gateway for Alignment
- 04:00Failures Encountered on Single Machine
- 06:09Scaling to Multiple Machines and Syncing State
- 07:05Consolidating Control and Using Discord as Router
- 08:06Current Challenges and Future Directions
Full Transcript — Download SRT & Markdown
Speaker A
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
Speaker 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.
Speaker A
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.
Speaker A
And here it is live, the whole thing running on one screen. Real agents, real work. This is a normal Tuesday for me.
Speaker A
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.
Speaker A
A few tmux panes, 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.
Speaker A
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 is the mess that broke me.
Speaker A
I just couldn't hold what six agents were doing at once. My own attention was the bottleneck.
Speaker A
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.
Speaker A
And that was the unlock. What if my agents weren't a flat pile? What if they were an organization?
Speaker A
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
Speaker A
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.
Speaker A
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.
Speaker A
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.
Speaker A
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 stopped doing it. It's slow. I can't choose what survives. And whatever
Speaker A
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
Speaker A
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.
Speaker A
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
Speaker A
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.
Speaker A
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.
Speaker A
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.
Speaker A
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.
Speaker A
So I forced its hand. A CLI harness with skills that call those CLIs. So dispatching becomes the only path it can take.
Speaker A
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 tmux
Speaker A
capture pane, the thing I used to read a pane programmatically, couldn't pull anything meaningful out of them anymore.
Speaker A
I'd literally run out of room to see what my own fleet was doing. Failure three, out of memory. Look at this. That's my activity monitor, completely buried under cloud code and MCP processes. Swap almost full.
Speaker A
Basically no free memory left. The sessions just stacked up until the machine couldn't breathe.
Speaker A
Failure four, get credentials. The expectation is clean. Credential A to workspace A, credential B to workspace B, one to one. The reality, they collided, crossed over, bound to the wrong workspaces. The fix was a clean, fully separated environment for each
Speaker A
workspace. And failure five, 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
Speaker A
just gave out. I came back later, opened the lid, and it had already restarted itself. Everything in flight just gone.
Speaker A
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
Speaker A
knew one machine wasn't going to cut it. Every single one of these pointed at the same answer. So, I added machines.
Speaker A
Here's the split. The MacBook was carrying everything, heavy coding and my personal projects. So, I offloaded it.
Speaker A
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.
Speaker A
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
Speaker A
pull. It pulls, the agent there reads the files, and picks up exactly where the first one left off.
Speaker A
Of course, it wasn't that clean. When two machines point at the same directory and both change it, you get conflicts.
Speaker A
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.
Speaker A
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
Speaker A
always-on Linux box because, remember, the Mac sleeps. Your one point of control can't be a thing that falls asleep.
Speaker A
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
Speaker A
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.
Speaker A
Mac, Linux A, Linux B. My phone is now the remote control for the entire fleet.
Speaker A
So, where am I now? Honestly, with a pile of things I have not solved. Four of them. Consistency across machines, abstracting away
Speaker A
handoff between instances, and resource management. I really want to stop being the one who decides what runs where.
Speaker A
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,
Speaker A
compute, secrets, tools. A scheduler places it, and the machines just disappear underneath. These are the exact questions Kubernetes already answers.
Speaker A
So, that's where I'm headed. I'm not going to reinvent compute, secrets, and tools. Kubernetes already nailed those.
Speaker A
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.
Speaker A
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
Speaker A
yet. I'm on LinkedIn and on X. Links are in the description. Thank you so much.
Topics:AI agentsagent orchestrationdistributed computingmachine managementstate persistencetask delegationhierarchical agentstmuxGit synchronizationremote control
