A flat group of coding agents made Kyle the scheduler, memory, and reviewer, so he organized them into a hierarchy with scoped context and approval boundaries.
2
Moving agent state into files made resets, machine crashes, and restarts recoverable because the work was not trapped in a model context window.
3
Scaling across machines exposed failures in dispatch, pane capacity, memory, credentials, power, synchronization, and control, leading Kyle toward Kubernetes underneath a custom orchestration layer.
Summary
Kyle Jaejun Lee describes running AI coding agents across a MacBook and two always-on Linux machines. His first problem was human attention: six flat agent contexts turned him into the scheduler, memory, and reviewer. He built a hierarchy of CEO, VP, manager, and worker agents, with scoped context and approval boundaries. He also moved state into workspace files, using handoffs and resets instead of model-context compaction. Scaling beyond one machine exposed practical failures. Agents did work themselves instead of delegating, tmux panes became unreadable, cloud code and MCP processes exhausted memory, credentials crossed workspace boundaries, and the MacBook lost work when it slept or restarted. Git, SSH, per-machine directories, pull requests, and a centralized review gateway helped connect the fleet. Discord became the router for three machine-specific bots. Lee is now considering Kubernetes for scheduling compute, secrets, and tools, while keeping task orchestration, review flow, and context management in his own layer.
A flat fleet made one person carry every agent's context
Kyle began with terminal panes and quickly reached four, five, and six live agent contexts. He was deciding what each agent should do, remembering what each one was doing, and reviewing all of their output. He compares those three responsibilities to a scheduler, memory, and reviewer. His attention became the bottleneck, and he could not keep the fleet in his head. This led him to separate context between agents instead of treating them as one flat pile. The problem was operational rather than model-specific: the setup failed because one human had to coordinate every active context.
The hierarchy limits each agent to the context and authority it needs
Lee built a real hierarchy with CEO, VP, manager, and worker entities. Each level is its own agent with scoped context and an approval boundary. Plans move down the hierarchy, while results move back up. Each layer receives only the slice it needs, so Lee reviews what reaches the top instead of entering every work window. He stresses that these are actual entity types in the system, not labels for a loose organizational metaphor. The hierarchy reduces the human's working load from six active contexts to one top-level context.
File-based state lets agents recover through resets and crashes
Agent state normally sits in the model's context window, which eventually fills. Lee gives every entity a workspace on disk. Shared state goes in a shared area, machine-bound state goes under machines, and each workspace contains a mission, current status, and handoff folder. When the context fills, he resets the Claude context instead of compacting it. The agent then reads its handoff and history files and continues. Because the work is stored in files, a wiped context or crashed machine does not erase the work that had already been written.
A review gateway stops plans until a human approves them
Plans can drift as they move down the hierarchy, so Lee built a review gateway. Any layer that wants to act submits a plan and blocks until approval. Once he approves it, a hook starts the work automatically. The process uses one web inbox and one control point, which means he no longer has to walk into individual panes. Lee says an infrastructure team inside the fleet built this gateway, so agents created part of the tooling used to run the agents. The loop is simple: a plan arrives, he approves it, and the work resumes.
One machine exposed five different scaling failures
The single-machine setup failed in several ways. Orchestrators performed tasks themselves instead of dispatching them, so Lee made delegation the only path through a CLI harness and skills that call the CLIs. Managers created so many worker panes that they became unreadable, and tmux capture pane could no longer return useful output. Cloud code and MCP processes consumed memory until swap was almost full. Credentials crossed workspace boundaries instead of staying one-to-one. Finally, the MacBook lost in-progress work when it lost power, dropped off the network, or restarted under too much load.
Multiple machines need explicit state boundaries and a single gateway
Lee moved long-running coding tasks to Linux A and short-lived personal projects to Linux B, leaving the MacBook for heavy coding and personal work. To move context, he commits files with Git, pushes them, sends keys to the other machine over SSH, and tells the remote agent to pull. Shared directories caused silent divergence when two machines changed the same state, so he separated machine-specific directories and allowed shared changes through pull requests. He also routed review requests from every machine into one gateway on an always-on Linux box, because the MacBook sleeps.
As Lee moved between machines, he eventually forgot where a feature had been built. He chose Discord as one place to start from, with one bot for the MacBook, Linux A, and Linux B. His phone became the remote control for the fleet. This is separate from the review gateway: the gateway centralizes approvals, while Discord routes him to the machine where work is running. The arrangement gives him one visible entry point even though the agents and their state are spread across three machines.
The next layer should schedule agents over infrastructure that already exists
Lee still has unresolved problems with consistency, Mac-only tools such as MCP servers and the browser, secure credential handoff, and resource management. He wants agents to declare what they need instead of specifying where they run. In his proposed structure, an orchestrator, review gate, and logical hierarchy sit above compute, secrets, and tools. A scheduler places the agent, while the machines become an implementation detail. He sees Kubernetes as an existing answer for compute, secrets, and tools, and plans to build task orchestration, review flow, and context management above it.
"The context can get wiped, the machine can even crash, and the work still survives because it was never only in the model."02:56
Who should watch
You are running several coding agents and keep switching between panes, tasks, and review decisions yourself.
Your agents need to survive context resets, crashes, laptop sleep, or movement between machines.
You are designing an agent platform and need concrete failure modes around dispatch, credentials, state synchronization, and scheduling.
