A personal field report on running a fleet of AI agents across three machines as a daily driver, presented by Kyle Jaejun Lee (KRAFTON). Focuses on the operational journey rather than any single tool: failures that appear when scaling from one machine to many, the maintenance required to keep a multi-machine agent setup running, and where the practice appears to be converging. Framed as individual lessons learned, not a company platform. # Channel Presentation Observations ## Video Identity - **Title:** "I Run a Fleet of AI Agents Across Three Machines. Here's What Broke. - Kyle Jaejun Lee, KRAFTON" - **Speaker self-identification:** > "Hello, I'm Kyle." - **Affiliation (from title):** KRAFTON — indicates the speaker is presenting under a professional/organizational identity. - **Format evidence:** The transcript structure (opening introduction, staged narrative, closing "Thank you so much") strongly resembles a **conference or meetup talk**, though this is presentation evidence, not a confirmed venue. ## Explicit Self-Description - **Daily practitioner claim:** > "this isn't a demo I spun up for the talk. This is what I actually use all day, every day." - **Role claim:** > "I run a fleet of AI coding agents across three machines every day" - **Current-state honesty claim:** > "that's the honest state of it. One machine, I solved. Across machines, still rough, still building." ## Intended Audience - **Practitioners running AI agents at scale**, directly addressed: > "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." - **Assumed technical background** in the audience: talk moves without explanation through tmux, SSH, Git workflows, MCP servers, Kubernetes, and Claude context management. ## Claimed Scope of Content - **Multi-machine AI agent orchestration**: hierarchy design (CEO/VP/manager/worker), file-based state management, review gateways, failure post-mortems, and a stated future direction toward Kubernetes. - **Failure-first framing**: the title and five enumerated "Failure" items position the channel's content around **what broke and how it was fixed** rather than polished success stories. ## Observable Presentation Patterns - **Transparency about unsolved problems:** lists four open issues explicitly (consistency across machines, local-only tools, credential handoff, resource management). - **First-person experiential style:** every point is anchored to personal experience ("my fleet," "my absolute favorite failure"). - **Community engagement:** > "I'm on LinkedIn and on X. Links are in the description." — indicates active audience outreach channels. - **Named tooling demonstrated live:** Claude, tmux, Git, Discord bots — concrete stack disclosure rather than abstraction. ## Claims vs. Demonstrated Evidence | Type | Example | |---|---| | **Creator claim** | "This is what I actually use all day, every day" — unverifiable from transcript alone | | **Demonstrated** | Detailed, specific failure accounts (pane crowding, swap exhaustion, credential collisions, machine restart) showing sustained hands-on operation | | **Honesty framing** | Explicit admission of incomplete solutions and invitation to compare notes with peers | # Delivery Observations: Kyle Jaejun Lee, KRAFTON ## Tone & Register - **Conversational, first-person narrative style** throughout — a personal retrospective framed as a story: *"this is the story of what broke, starting with me."* - **Candid, self-deprecating framing** of his own failures, without dropping into casual filler-heavy speech; the delivery stays structured. - Direct address to the audience: *"And please hear me on this."* ## Structure & Teaching Habits - **Numbered failure enumeration** as the core organizing device: *"Five things broke. Failure. One… Failure two… Failure three… Failure four… failure five."* Later mirrored with *"Four of them."* - **Problem → insight → fix pattern** repeated consistently (attention bottleneck → hierarchy; context fill → files on disk; drift → review gateway). - **Problem-solution pivots via rhetorical questions:** *"So, I asked myself kind of a strange question. How does a handful of executives run a company of thousands of people?"* - **Explicit "where am I now" recap** near the end: *"So, where am I now? Honestly, with a pile of things I have not solved."* ## Recurring Phrases & Verbal Tics - **"So," as a sentence opener** — very frequent: *"So, let's go back… So, I moved it out… So, I built a review gateway… So, I forced its hand… So, I added machines."* - **"And" chaining** to build momentum across clauses: *"And that was the unlock… And this is the single most practical thing I learned all year."* - Repeated emphasis device **"this is / it is" + strong claim**: *"It is not a cute metaphor," "This is a normal Tuesday for me," "It's boring, but boring is what stops…"* ## Vocabulary & Framing Choices - **Anthropomorphic/organizational vocabulary** for the agent system: *"CEO, VP, manager, worker," "the orchestrator," "rolls up its sleeves."* - Short, punchy declaratives for emphasis: *"It does not scale," "Real agents, real work," "Wrong."* - **Concrete tool names** used freely rather than abstracted: tmux, `tmux send-keys`, `tmux capture pane`, Git, SSH, Kubernetes, MCP, Claude, Discord. ## Emphasis & Signposting Techniques - **Contrast pairs (expectation vs. reality):** *"The expectation is clean… The reality, they collided, crossed over…"* - **Superlative flags to direct attention:** *"the single most practical thing I learned all year," "my absolute favorite failure of the whole project," "the one that really hurt."* - **Anti-metaphor disclaimer** to establish credibility: *"These are real entity types in the system. It is not a cute metaphor."* ## Closing Habits - **Honest-status summary plus open invitation:** *"And that's the honest state of it. One machine, I solved. Across machines, still rough, still building."* Followed by a call to connect: *"I'd genuinely love to compare notes… I'm on LinkedIn and on X."* ## Uncertainty Notes - Timestamps in the transcript are coarse segment markers, not reliable for precise delivery timing claims; timing-based observations (pacing, pauses) cannot be made from this source. - No curated metadata was present, so delivery context beyond the transcript is unavailable. # Position Record: "I Run a Fleet of AI Coding Agents Across Three Machines" **Speaker:** Kyle Jaejun Lee (KRAFTON), identified via video metadata; self-identified as "Kyle" in transcript. ## Setup - Runs a **fleet of AI coding agents** across **three machines daily** — framed not as a demo but as his actual daily setup. - **MacBook:** heavy coding, personal projects; sleeps because it's a laptop. - **Linux A:** headless, always-on, long-running coding tasks. - **Linux B:** headless, always-on, short-lived personal side projects. - One control plane ties the machines together. ## Core Position: The Human Became the Bottleneck - Starting with tmux panes and a few agents, he quickly faced **four to six live contexts at once**. - His stated claim: at that point *"I'm not running agents anymore"* — the human becomes **scheduler, memory, and reviewer** simultaneously. - Conclusion: **one human, three roles, six contexts "does not scale."** ## The Hierarchy Solution - Inspired by asking how executives run large companies: **they don't hold everything in their heads; they separate context.** - Built a hierarchy — **CEO, VP, manager, worker** — which he insists are **"real entity types in the system, not a cute metaphor."** Each entity is its own agent with scoped context and its own approval boundary. - Context flows down (each layer gets only its slice); results flow up; he reviews only what reaches the top. ## State in Files, Not Context Windows - Agent state normally lives in the model's context window, which fills up. - His fix: every entity gets a **workspace on disk** — shared context, machine-bound state, mission, status, and a **handoff folder**. - Claims this is **"the single most practical thing I learned all year."** - **Rejects compaction** (built-in summarization): "It's slow. I can't choose what survives. And whatever it throws away is just gone." - **Instead: reset** — clear context entirely in Claude, then the agent re-reads its own handoff/history files and resumes. Work survives context wipes and machine crashes because "it was never only in the model." ## Review Gateway - Problem: plans flowing down the hierarchy **drift**, and he could only catch drift by manually checking each pane. - Fix: any layer wanting to act **submits a plan and blocks** until he approves; approval fires a hook automatically. - Result: one web inbox, one control point — "I never walk into the work windows anymore." - Notes the gateway itself was built by **an infra team inside the fleet**: "Agents building the tools that run the agents." ## The Five Failures (Single Machine) 1. **Orchestrators did the work themselves** instead of delegating. Fix: a CLI harness with skills so dispatching is the only available path. 2. **Pane overcrowding:** managers spun up too many worker panes until tmux capture-pane couldn't extract meaningful content. 3. **Out of memory:** activity monitor buried under Claude Code and MCP processes; swap nearly full. 4. **Git credential collisions:** credentials bound to wrong workspaces despite one-to-one intent. Fix: fully separated environments per workspace. 5. **MacBook fragility (the one "that really hurt"):** power/network loss killed in-progress jobs; once the machine gave out and restarted itself, everything in flight gone. - Response to failure five: built a **boot command** (`overlord boot`) that restores the whole fleet from file state — and concluded **one machine wasn't enough**. ## Multi-Machine Architecture - Offloaded the MacBook: long-running tasks → Linux A, short-lived projects → Linux B. - **Context transfer via Git:** commit context files, push, then poke the other machine with **tmux send-keys over SSH** to pull and resume. - **Conflict problem:** two machines changing the same directory caused silent divergence. Fix: per-machine directories for machine-specific state; shared state changes only via pull request — "boring, but boring is what stops the two machines from silently disagreeing." - **Gateway consolidation:** one gateway per machine meant multiple inboxes again; collapsed into one main gateway on an always-on Linux box — **"your one point of control can't be a thing that falls asleep."** - **Discord as single router:** one bot per machine; his phone becomes the remote control. Motivated by genuinely forgetting which machine a feature was built on. ## Unsolved Problems (Stated Honestly) Four open issues, explicitly framed as unresolved: - **Consistency across machines** - **Abstracting away local-only tools** stuck on the Mac (MCP servers, the browser) - **Secure credential handoff** between instances - **Resource management** — he wants to stop deciding what runs where ## Forward Direction: Kubernetes - Claims these four questions are "the exact questions Kubernetes already answers." - Position: an agent should **declare what it needs, not where it runs**; a scheduler places it; "the machines just disappear underneath." - He does **not** intend to reinvent compute, secrets, and tools — reuse Kubernetes underneath and build orchestration (task orchestration, review flow, context management) on top. ## Overall Claim Status - **Settled (per his account):** single-machine operation. - **Unsettled:** cross-machine operation — "still rough, still building," and "the part nobody has figured out yet." - Closes with an invitation to compare notes via LinkedIn and X. # Speaker Attribution & Provenance Record ## Video **Title:** I Run a Fleet of AI Agents Across Three Machines. Here's What Broke. - Kyle Jaejun Lee, KRAFTON **Video ID:** `01a15ca8-b158-7e45-a784-9feb5feb9e7d` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Kyle (Kyle Jaejun Lee)** | **Sole speaker — creator/presenter**, identified with KRAFTON per title | Self-introduction: *“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.”* | - No other human speakers; no narrator, guest, or interview segments appear in the transcript. ## Referenced Systems & Tools (Provenance of Claims) All claims are first-person experience reports from the speaker; no third-party sources are cited. - **Claude** — context-clearing/reset behavior described (*“right inside Claude, I clear the context completely”*) - **tmux** — panes, `capture pane`, `send-keys` over SSH - **Git** — context-file transfer between machines - **Discord** — single-router bot, one per machine - **Kubernetes** — cited as the model for compute, secrets, and tools orchestration (*“Kubernetes already nailed those”*) - **MCP servers / cloud code processes** — referenced in memory-failure and unsolved-problems sections - **LinkedIn and X** — speaker's stated contact channels (*“Links are in the description”*) ## Promotional Segments - **None flagged.** Closing invitation to connect (*“I'm on LinkedIn and on X. Links are in the description”*) is self-promotional contact info, not a promotional segment for a product or sponsor. ## Third-Party Claims - **None.** All failures, fixes, and architectural claims are the speaker's own firsthand account. ## Availability & Limitations - **Comments:** Not indicated in transcript or metadata — availability **unknown**. - **Curated metadata:** Not supplied; speaker identity rests on the self-introduction and title attribution only. - **Live demo:** Speaker asserts the fleet shown is real daily usage, not a staged demo (*“this isn't a demo I spun up for the talk”*) — asserted, not independently verifiable. 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 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. 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 stopped 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 tmux 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 three, out of memory. Look at this. That's my activity monitor, completely buried under cloud code and MCP processes. Swap almost full. Basically no free memory left. The sessions just stacked up until the machine couldn't breathe. 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 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 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.