The Compression Thesis

Most executives have already run an AI pilot inside a team that never changed shape. The model got faster at drafting, summarizing, or answering; the org chart, the approval chain, and the handoff count underneath it did not move. Months later the pilot produced a nice demo and no line on the P&L. That is not a rollout problem you fix with more training or a better vendor. It is a design problem, and it traces back to the question the first era of enterprise AI asked.

That question was: same organization plus AI equals what? Mostly, it turned out to equal disappointment. MIT's NANDA initiative found that roughly 95 percent of generative AI pilots deliver no measurable P&L impact. Not because the models are weak. Because the organization surrounding the model was never redesigned to use the capacity the model actually created, so the capacity leaked out as slightly faster versions of the same slow process.

The right question is structural, not technical: if AI had existed when this organization was designed, how small would the team be that owns this outcome, and what would it look like? That is the compression thesis, and it is not a slogan you put on a slide. It is arithmetic you can run on a whiteboard, and this lesson works through why the bolt-on approach caps out for reasons that are structural, then what to build instead.

The coordination arithmetic

Coordination cost does not grow with headcount; it grows with the number of possible links between people, and that grows as n(n-1)/2. A team of seven has 21 possible communication links. A team of 25 has 300. Double the headcount from seven to fourteen and you do not double the coordination load, you nearly quadruple it. Surveys of knowledge workers consistently put close to 60 percent of a typical day into exactly this kind of overhead: status updates, meetings to align on what a meeting already covered, documents written mainly to inform people who were not in the room, and handoffs that exist only because a task crosses a team boundary.

This is what makes agents a structural event rather than a productivity feature. An agent that carries context between two people, drafts the status update nobody wanted to write, and tracks a hand-off until it is actually complete is absorbing coordination work directly, the same category of work that made large teams necessary in the first place. Call this the Compression Curve: as agents take on a growing share of the coordination load, the minimum team size that can still own a whole outcome end to end falls, and it falls faster than the link count would suggest, because the links that disappear first are the expensive ones, the ones that used to require a person.

Why bolt-on AI caps out structurally

Here is the trap most enterprise AI programs fall into. A well-known way to frame any technology investment is roughly 10 percent technology, 20 percent data and algorithms, 70 percent people and process. Bolt-on AI, by construction, only touches the first ten. The tool goes into the existing process, at the existing handoff points, worked by the existing team, reporting through the existing approval chain. The 70 percent, the part where the actual return lives, never gets touched, because touching it means changing who does what and who decides what, and that is precisely the part a tool rollout is designed not to disturb.

This is why the first era's framing was backwards. "Same organization plus AI" treats the organization as fixed and the AI as the variable. But the organization is not fixed; it was designed around a set of constraints, chiefly the coordination cost of coordinating knowledge across many specialists, that AI now relaxes. Holding the organization fixed and adding AI on top is optimizing the one variable that was never the actual bottleneck.

The reframe follows directly from the arithmetic: build a tiny version of the organization that would exist if AI had always been available, prove it against a real, measurable outcome, and only then decide how the rest of the organization should change around what was proven. You are not asking the existing org to adopt a tool. You are building the smaller unit the tool makes viable, and letting its results make the case the tool alone never could.

The Executive Lens (Where the Ninety Days Go)

If bolt-on AI caps out and a full reorganization is too slow and too risky to bet on before you have evidence, the Venture's ninety days have one job: produce that evidence, cheaply and safely, before committing the rest of the organization to anything.

Discover, weeks 1 and 2, is formation, not transformation. Pick one capability where the coordination cost is visible and the outcome is worth millions, not thousands. Name a sponsor with real authority to protect the effort, write a mission with one measurable outcome and written acceptance criteria, and carve out four to six of your best domain people plus an AI coordination layer into a protected environment where the rest of the organization's approval chain does not reach, with IT access requests filed on day one. This is a governance decision, not a technology decision, and by the end of week two the team has locked its mission and shipped a first working slice.

Build, weeks 3 through 8, is proof, not scale. The small unit runs its mission to a real result in real operating conditions, not a slide deck, demoing weekly to its sponsor against the acceptance criteria on a fixed cadence, not an open-ended check-in. By Pitch Day in week eight you have one of two outcomes, both useful: a proven capability with a reference model for how the rest of the organization should be redesigned around it, or a clear, cheap failure that tells you the mission or the team was wrong before you spent a reorganization's worth of political capital finding out. Prove, weeks 9 through 12, runs the model against real work and closes with the Transformation Dossier: the observed results a scale-or-stop decision needs. Either way, the executive's job across all three stages is protection and clarity, not building the thing personally.

