Systems
A three-tier delegation tree, coordinators that never touch code, and a headcount that is a config value, not a hiring plan.
The org chart has three tiers and one human. Me on top, a coordinator layer under me, and a floor of workers under that. No HR, no org chart software, no headcount plan, no annual review cycle. Just a delegation tree that gets taller when the work does and shorter the moment it is done, redrawn as often as the work requires it.
Here is the actual shape of it. I sit at the top. Below me is a standing coordinator I think of as the brain of the operation. Below that are tier-two coordinators, one per major initiative. Below them are tier-three workers, the agents that actually touch files. The rule that makes the whole tree hold together is one sentence: coordinators do not write product code. They delegate, they verify, and they report. The instant a coordinator starts editing files instead of assigning them, the tree collapses into one confused layer and you have lost the thing a tree is for.
That rule sounds bureaucratic until you watch what it replaces. In a normal company, a coordinator who cannot personally ship is dead weight unless they are good at people. In this company, a coordinator that cannot personally ship is the entire point, because its only job is to see the whole board, split the work correctly, and catch a worker lying about being done. It is middle management with none of the politics and all of the actual function.
The clearest proof I have that this scales is a rename. We needed to replace every reference to our old CLI name with the new one across a codebase that had absorbed a year of history — thousands of call sites, docs, config keys, fallback paths for existing installs. In a normal company that is a quarter of someone's life. Here it was one instruction to a workflow: spawn twenty-four agents, exhaustively finish the rename, preserve legacy fallbacks only where required for existing installs, run regression tests plus CI-equivalent checks, secret scan, conventional commits with explicit pathspecs, push to both remotes, report exact root causes and remaining CI state. Twenty-four workers, one coordinator watching the board, zero meetings.
Architecture decisions get the same treatment, minus the meeting room. When a real design question came up — whether a piece of infrastructure should be its own product or fold into an existing one — I did not put six people in a room for an hour. I dispatched twelve read-only reviewers across two model tiers, six roles each, and required every one of them to post an evidence-backed report to a shared channel, including the strongest argument against their own recommendation. Then a second round: each reviewer reads the others and posts a rebuttal or an agreement. That replaced an architecture committee with a structured argument between machines, and it left a paper trail no meeting ever produces.
QA works the same way. When Alumia needed every page and every action verified in the browser, the answer was not a QA team, it was eight parallel adversarial agents, each one owning a section, each one tied to the same shared plan so nobody duplicated work and nobody's findings got lost between people. A human QA team would have needed a stand-up to divide that work. The agents divided it because the plan itself was the assignment sheet.
None of this is unlimited. Concurrency is capped, and the cap is policy, not accident — a number I tune the same way a CEO would adjust headcount, except I do it by editing one line in a rules file instead of signing a budget request. I have run that cap at two, then raised it to six, then blown past the rule entirely and run sixteen when a task needed the throughput. The org chart's actual size is a variable in a config, live, reversible, with no severance and no notice period.
What replaces headcount is not a one-to-one swap of agent for employee. It is the removal of the concept. A company used to scale by hiring: more people, more desks, more of the coordination tax that comes with more people. This one scales by spinning up more tiers of the same delegation tree for the duration of the work and letting them fold back down when it is done. The 'team' for the rename was twenty-four workers for one day. The 'team' for the architecture question was twelve reviewers for one afternoon. Nobody needed onboarding. Nobody needed to be let go.
The agents are not anonymous either, and that matters more than it sounds. They have names — mostly Roman, Marcus, Cicero, Seneca, Cato — and roles that persist: Marcus is the senior architect who designs before he ever touches code, and he is the same Marcus next week. That continuity is what makes a fleet feel like staff instead of a pile of disposable API calls. You do not manage headcount when you manage a fleet. You manage personas with track records.
Reporting replaces the standup. When I hand a coordinator a standing duty — own this subsystem, post one digest, do not spam the channel — the follow-up is always the same demand: did you actually post it, and if so, give me the message ID. Not a status meeting, not a green checkmark someone half-believes. A specific, checkable artifact that either exists or does not. That is a performance review that takes four seconds and cannot be talked around.
Performance review for the whole tree runs on a sweep instead of a calendar. A recurring check classifies every pane on every machine into one of five states — working, idle-done, stuck, errored, or blocked on account usage — with a standing instruction attached to it: verify everything, never trust an agent self-report. That sweep is the only headcount audit that ever happens here, and it runs every few minutes instead of once a year.
Even headcount capacity is a resource allocation problem, not a hiring problem. I run sixteen or seventeen subscription profiles across the fleet at once, because a coding subscription is not a seat assigned to a person, it is a unit of compute assigned to whichever agent needs it next. Scaling the company up for a week of heavy work means adding profiles and raising the concurrency cap, not posting a job listing and waiting six weeks for someone to give notice at their old job.
There is a taxonomy for escalation too, the same way a real company has an incident channel separate from general chat. The Telegram bridge that connects me to the fleet has a coding channel, a divisions channel for the different lines of work, a reports channel, and something closer to a fire alarm for anything that needs eyes right now. The org does not treat every message with the same urgency, even though every message comes from the same tree.
The tree also has a rule that looks like it contradicts the veto I described earlier, and the contradiction is the design. The default posture for every worker is bias entirely toward doing the work — take actions, not questions, no exceptions. Agents do not get to sit idle asking for permission on routine calls. The veto only fires when a worker jumps ahead of an explicit decision I have not made yet, like starting to build something I only asked to discuss. Default to action, escalate on scope. Those two rules together are the entire management philosophy.
Humans still stay in the loop, and the loop is narrower than people expect: taste and scope, not execution. An agent that jumps straight to building something I only asked about gets stopped hard, in writing, every time — undo what you did, we need to discuss this further, stop, talk to me first. That brake exists precisely because the delegation tree is fast. Fast execution without a human veto on scope is not leverage, it is a company sprinting in a direction nobody chose.
The other place I stay in the loop is the boundary between deciding what and deciding how. I will tell a coordinator the outcome I want and leave the implementation entirely to it — you decide the approach, but keep it scalable — because the how is exactly the layer that should not require me. The what is the layer that should always require me, because that is the only decision in the whole tree that an org chart cannot make on my behalf.
Even the act of telling a worker what to do gets verified, because a delegation tree is only as good as its worst-delivered instruction. Prompts get routed to a worker's pane, and the router does not assume the message landed just because it was sent — it diffs the pane before and after to confirm the instruction actually arrived and was submitted. A manager who cannot confirm an instruction was received is not managing. In a company this small, a dropped instruction is not an inconvenience, it is the whole day gone.
The old startup mythology chased the mythical ten-times hire, the one person worth an entire team. This tree does not need that person, because it does not need any one node to be exceptional. It needs the split between tiers to be exact — coordinators that only coordinate, workers that only execute, evidence that only counts once it survives a check — and it needs that split enforced without exception, every single time, by a rule instead of a manager's mood that day.
People ask what happens when the fleet disagrees with itself, since twelve reviewers arguing in a channel can produce twelve opinions. It resolves the same way a real decision should: with evidence, not seniority. A worker's claim that a task is done is worth nothing until it survives a coordinator's check, and a coordinator's recommendation is worth nothing until it survives a rebuttal round. Nobody in the tree gets to pull rank. Only proof does.
A solo founder before any of this existed had exactly one lever: work more hours than everyone else and hope the math worked out. That lever tops out fast, because a day only has so many hours in it and a body only has so much attention. The delegation tree removes the ceiling without adding a single person, because the tree's hours are not my hours. It runs while I sleep, reports in the morning, and only wakes me up for the decisions that were always mine to make.
This is the part that took me longest to believe: a company with one human at the top is not a company missing ninety-nine employees. It is a company that never needed the coordination overhead ninety-nine employees generate in the first place. The tree does the coordinating. I do the deciding. That split is the whole company.
Ask me what my headcount is and I will tell you the truth: one, plus however many the current task requires, for exactly as long as it requires them.