The Execution Layer Has Moved
Think about the last knowledge work role you filled, the most recent hire or open position on your team where the job was centered around producing things: research, analysis, first drafts, and structured documents. The implicit assumption in that hire was that execution capacity lives in people. That to get more done, you add more people who can do the work. Most organizations never chose that assumption — they inherited it. Which is part of why it rarely gets examined. But it has stopped being accurate, and the gap between the assumption and the current reality is widening every quarter.
I know this because I no longer work this way. The work I used to assign to specialists is now handled by a system I direct. I’m not augmenting my team with AI tools. The execution layer has moved.
What the Execution Layer Actually Is
When I say “execution layer,” I mean something specific: the layer of knowledge work where the doing happens. Research synthesis, first-draft document production, structured analysis — tasks that used to require a specialist with enough domain familiarity to do them with reasonable quality, and enough consistency that you could assign the work and come back to something finished.
Frontier models now handle that work at the open-ended end of the spectrum — work where a human reviews and refines the output, rather than checking every step along the way. That’s where the shift is real and the change is visible.
But it’s not true everywhere. For work with high verification costs, regulatory constraints, or liability exposure tied to individual outputs, the layer has moved more slowly or not at all — and pretending otherwise would let the most exposed executives assume this argument is about someone else’s team. It isn’t. The question is where on your team the work looks like the first category, not whether any of it does.
The distinction is the separation between execution and orchestration. Execution is doing the task. Orchestration is directing what gets done: setting the quality standard, choosing the right approach, evaluating what comes back and deciding whether it’s right. These two things used to be bundled in the same specialist. You hired someone who both knew how to do the work and would do it. Now they don’t have to be the same person — or even a person at all.
After running Compound long enough, my job changed in a way I hadn’t fully anticipated. The execution side moved into the system. The orchestration side got larger: what does this agent need to know to do this well, what should it produce, is what it produced actually right, what does the next step require. The amount of time I spend on orientation, evaluation, and redirection has grown. The amount of time I spend producing has collapsed. The directing stayed mine. The doing didn’t.
What You’re Building Capacity For
One person directing a well-designed agent system can now produce what previously required a team of specialists. That’s not an estimate about where AI is headed. It’s a description of how I operate today. If the roles you’re filling are still built around execution capacity, you are building for a configuration of knowledge work that doesn’t match how the work actually happens now.
The consequence lands on execution-capacity roles, and on the people in them. The seat is expensive, and the leverage from that seat is declining. That’s the uncomfortable part of the argument.
The real question isn’t whether the consequence lands there — it’s what you do with it. An organization that absorbs the shift and reinvests in orchestration capacity comes out with meaningfully more leverage. An organization that simply runs fewer people at the execution layer without building the orchestration side has made a cost decision, not a capability decision. Those two outcomes look similar on a headcount chart but very different in practice.
The more accurate frame for knowledge work output is headcount multiplied by how well that headcount is directed. An organization with strong orchestration (clear standards, well-designed systems, directors who can evaluate complex outputs and push back when something is wrong) can produce substantially more from a given headcount. An organization that treats headcount as the main lever for scaling knowledge work output is betting that the execution layer hasn’t changed. That bet gets more expensive over time.
Hiring for orchestration capacity looks different from hiring for execution capacity. It means hiring for domain expertise deep enough to set meaningful quality standards and for the judgment to evaluate outputs the person didn’t produce themselves. Those capabilities have always existed at the senior end of knowledge work roles. The difference is that those capabilities are now what makes someone valuable, at levels where producing the work used to be the main qualification — and producing the work is now what the system does.
The Bet You’re Already Running
Most organizations aren’t moving on this yet. And I want to be honest about why, because the real reason is harder than inertia. Orchestration capacity is genuinely scarce. The ability to define what good looks like, design a system that produces it, and evaluate outputs you didn’t generate yourself is not a skill most teams have in depth, because it wasn’t what determined who was good at their level until recently.
My own fluency in this mode was built over time, through the work of building and running Compound. It isn’t a natural consequence of being smart and competent in the old execution model. The people who were excellent at execution-level knowledge work are not automatically excellent at directing the systems that do it now.
That scarcity is actually the reason the structural bet matters. If orchestration capacity were easy to hire for, the advantage would evaporate quickly. It isn’t. The organizations that build it early and deliberately, by hiring for it and developing it in the people already there, will hold the advantage for longer than they would if this were a shift anyone could easily copy.
Waiting isn’t obviously wrong in the near term. Restructuring how roles are filled is genuinely costly, and there’s legitimate uncertainty about how far this capability extends across different kinds of work. But not deciding is still a decision. An organization that fills its next knowledge work role the way it filled roles three years ago is betting that the current configuration is still the right one for how the work actually happens today. That bet has a cost, and the cost grows the longer the structure runs on assumptions that stopped being accurate.
The organizations that get the orchestration layer right first won’t just produce more output with the same people. They’ll have fundamentally different leverage, and the gap between those organizations and the ones still adding execution capacity for tasks the system can already handle will be visible by the time most people think to look.
The question worth asking isn’t whether AI will eventually change how your teams work. It already has. The question is whether the roles on your team right now are built for the work as it is, or for the work as it was before the execution layer moved — and whether your next hire closes that gap or widens it.