Worked example: Northgate Foods

Northgate Foods is a fictional $600 million packaged-foods company with about 1,800 employees. Its quarterly demand-planning and replenishment cycle is a good stand-in for the coordination problem every executive recognizes: a forecast for the top 100 SKUs has to move through sales forecasting, category management, supply planning, logistics, and finance before a replenishment order goes out. Nine people are load-bearing in that cycle, one or two from each of the five functions, which puts the possible communication links at 36 (9×8/2, using the coordination formula). In practice the cycle takes six weeks door to door, with four formal handoffs, three of which exist purely to translate one function's spreadsheet into a format the next function can use.

Northgate's leadership had already tried the bolt-on path: a forecasting tool inside sales, adopted eighteen months earlier, that improved forecast accuracy by several points and changed the six-week cycle time not at all, because the four handoffs and the approval chain around them were untouched. Rather than adding a second tool to a second function, the CFO sponsored a five-person Venture team: one person each from forecasting, supply planning, and logistics, one Agentic Solutions principal, and an operating layer handling data assembly, first-pass forecast generation, and the translation work between functions that had previously required a person and a spreadsheet. The mission, written in one sentence with acceptance criteria the CFO signed: cut the demand-to-replenishment cycle for the top 100 SKUs from six weeks to two, without a forecast-accuracy regression of more than one point.

By Pitch Day, in week eight, the team had the cycle down to twelve days, with the remaining time concentrated in a single supplier-confirmation step outside the team's boundary, clearly named rather than hidden. Forecast accuracy held within the agreed tolerance. The reference model the team produced showed the parent organization exactly which of the four original handoffs the operating layer had absorbed, which one still needed a human relationship with a supplier, and what a permanent, right-sized version of the unit looked like for the other product categories, an outcome the eighteen-month-old forecasting tool never came close to producing.

Board-level risks and how to answer them

"Haven't we already invested in AI for each of these functions? Why sponsor something new?" Because those investments, however good the tools, were bolted onto an unchanged process, and the coordination arithmetic explains why that caps out regardless of tool quality. The Venture is not a sixth tool; it is a redesign of the unit the tools sit inside, and it is scoped to prove that in one bounded capability before you touch anything else.

"Isn't this just another skunkworks project that produces a demo and quietly dies?" The distinguishing feature is the mission contract, not the team size. A skunkworks project with no sponsor, no written acceptance criteria, and no plan for what the organization does with the result does die quietly. A Venture team with a named sponsor, a one-sentence measurable outcome, and a milestone that is never invoiced if it misses its acceptance criteria has a built-in mechanism that forces an honest verdict, proven or not, by Pitch Day in week eight.

"How do we know a five-person result generalizes to the rest of the organization?" You do not scale by growing this team; you replicate the pattern into the next capability with its own Venture, carrying forward the shared agent infrastructure and the reference model the first team wrote down. The worked example above named exactly which handoff still needs a human and which the agent layer absorbed, which is the specific, falsifiable claim a board can hold you to before approving the next one.

The executive takeaway

The coordination arithmetic is not a metaphor; it is the reason large teams exist, and it is the reason bolt-on AI, by leaving the 70 percent of people and process untouched, cannot deliver a structural return. The fix is not a bigger AI program inside the organization you have. It is a small, protected, AI-native unit built to the size the arithmetic now allows, given one mission and ninety days to prove it, so the rest of the organization changes around evidence instead of around a mandate.

Apply this week

1. Pick one capability where you can name the functions a result currently crosses, count the formal handoffs, and estimate the coordination links using the people actually load-bearing in the process.
2. Write, in one sentence, the measurable outcome a small team would need to prove for that capability, and check whether you, personally, could protect that team for ninety days.
3. List every AI tool already deployed against that capability and ask, for each one, which of the surrounding handoffs it actually removed rather than sped up.

Key points

• Coordination cost grows as n(n-1)/2, not with headcount directly: seven people have 21 possible links, 25 have 300, and close to 60 percent of a knowledge worker's day already goes to this overhead.
• The Compression Curve: as agents absorb coordination work, the minimum viable team size for owning a whole outcome falls faster than headcount growth alone would predict.
• Bolt-on AI touches only the technology slice of any transformation (roughly 10 percent) and leaves the people-and-process slice (roughly 70 percent) untouched, which is why returns cap out regardless of tool quality.
• The reframe: build a tiny version of the organization that would exist if AI had always been available, prove it against a written, measurable outcome, then transform the rest around what was proven.
• The ninety days are for formation and proof, not scale: name a sponsor, carve out a protected unit, and let a real result at Pitch Day and through Prove make the case a tool rollout never could.