There are two ways to organize the work of a company, and for a long time we only had language for one of them.
The first way: managers, staff, and admins. Someone owns a function. Someone coordinates the people in the function. Someone schedules, files, routes, approves, and remembers where the ball is. Coordination is headcount. Context lives in meetings, inboxes, and the three people who "just know." When the work gets bigger, you hire more layers so the layers can talk to each other.
The second way: orchestrators and sub-agents — and sub-agents that spin off more sub-agents — each carrying a different context window so the work stays narrow enough to be efficient and complete enough to be done. Coordination is architecture. Context is deliberate. When the work gets bigger, you do not automatically hire another manager. You split the job into agents that can finish a piece without dragging the whole company into every prompt.
I have lived inside both. The rebuild from 320 people to 38 was not only a smaller payroll. It was a different operating system for how work moves.
What the manager-staff-admin stack is optimized for
Be honest about why it existed. When cognition was expensive and software was rigid, humans were the flexible layer. Managers translated strategy into assignments. Staff executed the assignments. Admins kept the machine from forgetting itself. That stack built real companies — including mine, for years.
It is also optimized for a tax you stop seeing: every handoff leaks context. Every status meeting re-derives what the last meeting already knew. Every admin layer exists because the system cannot hold state. People become the database, the router, and the apology when the router fails. Your P&L still bills hours because the org chart is still the product.
What an orchestrator actually is
An orchestrator is not a chatbot with a fancy title. It is the layer that knows the outcome, breaks the work into parts, assigns those parts, and checks that the parts still aim at the same north. Humans can be orchestrators. Software can be orchestrators. The job is the same: hold the plan, spawn the work, refuse drift.
Under that orchestrator sit sub-agents — specialists. One owns research. One owns drafting. One owns QA. One owns the customer-facing reply. One owns the boring follow-up. When a job is too wide for a single context, a sub-agent spins off another sub-agent with a clean window for just that slice. That is not bureaucracy. That is how you keep a complex request from becoming one bloated brain trying to remember everything and doing nothing well.
This is the twin of intelligence over laminated playbooks: stop freezing judgment into a binder, and stop stuffing every judgment into one overloaded seat — human or model.
Why different context windows are the whole point
Efficiency is not "one agent that knows the company." Efficiency is the right context for the right job — and nothing extra. A wide window feels powerful and quietly makes the work worse: more noise, more contradiction, more two-degree drift that only shows up miles down the pipeline.
Specialized windows do three things managers' meetings rarely do on schedule:
- Scope the job. The agent sees what it needs to finish — not the entire org's anxiety.
- Finish the job. Narrow context is how you get to done instead of "still synthesizing."
- Protect the customer. Billing context does not bleed into marketing drafts. One customer's details do not ride along into another session because someone forwarded the wrong thread.
Humans need the same design. The SME inversion — encode the expert, then run the system — only works if the expert's knowledge is packaged for the job, not dumped into every room as folklore.
This is not "fire the humans"
I will not romanticize a company with no people. Orchestrators still need operators. Sub-agents still need owners who set the angle, the guardrails, and the human-in-the-loop where errors are expensive. The question is not whether humans matter. The question is whether you are paying humans to be the routing layer forever — or paying them to design, aim, and improve the routing layer.
Managers who only exist to re-explain the plan in standups are a symptom. Admins who only exist because the system cannot remember are a symptom. Staff who burn their best hours copying context between tools are a symptom. Treat the symptom with another hire and you grow the org chart. Treat it with orchestration and specialized agents and you grow capacity.
How to start building the second way
- Name the outcomes, not the seats. "Booked jobs reconciled daily" beats "we need another coordinator."
- Find the handoffs. Every place a human re-derives context is a candidate for an orchestrated pass — or a sub-agent with a clean window.
- Split wide jobs. If a request has five parts, do not force one brain — human or model — to hold all five. Spawn the parts. Check them against the plan.
- Keep a human where mistakes are expensive. Orchestration without accountability is just faster fiction.
- Measure finished work, not meeting volume. The org chart applauds activity. The operating system should applaud outcomes.
You can build a business around managers, staff, and admins — or around orchestrators and sub-agents that spin off sub-agents, each with a different context window so the work stays efficient and gets done. Same ambition. Different compound interest. One path grows coordination cost. The other grows finished work. Choose the operating system on purpose.