In February 2024, Air Canada lost a court case to its own chatbot.

The bot had invented a bereavement-fare discount that didn’t exist. A customer relied on it. The airline argued, with a straight face, that the chatbot was a separate legal entity responsible for its own words. The tribunal disagreed, and Air Canada paid.

Almost every public AI failure of the past three years has this same shape. A New York City government bot told employers they could take workers’ tips, which is illegal. A dealership bot was talked into “selling” a $76,000 truck for one dollar. Media outlets retracted dozens of AI-written articles. A major bank announced AI-driven layoffs, then reversed them when the union showed the workload hadn’t actually dropped.

Different industries, different vendors, different models. One common cause: in every case, nobody checked the output before it hit the real world.

The opposite is also true. The AI deployments that quietly work, such as coding assistants, claims processing, and customer-support tools, all share one trait: every output gets checked, automatically and cheaply, before it matters.

That single difference is the most important idea in the economics of AI right now. It has a name: verifiability.

What “verifiable” actually means

Some work is easy to check and hard to do. Some work is hard to check even when it’s easy to produce.

A completed Sudoku takes twenty minutes to solve and two seconds to check. A bank reconciliation either balances or it doesn’t. Code either passes the test suite or it doesn’t. An insurance claim either matches the policy terms or it doesn’t.

Now compare: a legal opinion. A treatment plan. A five-year strategy. A hiring decision. Producing a plausible version of any of these takes an AI seconds. Checking whether it’s actually right takes an expert, takes time, or, worse, takes years for reality to deliver the verdict.

AI researcher Jason Wei formalized this as Verifier’s Law: the easier a task is to verify, the faster AI will master it. Andrej Karpathy puts it even more simply: traditional software automated what we could specify; AI automates what we can verify.

Why? Because a cheap, reliable check does two jobs at once. It’s how the AI learns (train against the check, millions of times), and it’s how a business can trust it (catch errors before they become Air Canada moments). No check, no learning, no trust, no deployment.

So the question “what will AI automate?” becomes a different question: “what work can be cheaply checked?”

Let’s count.

The arithmetic, step by step

I spent the past months building this into a working model: nine synthetic firms, including a bank, an insurer, a hospital, a law firm, a manufacturer, and a trucking company, each rebuilt from its real cost structure and redesigned around AI agents, with every task admitted only if its output could be cheaply verified. The numbers below come from that model, and I’m happy to share it with anyone who wants to pressure-test them.

Take a 100-person operations department: claims processing, customer service, back-office finance, that kind of work. Walk through what happens when you rebuild it around AI agents whose every output is verified, with humans handling the exceptions.

Step 1: How much of the work can be checked cheaply? Go decision by decision through the workflows and about 60% of operational decisions can run inside verified loops, checked against policy rules, ledgers, records, or tests. The rest is judgment calls, relationships, exceptions, and anything with no clean way to confirm “correct.”

So: 100 units of work becomes 60 loopable.

Step 2: Can your systems actually support the check? This is the gate most analyses skip. A verified loop needs something to verify against: a trustworthy record. Try this test on any company. Pick something a department produced last week, and ask whether the firm can produce, within one day and without manual reconciliation, a machine-readable record proving it was done correctly. Most companies fail. Official statistics say only about 10% of US firms run AI in production at all, and the typical enterprise captures roughly 65% of its theoretical loop potential because its records simply aren’t clean enough.

60 × 0.65 gives 39.

Step 3: The exceptions come back. Automated flows don’t eliminate humans; they concentrate them. In real production systems, exception handling persistently eats 20 to 40% of the “automated” work. Call it roughly one unit in five returning.

39 × 0.78 gives about 30.

Step 4: Oversight isn’t free. Somebody writes the policies, audits the loops, and signs off. That governance layer costs 2 to 9% of transformed operating cost at launch, settling to roughly 1 to 5% at steady state. (Compute, the thing everyone worries about, runs 1 to 3% and never becomes the binding cost.) Net it out:

About 28 of the original 100 units of operational labor actually leaves.

Sixty percent coverage became twenty-eight percent displacement. That gap between coverage and displacement is where almost every AI forecast goes wrong, in both directions.

Step 5: Operations isn’t the whole company. A firm is also sales, clinical staff, engineers, drivers, relationships, physical work. One hospital illustrates it perfectly. Its billing and revenue-cycle department is about 56% loopable, the best score in the whole analysis. Its clinical care, half the payroll, is about 8% loopable, because a treatment decision has no cheap check before irreversible harm. Same building, opposite worlds.

Blend it all and the typical established firm lands around 1.24×, roughly 19% cheaper to run, against a measured reality today of 1.05 to 1.15×, because most firms are still early. Within the specific functions that get reorganized: 1.2 to 1.6×, which matches the best field studies we have.

What that means in dollars

Global labor compensation is about $58 trillion a year (global GDP of roughly $111T, labor’s share roughly 52%). The functions where verified loops apply this decade, meaning administrative, clerical, support, claims, software delivery, and the back offices of finance, insurance, and healthcare, cover roughly 20% of it: about $11.6 trillion in wages.

Where are we today? Be honest about the starting point. Official statistics show AI adoption is real but shallow. Most firms aren’t in production at all, adoption weighted by employment is around a third, and the majority of adopters use AI in three or fewer business functions, mostly to assist humans rather than to run verified loops. Multiply it through: $11.6T affected wages, times a 4 to 6% net gain rate, times the sliver of organizations actually capturing it, and the realized market right now is roughly $50 to 140 billion a year. Tens of billions. Not trillions.

Compare that with the spending. Industry forecasts put generative-AI spend at over $600 billion in 2025, but roughly 80% of it is hardware, with software a few tens of billions. In other words, the world is currently spending several times more building AI capacity than it is capturing in verified value from it. That gap is not a scandal. It’s a queue. Value shows up only when infrastructure gets converted into governed, verified loops, and most organizations haven’t started.

Now run the funnel forward through coverage, readiness, exceptions, and oversight, and phase it by how fast organizations actually become capable of capturing anything: roughly $120 to 240 billion a year by 2028, rising to $1 to 2 trillion a year by 2035.

A trillion-plus is enormous. But it’s worth being clear about what that number is not. It is not “AI does half of all work.” It’s a fifth of wages addressable, and a quarter-ish of that captured, after every honest deduction.

That is the map today. Now for the more important question.

Is the unverifiable 80% actually fixed?

Every number above assumes the wall between checkable and uncheckable work stays where it is. It won’t. “Unverifiable” isn’t one condition. Decompose any judgment-heavy domain and you find five different reasons work can’t be checked, with wildly different life expectancies:

1. Nobody records the outcome. The ground truth exists; there’s no sensor on it. Half-life: short. Cheap sensing is eating this layer alive.

2. Checking costs too much. A check exists but costs more than the work. Half-life: short to medium. Cost curves win.

3. The standard is unwritten. The rules exist only in experts’ heads. This one masquerades as “judgment” more than anything else, and history keeps unmasking it. Credit decisions were a banker’s intuition until scorecards decomposed them in the 1960s. Options pricing was trader feel until Black-Scholes. Aviation turned pilot judgment into checklists. Each time, judgment turned out to mean policy nobody had written down yet, and language models are unusually good at writing down unwritten rules.

4. The feedback is slow. Reality delivers the verdict in years (strategy, diets, careers). Erodible through proxies and simulation, but with a hard floor, described below.

5. Checking is impossible in principle. The genuine article. Rare.

Want proof the wall moves? Look at the domain everyone calls least verifiable: medicine. Closed-loop insulin delivery is in production right now, an autonomous system making dosing decisions in the highest-stakes category that exists, approved by regulators. What moved it across the wall wasn’t a smarter model. It was a sensor. Continuous glucose monitoring made the outcome observable faster than harm can accumulate.

That points to the general law hiding underneath all of this:

A decision becomes automatable when verification latency drops below harm latency.

The wall was never “medicine” or “law” or “judgment.” It’s a ratio: how fast you can observe the outcome versus how fast a mistake becomes irreversible. Every new sensor, every automated first-pass check, every written-down rubric attacks that ratio.

The future numbers

Price the drift and the map redraws. If verification technology keeps improving at anything like its recent rate, loop coverage of operational work climbs from about 60% toward 68 to 75% within a decade, adding $300 to 600 billion a year to the pool. And in the scenario where automated verification crosses reliability thresholds in even two major expert domains, moving legal review or medical first-reads from “expert-only” to “machine-checked with human sign-off,” the pool runs to $3 to 5 trillion a year, because that’s where the biggest wage pools sit, locked behind expensive verification.

The market is not a fixed number. It is a number with a derivative, and the derivative is verification technology.

What survives

Strip away the four eroding layers and a rock core remains: real, but far smaller than today’s “judgment premium” assumes. And as the contingent layer erodes, the judgment that survives doesn’t just survive. It concentrates and re-prices upward. Four things sit in the rock:

One-shot decisions with no rerun. You can’t A/B test the merger or replay the patient. Only protocols can be verified; the individual call cannot.

Bets that outlive the world. If the outcome arrives in seven years and the environment reshuffles in three, the ground truth expires in transit.

Questions of what’s worth wanting. Six good months, or eighteen medicated ones? No instrument can ever verify that answer, because there’s no fact out there to converge on, only a person’s own trade-off. Populations can be A/B tested; a person’s future self cannot. And that decision was never the doctor’s to automate in the first place. It’s the patient’s.

Independence. A system vouching for itself is a closed loop. The accounting profession has made exactly this argument about AI-assisted work, and it’s their home turf: an audit signature has value precisely because someone independent supplies it. Machines may one day do the checking, but the signature must always be someone else’s. AI can move the frontier. It cannot verify itself across it.

The question to ask about your own work

Not “is my work judgment?” That framing assumes judgment is one thing, permanently out of reach. It isn’t. Most of it is unwritten policy, missing sensors, and slow feedback wearing a trench coat.

The real question: which of the five reasons makes my work hard to check, and what is that reason’s half-life?

If your moat is an unwritten standard, assume it will be written. If it’s a missing sensor, assume it’s coming. If it’s the cost of checking, assume the cost curve wins. The durable ground is the rock: the one-shot calls, the long-horizon bets, the values conversations, and the independent signature. That’s the work that gets more valuable as everything around it becomes checkable.

Roughly two trillion dollars a year says the glacier is moving. Build on rock.

Methodology Appendix: How the Numbers Were Built

The model, the evidence, and the arithmetic behind “Unverifiability Has a Half-Life”

This appendix documents where every figure in the article comes from: the model that produced it, the evidence that disciplines it, the exact arithmetic, and the honest limits of both.

1. The approach in one paragraph

No organization has yet been rebuilt end to end around verified AI-agent loops with a published, audited before-and-after income statement. Every well-documented deployment bolts AI onto legacy processes. So the analysis combines two layers. An evidence layer draws on peer-reviewed field studies, tribunal rulings, official statistics, and documented rollbacks to establish what is measured. A mechanism layer, a simulation of nine synthetic firms, supplies what the evidence cannot reach: the cost structure of a firm actually reorganized around verified loops. Every claim carries a grade. Measured means it comes from Tier 1 or 2 evidence. Derived means it is a model output with evidence-bounded parameters. Assumed means exactly that, and is disclosed.

2. Definitions

A governed agentic loop is a unit of work in which AI agents execute tasks within explicit, human-authored policy; humans handle escalated exceptions and run an independent verification process that confirms outcomes against a system of record.

Work is admitted into a loop only if it passes the verifiability test: the result can be checked objectively, fast enough to catch failure before it becomes irreversible, at a cost below doing the work manually. No task in the model is classified as loop-run without naming how its result is checked and what the check costs.

3. The engine

Nine archetype firms span the economy: a property and casualty insurer, a contact-center outsourcer, a regional bank, a B2B software company, a law firm, an acute hospital, a discrete manufacturer, a general retailer, and a logistics carrier. Each is built in stages.

Stage 0. Construct the firm’s financial anatomy from public financial and occupational data: revenue, labor cost by function, non-labor operating cost, capital. Pass-through costs (claims payouts, cost of goods, purchased transport) are excluded from transformable cost.

Stage 1. Decompose each value-chain link into the outcomes it must produce and the decisions inside them, never into today’s process steps.

Stage 2. Apply the verifiability test to every decision. Each is classified loop-run, human judgment, or loop-running work (the new work that loops create). The loopable fraction of each function, lambda, is an output of this design, not an input.

Stage 3. An adversarial pass attacks every surviving loop from three directions. A Skeptic attacks verifiability: true exception rates, the cost of a missed error. A CFO attacks economics: compute, integration, governance, transition cost. An Operator attacks the seams: bursty exceptions, degraded modes, staffability. Loops that fail are killed and recorded. The pass is applied to every labor pool, including the governance function itself.

Stage 4. Re-derive the financials. Per function f:

L′f = (1 − λf) · Lf · αeff + λf · Lf · εf

αeff = 1 − (1 − αf) · κ

Cf = ρf · λf · Lf (compute)

Gf = [Gkernel + Gvar(t)] · λf · Lf (governance)

OpEx′ = Σf (L′f + Cf + Gf) + N′ + ΔK

Gain = OpEx / OpEx′

Where lambda is loop coverage, epsilon is the exception burden (work that comes back to humans), alpha is the assist factor on retained human work, kappa is maturity capture, rho is compute cost per unit of loop volume, and G is the governance layer with a permanent kernel plus a variable component that decays as policies stabilize.

Stage 5. Everything runs as a Monte Carlo over all parameters, with one critical design choice: a common-mode factor correlates the dominant uncertainty (whether cheap verification holds up across the firm at all) so it cannot be averaged away across functions.

4. Where each parameter comes from

Loop coverage, lambda (the 60%). Derived, then validated. The derivation was done by reasoning agents given only the verifiability test and the frozen firm anatomy, blind to all deployment evidence and to any target numbers, to prevent anchoring. Across the nine firms, the designed coverage of rules-based operational work clusters at 0.52 to 0.65, median 0.60, with a structural band of 0.48 to 0.68. The derivation was then scored against fourteen documented deployment outcomes (successes and rollbacks, from the Air Canada tribunal ruling to the McDonald’s drive-thru withdrawal). The verifiability test retrodicts twelve of fourteen in the right direction. This validates the ordering and structure of lambda, not its precise level, which is why the level carries a wide band.

Maturity capture, kappa (the 65%). A verified loop needs a trustworthy record to verify against. Maturity is graded by a concrete test: can the firm, within one business day and without manual reconciliation, produce a machine-readable record sufficient to verify last week’s output against explicit policy? Three grades follow. M1 (fails almost everywhere): kappa 0.25. M2 (core transactions covered, exceptions leave the system): kappa 0.65. M3 (complete, continuously verified record): kappa 0.92. The economy-wide mix, 35% M1, 50% M2, 15% M3, is calibrated to official statistics: roughly 10% of US firms using AI in production, about a third on an employment-weighted basis, and a majority of adopters using AI in three or fewer functions (US Census Bureau business trend surveys, 2025 to 2026). The article’s typical firm sits at M2, hence 0.65. This is the softest calibrated input in the model and it ranks first in every sensitivity analysis.

Exception burden, epsilon (the one in five). Bounded by field evidence. Production straight-through-processing programs in payments and claims persistently show exception handling consuming 20 to 40% of nominally automated flows. Review-inclusive cost analyses of frontier model output (GDPval, 2025) reduce naive time savings to 1.2 to 1.6 times once checking is priced. The model uses 0.12 to 0.30 by function; the article’s funnel uses 22%.

Assist factor, alpha. Bounded by the best field studies. A quasi-experimental rollout across 5,179 support agents measured 15% average productivity gains, concentrated at 34% among novices and near zero for the most experienced (Brynjolfsson, Li and Raymond, Quarterly Journal of Economics, 2025). A randomized trial of 453 professionals found 40% faster writing on bounded tasks (Noy and Zhang, Science, 2023). A randomized trial of experienced developers on their own mature codebases measured a 19% slowdown against a predicted speedup (METR, 2025), which caps alpha for expert work. Assist is gated by kappa: a firm that cannot trust its records cannot reliably deploy copilots against them.

Governance (2 to 9% at launch, 1 to 5% at steady state). The governance function was put through the same verifiability test as everything else. Its monitoring majority is itself rules-based work against a record and partially loops. Its irreducible kernel, independent attestation and adversarial audit, cannot loop by construction: a system attesting to its own compliance is circular, a conclusion supported by peer-reviewed findings that AI judges exhibit self-preference bias, and by the EU AI Act’s legal requirement for human oversight of high-risk systems. Hence a cost that decays but never reaches zero, with a permanent kernel of 0.6 to 1.5% of transformed cost.

Compute (1 to 3%). Modeled generously per unit of decision volume and it still never binds, consistent with a measured price decline of more than 280-fold for constant-capability inference over roughly two years (Stanford AI Index, 2025).

5. The funnel arithmetic

The article’s 100-unit department walkthrough is the engine’s equation evaluated at typical (M2) maturity:

Coverage: 0.60

After maturity: 0.60 × 0.65 = 0.39

After exceptions: 0.39 × (1 - 0.22) = 0.30

After governance: 0.30 - 0.02 = 0.28

Coverage of 60% becomes net displacement of about 28% of operational labor. Blending all functions across each firm’s full anatomy, weighted by labor cost, gives the firm-level results: 1.15 to 1.39 times for typical firms by industry, 1.24 times economy-weighted, with a structural uncertainty band of 1.12 to 1.42. Immature (M1) states land at 1.05 to 1.15 times, which matches the measured present and is the source of that figure in the article.

The hospital example is a direct model output: its revenue-cycle function designs to lambda of roughly 0.56 (every output checks against payer rules and the medical record), while clinical care, about 52% of its labor, designs to roughly 0.08 (no cheap check before irreversible harm).

6. The market arithmetic

Wage base. Global GDP of roughly $111 trillion (IMF World Economic Outlook, 2025) times a labor income share of 52.3% (International Labour Organization, 2024) gives about $58 trillion in global labor compensation.

Addressable slice. The functions covered by the archetypes (administrative and clerical work alone is 12.2% of US employment per the Bureau of Labor Statistics, plus customer service, software delivery, and the administrative layers of finance, insurance, and healthcare) map to roughly 20% of the global wage pool: about $11.6 trillion.

Today’s realized value. $11.6T, times a mature net gain rate of 4 to 6% of addressed labor cost per year (the pool-weighted average of the archetype results), times current effective capture of 10 to 20% (from the adoption statistics above), gives roughly $50 to 140 billion per year.

The path. Capture is phased on the diffusion record of comparable technologies (cloud computing’s two-decade spend curve, e-commerce’s quarter-century to 16% of retail): 10 to 15% of the addressable pool captured within capable organizations at year three, 25 to 35% at year five, 55 to 70% at year ten. That yields roughly $120 to 240 billion per year by 2028 and $1 to 2 trillion per year by 2035. A second, fully independent method (2025 software and services spend of about $65 billion, compounded at 25 to 40% decaying to 15%, times a 2 to 4 times value multiplier) lands at $0.7 to 2.8 trillion, overlapping the first. The divergence between the methods is analyzed, not averaged.

The frontier scenario. If verification technology continues improving at its recent measured rate (agent task horizons doubling roughly every seven months, automated judges reaching human-level agreement rates), loop coverage of operational work drifts from 0.60 toward 0.68 to 0.75 over a decade, worth $300 to 600 billion per year. If automated verification crosses reliability thresholds in two or more expert-review domains, the pool runs to $3 to 5 trillion. These scenario figures are quarantined and never blended into the base case, because the drift rate is the most speculative quantity in the analysis.

Spend versus value. Industry forecasts put 2025 generative-AI spending above $600 billion, with roughly 80% in hardware and software in the tens of billions (Gartner, 2025). The comparison in the article divides realized value by that spend directly.

7. Evidence standards

Sources are tiered. Tier 1: peer-reviewed studies and randomized trials. Tier 2: tribunal rulings, regulatory texts, official statistics. Tier 3: document-supported journalism. Tier 4: named large-sample surveys. Tier 5: vendor and consultancy claims, directional only, never load-bearing. Field evidence is admitted into the model only as bounds on epsilon, alpha, governance, and the maturity mix. It is never allowed to inform the lambda derivation, which is where anchoring would corrupt the result; lambda is derived blind and validated afterward against the case record.

8. Uncertainty, honestly

Two bands are reported. The parametric band reflects the model’s chosen probability distributions and is authored precision: it can be made arbitrarily tight by choosing tight distributions, so it is disclosed but not trusted. The structural band adds the coarseness of the nine-archetype grid, alternative functional forms, and the calibration error of the maturity mix. The structural band is the honest one. For the base-case market figure it spans roughly 0.6 to 1.6 times the central estimate.

9. Limitations and how the analysis could be proven wrong

The case set that validates the mechanism is small and publicity-biased. The maturity mix rests on the best available official statistics, which measure adoption rather than record quality directly. The model prices states and a phased path between them, not the true speed of organizational change. Bolt-on field evidence can only lower-bound designed loops, and no audited, end-to-end reorganized firm yet exists to test the gap.

Specific observations would break specific claims. A production rules-based loop running far outside the 0.48 to 0.68 coverage band at twelve months breaks lambda. Closed-loop audit pass rates measured across a real sector diverging more than twofold from the assumed mix re-weights every market case. Audited multi-firm evidence of sustained organization-wide gains above 2 times within three years breaks the gain band upward; five years of median adopters capturing nothing breaks it downward. A regulator or insurer accepting fully machine attestation of loop compliance breaks the governance kernel. Official adoption statistics still below 12% of firms in production in 2028 mean the market path is too optimistic; verified positive returns on more than $500 billion of annual software and services spend by 2028 mean it is too conservative.

The full model, the per-firm parameter files with their evidence bounds, the blind derivations, and the case-set scoring exist as runnable artifacts and are available on request.

There are a few years of essays here. You don’t need all of them. Read these six, in this order, and you’ll have the whole picture — the shift, why most efforts fail, what it feels like, what’s really at stake, how to actually build, and what to do Monday.

1. The Dissolution — what’s happening, right now, at the industry level.

Between April and May 2026, SAP and Salesforce answered the same question three different ways. Read this to understand the one question on every enterprise board’s agenda for the next eighteen months: who owns the agentic work surface — the independent AI operating system, or the incumbent system of record?

The Dissolution

The Dissolution

Saleh Hamed

·

May 15

Read full story

2. Electrify the Factory, Don’t Just Swap the Engine — why 95% of AI efforts “fail.”

They don’t fail because AI doesn’t work. They fail the way factories failed when they dropped an electric motor into a steam-era layout and wondered why nothing changed. You’re retrofitting. Your competitors are rebuilding.

Strategy

Electrify the Factory, Don’t Just Swap the Engine: Why Most AI “Fails”

Saleh Hamed

·

August 23, 2025

Read full story

3. I Set Up an AI Agent for My Father Last Weekend — this is already happening in your building.

My father went from “what is an agent?” to running his smart home without writing a line of code. The technical barrier didn’t shrink — it moved. It became a communication barrier. That shift is happening across your organization right now; your people just aren’t calling it an agent yet.

Field Notes

I Set Up an AI Agent for My Father Last Weekend

Saleh Hamed

·

Feb 11

My father has a garden and a smart home. Sensors, irrigation controllers, AC units, lights, water meters. He’s gone deep on this stuff over the years, and he had a growing list of complaints that none of his apps could quite handle.

Read full story

4. The Ladder Is Gone — the deeper stakes, if you want them.

Every economic model since Adam Smith assumes humans enter the economy through the bottom rung. AI arrives already capable — no apprenticeship, no bottom rungs. Your hiring model is built on a structure that’s quietly disappearing.

Foundations

The Ladder Is Gone - Part 1

Saleh Hamed

·

November 30, 2025

Read full story

5. Operating Model to Operating System — how to actually build native.

What an agentic-native company is really made of: agent-first process, an actionable data fabric, policy-as-code, observability, risk plumbing. Not a center of excellence. A redesign.

The Dissolution

Operating Model → Operating System: How to Build an Agentic‑Native Company

Saleh Hamed

·

August 28, 2025

Created on 2025-08-28 17:32

Read full story

6. The Two-Hour Rule — something to do on Monday.

Give every employee two hours a week to work real problems with AI. Unmeasured, uninterrupted. Two thousand hours a week across a thousand people compounds into things no innovation program will buy you.

Strategy

The 2-Hour Rule: Why AI Makes Your Entire Workforce an Innovation Engine

Saleh Hamed

·

October 6, 2025

Read full story

———

Get the book, free.

The Dissolution — the full book on the AI-native enterprise — as a single read. Subscribe and I’ll send it to you:

https://ainativestrategy.ai/subscribe

Free. One essay a week after that.

— Saleh Hamed

July 6, 2026

Two robots, one argument

In 1966, a team at Stanford Research Institute began building the most sophisticated robot the world had ever seen. It was a tower of sensors and circuitry on wheels, connected to a room-sized computer that held something no machine had ever possessed: a complete internal model of its world. Before every move, the robot would consult its model, reason about it, and produce a plan. Life magazine called it “the first electronic person.” The researchers, noting how it trembled when it moved, called it Shakey.

Shakey was a triumph, and Shakey was almost useless. Updating and consulting that beautiful internal model took so long that the robot could spend an hour thinking about a task a child would do without thinking at all. The world would change, the model would lag, the plan would fail. The smarter they made its picture of the world, the further the picture drifted from the world itself.

Twenty years later, a young Australian at MIT named Rodney Brooks committed heresy. He built robots with no model of the world at all. His six-legged machine, Genghis, was a bundle of simple reflex loops layered on top of each other: sense the ground, lift the leg, catch the balance. Nothing in Genghis knew what a room was. Genghis scampered across rough terrain in real time while Shakey’s descendants were still planning. Brooks compressed his heresy into six words that became famous in robotics: the world is its own best model. Don’t build an inner copy of reality and reason about the copy. Check reality itself, constantly, and act.

You can guess which philosophy won. Brooks went on to co-found iRobot. Shakey is in a museum. The Roomba, a machine with barely any brain at all, is in tens of millions of homes.

We are building Shakey again

Now here is the strange part. Half a century later, the most fashionable idea in corporate technology is to build Shakey again. This time for the whole company.

The pitch arrives under many names: the enterprise brain, the organizational memory, the company knowledge graph, the AI that “knows everything about your business.” The idea is always the same. Gather every document, every decision, every fact into one great semantic memory, and let AI consult that memory to get work done. It sounds obviously right. It is the same intuition the Stanford team had in 1966, scaled up ten thousand times.

And the early returns look eerily familiar. Companies have adopted AI almost universally, and the surveys from the big consultancies keep finding the same embarrassing gap: adoption near ninety percent, meaningful financial impact for a minority, most firms reporting little value at all. The models got brilliant. The picture of the company got bigger. The needle barely moved.

The lesson of the Prussian forest

To understand why, it helps to visit an eighteenth-century German forest.

The political scientist James C. Scott tells the story in his book Seeing Like a State. Prussian officials, wanting to manage their forests scientifically, replaced the chaotic old woodland with something legible: a single species of tree, planted in perfect rows, every trunk countable, the whole forest reduced to a table of numbers. For one generation it was a spectacular success. Yields were predictable, administration was effortless, the map matched the territory because the territory had been forced to match the map. Then the soil, deprived of the messy underbrush and dead wood the old forest had lived on, gave out. The second and third plantings sickened. German foresters had to invent a new word for what happened next: Waldsterben. Forest death.

Corporate life has run Scott’s experiment roughly once a decade for forty years. Expert systems in the eighties. Knowledge management in the nineties. Corporate wikis, enterprise ontologies, master data programs. Each began with the same promise: at last, one legible map of everything we know. Each ended the same way. The people assigned to tend the map stopped tending it, because tending it was a chore and no one’s actual work depended on it. The map drifted from the territory. Eventually a wrong map became worse than no map, and the whole thing was quietly abandoned. Anyone who has clicked into a company wiki and found the org chart from three reorganizations ago has stood in a dead Prussian forest.

Two kinds of memory, and only one survives

There is a simple way to see the underlying law. In most households there are two kinds of memory. There is the calendar on the fridge, and there is the journal someone swore they would keep. The calendar is accurate to the day, because everyone uses it, and if an entry is missed a child misses a dentist appointment. The journal is three months behind, because keeping it is a virtue rather than a necessity. Memory kept true by use survives. Memory kept true by effort decays.

Companies are full of the first kind, and this is the fact the enterprise-brain pitch skips over. The accounting ledger is accurate because money actually moves through it. The order system is accurate because shipments actually route through it. Payroll is accurate because people get very loud when it isn’t. A company, it turns out, has already written itself down, in the systems where the work actually happens, and that record stays fresh for the same reason the fridge calendar does. Nobody maintains it. The work maintains it.

Which raises an awkward question about the giant AI memory: what exactly is it for? It is a photocopy of the filing cabinet, pasted into a diary, and the diary starts aging the moment the copying stops.

The cashier does not need the CEO’s strategy

There is a second thing the brain-builders skip, and it may be the more important one. To do almost any job in a company, you do not need to know everything about the company. The cashier makes change without reading the marketing plan. The claims adjuster settles the claim without the CEO’s calendar. This is not a bug in corporate life. It is the entire technology of corporate life. Over a century, firms painstakingly arranged themselves so that every decision needs only a small slice of information: this form, these rules, that record. Herbert Simon won a Nobel prize for explaining why this works. Friedrich Hayek won one for showing that whole economies coordinate this way, through small local signals, with no central mind anywhere. Ronald Coase won one for demonstrating that reducing how much any one person needs to know is, in a sense, the reason firms exist at all. Three Nobel prizes converging on one lesson: large-scale coordination runs on structure and local knowledge, not on a big brain. The organization that wires every action to a memory of everything is not upgrading itself. It is un-inventing itself.

What to build instead

So what does the alternative look like? Roughly what Brooks built, and roughly what a good restaurant kitchen has always been. Not one chef who knows everything, but stations. Small loops, each responsible for one concrete result. Each loop can suggest an action but cannot simply take it: the action is checked against written rules that work like a guest list, where nothing happens unless a rule explicitly allows it. Each loop confirms its work against reality itself, the actual ledger, the actual order system, rather than against its own account of what it did. Each loop keeps receipts no one can quietly edit. And each loop earns independence the way a new employee does, by watching first, assisting under supervision, and acting alone only after a track record, with every human correction becoming a permanent rule so the same question never needs answering twice. The system that results holds more memory than any brain, but every bit of it is fridge-calendar memory, written by the work itself.

The builders are already converging

The people building AI’s infrastructure appear to be arriving at the same place. Michael I. Jordan of Berkeley, once identified by the journal Science as the world’s most influential computer scientist, has spent years arguing that the future is not one artificial mind but intelligent infrastructure, systems that are smart the way markets are smart. A market that feeds New York every single day, he likes to point out, is an intelligent entity, and no neuron in it knows the whole plan. NVIDIA’s researchers published a position paper arguing that fleets of small, specialized models will beat giant ones for real work, describing the winning design as Lego-like composition. Andrej Karpathy, formerly of Tesla and OpenAI, tells builders that the products which actually work keep humans in tight verification loops and expand a machine’s autonomy the way you’d expand a trainee’s. Different vocabularies, same instinct. Shakey lost. Genghis won. Build loops, not brains.

The brain you already have

None of this means the dream of organizational memory is worthless. It means the executives asking for a brain already have a better one than the vendors are selling. It is sitting in the transaction systems that never go stale, in the audit trails, in the rulebooks that encode every hard lesson the institution ever learned. A company was never a person, and it never needed a mind. It is something rarer: an institution, a set of roles, rules, and records that lets thousands of people, and soon thousands of machines, accomplish what no single mind could hold.

The Prussians wanted a forest they could read. They should have wanted a forest that could live. Fifty years of robots, forty years of dead corporate wikis, and three Nobel prizes are all whispering the same advice to anyone about to sign the purchase order for an enterprise brain.

The world is its own best model. Your company is too.

Research Notes

The evidence behind “The Robot That Thought Too Much”: what the surveys, benchmarks, vendor documentation, and analyst record from 2022 through mid 2026 actually show. Sources at the end. The most fragile claims are flagged rather than hidden.

Note 1. The value gap is measured, not anecdotal

AI adoption is nearly universal while financial impact remains rare, and the numbers come from organizations with no stake in the argument.

McKinsey’s State of AI research finds roughly 88 percent of organizations now use AI in at least one function, while only about 39 percent report any earnings impact at all, most of it small. Deloitte’s State of AI 2026 survey of 3,235 executives finds only 34 percent of organizations describe themselves as deeply transforming with AI, and only 21 percent have a mature governance model for AI agents despite the vast majority planning to deploy them. BCG’s global research finds a majority of companies reporting little to no value from AI investment, with a single-digit minority capturing value at scale. Gartner, in a widely reported June 2025 release, projected that more than 40 percent of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.

One widely quoted figure deserves a flag. The MIT NANDA study’s finding that 95 percent of enterprise GenAI pilots produced no measurable P&L impact has had its methodology publicly challenged for a narrow success definition and a short measurement window. It is directionally consistent with the sturdier McKinsey, BCG, and Deloitte numbers, but it should be quoted with attribution rather than asserted as fact.

Note 2. Bolting on fails and redesign works, according to the people selling both

AI added to work designed for humans produces little; work redesigned around AI produces much. This is now the explicit, published position of the major consultancies and platform vendors themselves.

McKinsey’s agentic AI research states that value comes from reimagining workflows from the ground up with agents at the core, not from deploying tools into existing processes. Gartner’s guidance uses nearly identical language about rethinking workflows from the ground up. Microsoft’s Work Trend Index research has pivoted its framing from individual copilot productivity to the “Frontier Firm,” an organization redesigned around orchestrated agent operations under human direction. The most concrete number comes from BCG’s June 2026 report on reinventing the operating system of work: in its client deployments, end-to-end process redesign achieved cost reductions above 60 percent where bolt-on tool deployment did not, and almost two thirds of the agentic AI leaders it surveyed expect operating model changes as a consequence. These are consulting-house figures with selection bias toward successful engagements, and they should be read as directional. The direction, however, is unanimous.

Note 3. The benchmark record argues for verified loops, not free-running autonomy

Checking work against reality, rather than trusting an AI’s own account, is the load-bearing design principle, and the agent-benchmark literature makes the case quantitatively.

On tau-bench, a benchmark of realistic customer service tasks involving tools, policies, and databases, state-of-the-art models succeed on fewer than half of tasks, and consistency collapses when the same task is attempted repeatedly: pass rates over eight attempts fall below 25 percent in the retail setting, a drop of roughly 60 percent from single-attempt scores. Tasks requiring four or more database writes succeed only around one fifth of the time. On WorkArena, an enterprise UI benchmark built by ServiceNow Research, GPT-4o completed about 43 percent of tasks and scored zero on an entire task category. On the original WebArena benchmark, the best GPT-4 based agent achieved 14.4 percent end-to-end success against 78.2 percent for humans. Agent-SafetyBench reported that none of the tested agents exceeded a 60 percent safety score. AgentBench identified long-horizon reasoning and instruction following as the persistent obstacles.

The pattern across five independent benchmarks: failures concentrate exactly where trust should not be extended, in multi-step write operations against real systems, in policy adherence, and in long chains of unverified action. The same literature shows what helps. The foundational ReAct paper demonstrated that interleaving reasoning with action and observation improves reliability, and Reflexion showed that structured feedback loops improve performance further. Loops with checking beat straight-line autonomy in the lab as well as in the argument.

Note 4. The industry’s own architecture converged on the loop

The strongest evidence is architectural rather than statistical. Inspected through developer documentation and SDKs rather than marketing, every major vendor’s production agent stack now exposes the same set of primitives: a trigger, scoped context, a reasoning or proposal step, a policy or guardrail gate before action, human approval and escalation points, write-back to systems of record, execution traces, evaluation harnesses, and a learning loop. This holds across OpenAI’s AgentKit, Anthropic’s agent guidance and the Model Context Protocol, Microsoft’s multi-agent orchestration, Google’s agent development kit with its explicit loop agent, Salesforce’s Agentforce with its observability layer, ServiceNow’s orchestrator and control tower, AWS Bedrock AgentCore’s policy enforcement, IBM’s watsonx Orchestrate, and the open-source runtimes LangGraph and AutoGen.

Anthropic’s published engineering guidance is representative of the design philosophy: the best production systems begin as simple, composable workflows, adopting fuller autonomy only where task variability justifies the added cost and risk. The Berkeley “compound AI systems” thesis, among the most cited artifacts in the field, argues that state-of-the-art results now come from systems of components rather than from single monolithic models. NVIDIA’s research position paper argues that small, specialized models are sufficient, more suitable, and more economical for most agentic invocations, describing the winning pattern as composition of small experts rather than scaling up a monolith. None of these organizations uses the kitchen metaphor. All of them are describing the kitchen.

Note 5. Even the brain vendors gate the writes

The claim that a global company memory should never hold authority over action has a revealing witness: the leading vendor of the organizational-brain archetype itself. Palantir’s ontology is the most serious and well-funded version of the enterprise semantic layer in existence, and in Palantir’s own platform documentation, “all writes must go through Action Types,” which enforce validation rules, approvals, and audit trails, with human-in-the-loop workflows woven through autonomous operations. The semantic layer informs; a governed action layer decides. Across the major vendors, none positions a global semantic memory or knowledge graph as the authoritative execution layer for operational decisions. Knowledge graphs and vector stores appear consistently as context providers on the read path. Where the map exists, the map advises. The gate still decides.

Note 6. The honest caution: naming things is not building them

The counter-evidence belongs in any honest appendix. Gartner has coined the term “agent washing” for the rebranding of chatbots, assistants, and RPA as agents, estimating that of the thousands of vendors claiming agentic products, only around 130 are genuine. The market narrative runs well ahead of operational reality: most enterprises remain at assistant-level maturity, copilots dominate actual adoption, and the gap between claimed and production-scale agent deployment is the defining feature of the current market. The governed-loop architecture is where the evidence points, not where most organizations stand. Anyone presenting it as an already-won category, rather than an emerging direction with a measured rationale, is committing the same inflation the data punishes.

Note 7. The theory predates the technology

The intellectual claims are standard results in their home fields, documented there long before the AI literature arrived: Herbert Simon on near-decomposability and bounded rationality, Friedrich Hayek on coordination through local signals, Ronald Coase and Oliver Williamson on the firm as an information-economizing institution, W. Ross Ashby on regulators scoped to what they regulate, Rodney Brooks on behavior-based robotics and the world as its own best model, James C. Scott on the failure of centrally legible maps, and Michael I. Jordan on intelligence as a property of markets and loosely coupled systems. A 2020s engineering literature converging on conclusions reached independently by cybernetics, economics, robotics, and political science across seventy years is itself a finding.

Sources

Yao et al., ReAct (ICLR 2023). Shinn et al., Reflexion (2023). Yao et al., tau-bench (arXiv 2406.12045, 2024). WorkArena, ServiceNow Research (ICLR 2024). Zhou et al., WebArena (2023). AgentBench (ICLR 2024). Agent-SafetyBench (2024). Zaharia et al., The Shift from Models to Compound AI Systems, Berkeley AI Research (2024). Belcak et al., Small Language Models are the Future of Agentic AI, NVIDIA Research (arXiv 2506.02153, 2025). Anthropic, Building Effective Agents (December 2024). Gartner press release on agentic AI project cancellations and agent washing, as reported by Reuters (June 2025). McKinsey, The State of AI (2025). BCG, Reinventing the Operating System of Work with AI (June 2026). Deloitte, State of AI 2026 (survey of 3,235 executives). Microsoft, Work Trend Index, Frontier Firm research (2025 to 2026). MIT NANDA, The GenAI Divide (2025; methodology contested, quote with attribution only). Palantir platform documentation on Action Types. Michael I. Jordan, Artificial Intelligence: The Revolution Hasn’t Happened Yet, Harvard Data Science Review (2019). Simon, The Architecture of Complexity (1962). Hayek, The Use of Knowledge in Society (1945). Brooks, Intelligence Without Representation (1991). Scott, Seeing Like a State (1998).

Almost nobody is talking about this. The AI conversation is fixated on enterprises. Productivity gains. Headcount. Quarterly earnings calls. But businesses are not outside of society. They are the largest informal school system humanity has ever built, and every skill they teach their staff eventually walks out the front door at five o’clock and goes home.

It always has. In 1979, two men in Cambridge released a piece of software called VisiCalc. It was the first electronic spreadsheet, built for accountants. Within a year, it was selling Apple IIs to dentists and contractors who had no business owning a computer but had suddenly discovered they could not run their books without one. What we forget about VisiCalc is what happened next. The habit of spreadsheet thinking migrated out of the office and into the kitchen. By the late 1990s, regular families were running mortgage comparisons and college-savings projections on the same software their CFOs used. Financial literacy didn’t rise because schools taught it better. It rose because the office accidentally taught the household.

Frederick Taylor’s stopwatch studies were designed for steel mills, but by 1912 a woman named Christine Frederick was publishing a series in Ladies’ Home Journal called “The New Housekeeping,” teaching middle-class women to apply Taylor’s time-and-motion principles to their kitchens. Toyota’s kanban system, invented to manage automotive parts, now sits on the refrigerators of suburban families as chore charts. PowerPoint, born in the conference room, is how middle schoolers explain their science projects. Email etiquette, with its subject lines and salutations and “per my last message,” was invented inside corporations and is now how teenagers write to their landlords.

The pattern is consistent enough to be a law: whatever the office learns, the home learns next. And what the office is learning right now, at extraordinary speed, is how to think with a machine.

This transition is different from spreadsheets or email. Spreadsheets taught us to model. Email taught us to communicate asynchronously. Search engines taught us to look things up. AI teaches us how to delegate cognition itself: how to break a vague desire into a structured request, how to specify a goal precisely enough that someone else can pursue it, how to verify work you did not do. These are not technical skills. They are executive skills, in the truest sense of the word. And for the first time in history, roughly a billion working adults are being trained in them simultaneously, and paid to practice every day.

Imagine what happens when those people go home.

The size of the prize

I started wondering what this is actually worth. Not to a company, but to a household. If structured thinking is about to be redistributed on a planetary scale, what is the size of the prize?

The number, it turns out, is enormous. Economists have been tallying it for years, in fragments, under different names. The advice gap. Sludge. Administrative burden. The justice gap. Nobody had summed it, so I did, using research from the CFPB, the WHO, the World Justice Project, and a stack of papers from the American Economic Review.

Start with a single American household. The typical family carrying a credit card balance pays north of $2,400 a year in interest alone, on an average balance of $10,563 at a 23.37% APR. About one in five American homeowners who could profitably refinance does not, leaving a median $11,500 on the table, according to a landmark study from the University of Chicago. One in four 401(k) participants fails to capture their full employer match, forfeiting $1,336 a year each, or roughly $24 billion in free money declined across the country. The average Medicare Part D enrollee picks the wrong drug plan and overpays by about $300 a year. Only 12 percent of seniors actually choose the cheapest plan that covers their medications.

These are not stories about poor people making desperate choices. They are stories about ordinary people, across the income distribution, leaving money in envelopes on the kitchen counter because the cognitive cost of opening them is too high after a long day.

Scale this up. Medication non-adherence, meaning patients not taking medicines they have already been prescribed and already paid for, costs the United States somewhere between $100 billion and $500 billion a year, and is associated with as many as 275,000 preventable deaths annually. Americans spend 7.1 billion hours and $148 billion a year complying with the federal tax code. The IRS Taxpayer Advocate estimates that $7 billion in Earned Income Tax Credit goes unclaimed every year by people who are entitled to it but cannot navigate the forms. About 18 percent of Americans eligible for food stamps do not enroll, roughly eight million people in any given month, almost entirely because of paperwork.

In civil court the asymmetry is starker. A randomized trial in Boston housing court found that two-thirds of tenants with full legal representation kept their homes, versus one-third without. In immigration appeals, represented applicants succeed at four times the rate of the unrepresented. Globally, the World Justice Project estimates that 5.1 billion people, two-thirds of humanity, have unmet legal needs: a will that was never written, a deed that was never registered, a workplace abuse that was never contested.

Add the investment “behavior gap,” meaning the documented underperformance of ordinary investors versus the funds they are invested in, driven almost entirely by panic selling and trend chasing, and you have roughly another $300 billion a year in foregone American household wealth.

Add it up, deflate for double-counting, and the number lands between $1.5 and $2.1 trillion a year in the United States alone. Call it five to seven percent of GDP. About $10,000 to $15,000 per household, every year, in losses caused not by misfortune but by the absence of a structured thinker in the room.

A note before extrapolating globally. The United States is a uniquely punishing environment for bad decisions. American credit card APRs, overdraft fees, healthcare prices, and litigation costs are extreme outliers. You cannot multiply the US number by twenty and call it the world. But the opposite is true on the other side of the ledger. Two-thirds of adults worldwide are not financially literate by basic standards. Medication non-adherence is even higher outside wealthy countries. The justice gap is overwhelmingly concentrated in the global south. A conservative, GDP-weighted estimate puts the worldwide cost of preventable individual decision failures at somewhere between $5 and $8 trillion a year, or 5 to 7 percent of global GDP.

This is the size of the prize. This is what a world without structured thinking costs, every year, on top of every other tax we pay.

Give a man a fish...

What makes the number especially striking is why the losses persist. They are not, mostly, problems of information. People have known for decades how to refinance a mortgage, take medication on schedule, fill out a FAFSA, choose a drug plan, write a will. The information is on Google. The information is free. And yet the losses continue, year after year, in remarkably stable proportions.

The most important randomized experiment in this whole literature was run in 2008 by the economists Eric Bettinger, Bridget Long, Philip Oreopoulos, and Lisa Sanbonmatsu. They wanted to know what would actually get low-income high school seniors to apply for federal college aid. They tried two interventions. The first was an information campaign: detailed, accurate, personally relevant data about financial aid eligibility. The second was the same information plus an H&R Block tax preparer who sat next to the family and helped them fill out the form, in the office, on the spot.

The information campaign, on its own, did nothing. Zero effect. The intervention with the person sitting next to the family raised college enrollment by eight percentage points and lifted two-year completion rates from 28 to 36 percent.

This is the cleanest finding in the entire field, and it explains almost everything. People do not lack motivation. They do not lack information. What they lack is somebody in the room with them while they fill out the form. A structured thinker. Patient, available, not tired, not judgmental, not charging $400 an hour.

For most of human history, that person was a function of class. If you were born into a family with a lawyer for an uncle, a doctor for a cousin, a financial planner at the country club, you made systematically better decisions across your entire life. Not because you were smarter, but because you had someone to think alongside. This is what sociologists mean when they say privilege compounds across generations. It is not money, exactly. It is access to structured thinking at the moments that matter.

It is also exactly what every household on the planet is about to acquire.

What it looks like at the kitchen table

The household has always been run by exhaustion and improvisation. People come home tired. They make decisions on instinct. They put off the difficult conversation, the long-term plan, the careful budget, because the cognitive cost of starting is too high after a day at work. AI dissolves that cost. Not entirely, not for everyone, not overnight, but at the margin, decisively.

The person who spent the day at the office briefing an AI on a complex client problem comes home with the muscle memory to brief one on a complex family problem. The drafting of a difficult letter to a sibling. The structuring of an aging parent’s care. The mediation of a disagreement with a teenager. The auditing of a household budget that has, frankly, never been audited.

None of these things require AI. All of them have been waiting, often for decades, for someone in the family to have the energy and the framework to begin.

A realistic share of the cognitive deadweight we can actually recover is probably a quarter to a third of the gross figure. There will be new pathologies: marriages mediated through a chatbot, children raised by algorithmic permissiveness, elderly relatives talked to less because the assistant has been delegated the small talk. Every previous technology that promised democratization produced its own dark afterlife, and this one will too. That deserves a separate essay.

But even a third of the recoverable gap is more than a trillion dollars a year in the United States, and several trillion globally. Money that currently leaks, quietly, out of the lives of ordinary people and into the balance sheets of the banks, hospitals, insurers, landlords, and bureaucracies organized to absorb it. Redistributing structured thinking is, mechanically, one of the most progressive economic transfers ever proposed. Cognitive deadweight falls hardest on the poor: lower-income households pay roughly 80 percent of overdraft fees, the bulk of payday loan costs, and constitute almost all unrepresented pro se litigants. The smart friend who happens to be a lawyer or a doctor or a financial planner has always been a luxury good. It is about to become a utility.

The revolution will not arrive with a press release. It will arrive the way VisiCalc did. Somebody’s parent, sitting at the kitchen table on a Tuesday night with a tool they first met at work. Finally opening the envelope. Finally filling out the form. Finally writing the difficult email. Finally running the numbers on a life.

For two thousand years, we have repeated the same maxim.

Give a man a fish, and you feed him for a day.

Teach a man to fish, and you feed him for a lifetime. A lifetime of licenses to renew, taxes to file, regulations to read, insurance to compare, forms he does not understand and cannot afford to get wrong. The maxim promised a lifetime of fish. What it delivered was a lifetime of paperwork.

Give every fisherman a steward, and the village can finally fish.

That is what happens at one kitchen table. The same thing is about to happen to every institution on Earth. But that is a different essay.

Where this essay begins. Three earlier essays set the ground this one stands on. The first argued that the old structure of enterprise software is dissolving. The second argued that the enterprise is being reconstituted, a new interaction-based front office rising on top of a reconstituted system of record. The third argued that what holds the new enterprise together is an operating system for agents, a control plane that the enterprise should think hard about owning. Those three essays describe a destination: what is happening, what the enterprise becomes, and what machinery makes it an institution. They do not say how an enterprise actually gets there from where it stands today. This essay is about the getting there. It is about migration, and its central claim is that almost every enterprise is about to attempt the migration with the wrong map.

Every large enterprise knows how to run a transformation. The method is deep muscle memory: inventory the systems, prioritize them, migrate them, retrain the users, decommission the old platforms. That method is about to fail a great many companies, because it migrates the wrong thing. The move to an AI-native enterprise is not a migration of systems. It is a migration of experiences, the recurring situations in which people understand, decide, and act. This essay argues for that reframing, lays out the three movements that an experience-led migration actually requires, and is honest about the discipline that holds them together and the ways the whole approach can still go wrong.

I. The wrong map

Begin with a piece of good news, because it is real and it is also the trap. Every large enterprise already knows how to do a transformation. The capability is mature, rehearsed, and institutionally deep. There is a method, and any competent technology organization can run it from memory: take an inventory of the systems, rank them by value and risk and difficulty, migrate them in waves, move the infrastructure, retrain the people who used the old thing on the new thing, and decommission the platforms left behind. This is how enterprises moved to client-server, to the web, to mobile, to the cloud. It has worked, more or less, across four decades and four technology waves. It is one of the most reliable competencies in modern management.

And it is the wrong map for this transition. Not slightly wrong, not in need of an update. Wrong in its primary unit, which means wrong in a way that no amount of skilled execution can rescue, because skilled execution of the wrong plan produces the wrong result faster.

The reason is at the center of this whole sequence of essays, so it is worth stating once more in the plainest possible form. The established method migrates systems. It takes the application as its unit of work: this ERP module, that CRM instance, this data warehouse. It assumes the systems are the thing, and that transformation means getting the enterprise from an old set of systems to a new set of systems. That assumption was true, or true enough, for every prior wave, because every prior wave really was a change of systems. The web era was the same work delivered through a browser. The cloud era was the same systems running on someone else's hardware. The unit was always the system, and the method was built for the unit, and the fit was good.

The move to an AI-native enterprise is not a change of systems. The earlier essays in this sequence labored to establish exactly this and I will not re-prove it here, only name it: the systems, the ERP and the CRM and the data warehouse and the document store, do not go away. They are not the thing being migrated. They descend, intact, to become the substrate, the authoritative record of state beneath a new layer. What actually changes, the thing that is genuinely migrating, is one level up from the systems. It is the experience of work. It is how a person comes to understand a situation, weigh it, decide, and act. In the old enterprise that experience was navigation: the person opened systems, searched them, read them, assembled the pieces by hand, and operated the workflow. In the AI-native enterprise that experience is something else: the person expresses an intent, receives a synthesis grounded in the enterprise's real state, examines options, and authorizes action. The systems still hold the state. But the experience of working with that state is rebuilt completely.

Every prior wave really was a change of systems, so the method built for systems fit. This wave is not. The systems become the substrate. What migrates is the experience of work.

So the enterprise that approaches this transition with the inherited method makes a precise and costly category error. It points the system-migration machine at its application estate, and the machine does what it is built to do: it inventories the applications, ranks them, and starts bolting AI onto them one by one, a copilot in the CRM, an assistant in the ERP, a chatbot on the service desk. Each of those is locally plausible. None of them changes the experience of work, because the experience of work was never inside a single application; it always ran across many of them. The result is the pattern the earlier essays described from other angles: enormous activity, real spend, visible motion, and an enterprise that at the end of it is a slightly faster version of exactly what it was. The map said migrate the systems. The enterprise migrated the systems. The experience of work, the thing that was supposed to be transformed, was never on the map.

The whole of this essay follows from correcting the map. If the unit of this migration is the experience and not the system, then the inventory is wrong, the sequencing is wrong, the team is wrong, the success measure is wrong, and the definition of done is wrong. Everything the established method specifies has to be rebuilt around the right unit. The rest of this essay is that rebuilding.

II. The unit is the experience

If the system is not the unit of migration, the essay owes a precise account of what is. The unit is the enterprise experience, and the word has to be defined carefully, because it is easy to hear it as something softer and vaguer than it is.

An enterprise experience is a recurring situation in which a person needs to understand something, decide something, create something, coordinate something, or act. It is not a feeling and it is not a user-interface concern. It is a unit of real work, and it has a particular property that the system does not have: it is defined by the human's purpose, not by the software's boundaries. Consider a handful of them, and notice their shape. Preparing for a customer renewal conversation. Responding to a regulatory or legal question. Resolving an operational incident. Diagnosing why a number is off plan. Onboarding a new manager into a role. Reviewing and approving a commercial contract. Each of those is a real, nameable, recurring piece of enterprise work. And each of them, examined honestly, runs straight across the system map. Preparing for a renewal touches the CRM, the support system, the contract store, the billing platform, the product telemetry, and three years of email. It is not in any of those systems. It is the thing a human being assembles by visiting all of them.

This is why the experience, and not the system, is the right unit, and the reason is almost arithmetic. The experience is where the work actually lives. The system-centric method, by taking the application as its unit, can only ever improve one fragment of an experience at a time, and it improves each fragment in isolation, which means the improvements do not compound, because the cost of the experience was never inside the fragments. The cost was in the seams: in the human labor of crossing from one system to the next, holding context across the gaps, reconciling what does not reconcile, assembling the scattered pieces into something a decision can be made on. A copilot inside the CRM makes the CRM fragment faster and leaves every seam exactly where it was. To change the experience you have to take the whole experience as the unit, span all the systems it touches, and rebuild the crossing. That is a different unit of work than the system, and it requires a different everything else.

The cost of enterprise work was never inside the systems. It was in the seams between them. A unit of migration that cannot see the seams cannot move the cost.

There is a second reason the experience is the right unit, and it connects this essay to the one before it. An experience, rebuilt, is the natural home of an intent. The AI-native enterprise, the earlier essays argued, is intent-centric: a person expresses what they are trying to achieve and a governed layer of agents carries it out. But intent does not float free; it always attaches to a situation. The intent prepare me for the Henderson renewal is an experience with an intent expressed into it. So when an enterprise rebuilds an experience end to end, it is not doing user-interface work. It is building the place where intent enters the institution and the place where the operating system of the previous essay meets a real human purpose. The experience is the unit at which the whole architecture of the new enterprise actually touches the work. Choose any smaller unit and you are improving software. Choose the experience and you are migrating the enterprise.

This reframes the inventory, the first thing the old method gets wrong. The system-centric migration begins by cataloguing applications. The experience-centric migration begins by mapping experiences: going into the business and finding the recurring situations where people understand, decide, and act, recording which systems each one touches, where it hurts, who owns it, and what a good outcome would be. That map, the experience map, is the true starting artifact of this migration. An enterprise that begins with an application inventory has begun by describing its substrate. An enterprise that begins with an experience map has begun by describing the work it is actually there to transform.

III. Three movements

Knowing the unit is not the same as knowing how to move. An experience-led migration requires three distinct kinds of work, and the heart of this essay is the claim that there are exactly three, that they are different in kind, and that the relationship between them is the thing most enterprises get wrong. Name them first, plainly, and then take each in turn. Raise the floor. Build the substrate. Transform the experiences.

The first movement is to raise the floor. This is the broad, shallow, organization-wide work of building a common level of AI fluency: a shared language for what AI-native work is, a working sense of what the tools can and cannot do, an instinct for what is safe and what is not, and enough imagination across the workforce that people can participate in redesigning their own work rather than having it redesigned at them. It is called raising the floor because that is the precise shape of it. It is not about creating experts. It is about lifting the minimum, so that there is no part of the enterprise standing at zero, because the parts standing at zero are where shadow usage and quiet risk and simple failure of imagination collect. Raising the floor is wide and thin. It touches everyone and it changes no single piece of work very much. On its own, that is exactly its weakness: an enterprise that only raises the floor produces a workforce that is conversant with AI and an operating model that has not changed at all, a great deal of fluency with nowhere to go.

The second movement is to build the substrate. This is the deep, horizontal, technical and governance work that the previous essay described in full: the control plane, the identity that covers agents as well as people, the policy engine, the registry of approved tools, the data access with its permissions and lineage, the evaluation harness, the audit trail. It is the foundation that lets an AI-native experience reach enterprise state without bypassing a single control. This essay does not need to re-describe it; the essay before it did that. What this essay needs to say is its role in the migration: the substrate is the movement that makes the other two safe and real. It is also, on its own, the most seductive of the three failure modes, because it is the one that looks most like the kind of project a technology organization knows how to run. An enterprise that only builds the substrate produces an elegant, governed, genuinely impressive platform that no business experience is actually using yet, a foundation with no building on it, and a chief financial officer who has stopped believing the slides.

The third movement is to transform the experiences. This is the deep, narrow, vertical work of taking one priority experience, a renewal preparation, an incident response, a contract review, and rebuilding it end to end: redesigning the work itself, building the intent-based interface over it, wiring it through the substrate to the systems of record, placing the human approval points, and proving it is genuinely better than the application-navigating version it replaces. This is the movement where transformation becomes concrete, where the enterprise can point at a real situation and say, that is different now, and better, and measured. It is the proof. And on its own it is the third failure mode: an enterprise that only transforms experiences, without raising the floor beneath them or building the substrate under them, produces islands. A few brilliant rebuilt experiences, each improvised on its own foundation, ungoverned, unconnected, impossible to scale, surrounded by an organization that cannot use them and a control environment that cannot account for them.

Raise the floor and you get fluency with nowhere to go. Build the substrate and you get a foundation with nothing on it. Transform experiences and you get islands. Each alone fails in its own way.

Three movements, then, and each one has a characteristic and predictable way of failing when it is pursued by itself. Notice that these are not hypothetical failure modes. They are the three most common shapes of enterprise AI effort visible right now: the training-led program, the platform-led program, the pilot-led program. Each is one of the three movements, mistaken for the whole. Which is the subject of the next section, because the relationship between the three movements is not a matter of project sequencing. It is the central discipline of the entire migration.

IV. The discipline is parallelism

Here is the instinct, and it is a good instinct, honed by every well-run project an experienced executive has ever delivered. Three movements, clearly distinct. Therefore: sequence them. Do the foundational one first, get it solid, then build the next on top, then the third. Specifically, the instinct says, build the substrate first, because it is the foundation and you do not build on an unfinished foundation. Then, once the substrate is ready, raise the floor so people can use it. Then, once the floor is raised, transform the experiences. Three movements, three phases, in a disciplined order. It is the natural way to manage complexity, and here it is a mistake. It is, in fact, the most expensive mistake available, because it is the one that looks the most responsible while it is being made.

Take the sequence the instinct proposes and follow what actually happens. The enterprise spends its first long stretch building the substrate alone, because the substrate is the foundation and the foundation comes first. But the substrate, built in isolation, has nothing pulling on it. It is being designed against imagined requirements rather than real ones, so it is designed wrong in ways no one can see yet, and it produces, for a long time, no value an executive can point to. Patience runs out before the foundation is finished. Or the enterprise raises the floor first, runs the fluency program across the whole organization, and creates thousands of people who now have a vivid sense of what AI-native work could be and absolutely nothing sanctioned to do it with, so the energy dissipates, or worse, it flows into shadow tools, and the floor that was raised has quietly settled back down within two quarters. Or the enterprise leads with a transformed experience, a single pilot, because a pilot shows value fast, and it does, and then the pilot cannot scale because there is no substrate beneath it and no floor around it, and the one success becomes an island that the rest of the enterprise watches with admiration and cannot copy.

Every sequential order fails, and it fails for one underlying reason: the three movements are not three phases of one project. They are three aspects of one change, and they are mutually dependent in a way that makes any ordering incoherent. The substrate is designed correctly only when real experience-transformation work is pulling real requirements through it. Experience transformation is safe and scalable only when the substrate is there beneath it. Both are absorbed by the organization only when the floor has been raised enough that people can receive them. Each movement needs the other two to be already happening. There is no order. There is only the parallel.

The three movements are not three phases of one project. They are three aspects of one change. Each needs the other two already underway. There is no valid order, only the parallel.

So the discipline of an experience-led migration is parallelism, and it has to be stated as a discipline because it does not come naturally and the organization will fight it. Running three movements at once feels, to a project-trained instinct, like indiscipline, like a failure to phase the work. It is the opposite. It is the harder discipline: holding three kinds of work in motion together, at deliberately different depths, the floor going wide and shallow, the substrate going deep and horizontal, the experiences going deep and narrow, each one calibrated to feed the other two. The earlier essay in this sequence observed that the enterprises capturing real value run their layers in parallel rather than in sequence. This is the same finding, arrived at from the migration side. The parallel is not an aesthetic preference. It is the only configuration in which the three movements are coherent, and an enterprise that cannot hold the parallel will, with the very best intentions and the most disciplined-looking plan, produce one of the three familiar failures.

This does not mean everything happens everywhere at once, which would be the opposite failure, a migration with no focus at all. It means the three movements run concurrently while staying narrow in their targets: the floor rising across everyone but lightly, the substrate built out horizontally but only as fast as real experiences require it, and the experience transformation deliberately limited to a small first wave. Concurrent, but bounded. The next section is about how that first wave is chosen, because choosing it well is what keeps the parallel from becoming chaos.

V. The first wave, and the pod that carries it

An experience-led migration becomes concrete in the choice of which experiences to transform first, and in the kind of team that carries the transformation. Both follow directly from the reframing, and both differ sharply from what the system-centric method would prescribe.

The first wave should be small. Two experiences, perhaps three, not ten. The point of the first wave is not coverage; it is proof and learning, the establishment of a pattern the enterprise can then reuse. And the experiences chosen should meet a specific set of conditions, because the first wave is carrying more weight than its own results. A good first-wave experience is knowledge-heavy, requiring synthesis across many sources, because that is where the AI-native interface most visibly outperforms human navigation. It is painful, slow, or fragmented today, so the improvement is felt and not merely measured. It crosses several systems but has clear systems of record, so it exercises the substrate honestly without drowning the first attempt in ambiguity about where truth lives. It carries enough business value to be worth a serious leader's attention, but not so much irreversible risk that early experimentation is dangerous. And it has a genuine owner, a specific executive who can change the process, the policy, and the adoption, because an experience cannot be transformed by a team that can only change the software. The system-centric method chooses its first wave by system criticality. The experience-centric method chooses by this cluster of conditions, and the difference is the difference between a pilot that teaches the enterprise how to migrate and a pilot that merely works.

The team that carries an experience transformation is not a technology team, and this is one of the most concrete and most ignored requirements of the whole approach. Because the unit is an experience and not a system, the team has to contain everyone needed to redesign the work, not merely everyone needed to build the interface. That means a single pod, accountable for one experience, that includes the experience owner who answers for the outcome, the domain expert who knows how the work genuinely runs including its exceptions and its tacit knowledge, the process owner who can actually change the workflow and the approval path, the data steward who knows what the data means and how sensitive it is, the security and risk lead who defines the controls, the engineer who builds the AI interface and its retrieval and its tool use, the designer who shapes the new interaction, and the change lead who carries the adoption. That is a cross-functional pod, and the breadth of it is not a nicety. It is structural. A technology team building on its own can change the interface to an experience. Only a pod with the process owner and the domain expert and the risk lead inside it can change the experience itself, and changing the experience is the entire point.

A technology team can change the interface to an experience. Only a cross-functional pod can change the experience itself. The breadth of the pod is not a nicety. It is the method.

There is a sequence to the work a pod does, and it is worth stating compactly because it is the inverse of the system-migration sequence and the inversion is instructive. The system method runs: inventory the systems, prioritize, move the infrastructure, retrain the users, decommission. The experience method runs: map the experiences, choose the first wave, expose the relevant enterprise state safely through the substrate, redesign the work and build the intent-based interface over it, place the human approval points, measure against the old way, harden the controls, and only then reuse the pattern on the next experience and, where it genuinely helps, retire the old interaction path. The two sequences barely share a word. That is the measure of how different a migration this is, and of how badly the inherited method, run on confident autopilot, will serve the enterprise that trusts it.

And the pattern, the reusable residue of a transformed experience, is what turns a first wave into a migration. The first pod builds, alongside its one rebuilt experience, a set of things the next pod does not have to build again: a way of exposing a system of record through the substrate, a tested approval pattern for a class of action, a retrieval approach, an evaluation method, a control template. The second pod inherits those and adds its own. By the fifth or sixth experience the enterprise is no longer building from scratch; it is composing. This is how an experience-led migration scales without becoming the thing it was trying to escape, a single enormous program. It scales as a growing library of reusable patterns, carried from pod to pod, each transformed experience making the next one faster. The migration is not a plan executed top-down. It is a pattern propagated experience by experience.

VI. Knowing is not doing

One distinction governs the safety of this entire migration, and an enterprise that blurs it will either move recklessly or not move at all. It is the distinction between AI that helps a person know something and AI that goes and does something. Reading is not acting. They are not two points on one scale; they are different in kind, and they must be governed differently, and an experience-led migration has to keep them separate by design.

The earlier essay on the operating system described the control plane that governs agent action. This essay needs only to add the migration-level rule that follows from it, and the rule is that capability is granted in stages, never all at once. An AI-native experience begins by being allowed only to read: to retrieve and summarize what the person asking is already entitled to see. From there it may be allowed to reason: to compare, analyze, diagnose, recommend, still without changing anything. Then to prepare: to draft the message, the form, the proposed transaction, for a human to inspect. Then to act, but only after explicit human approval, a person in the loop for each consequential action. And only then, and only in bounded low-risk domains where the controls have genuinely proven themselves, to act on its own within policy. Read, reason, prepare, act with approval, act within policy. The stages are a ladder, and an experience is walked up the ladder one rung at a time, and it climbs only as far as the evidence and the controls of that specific experience justify.

This staging is what makes an experience-led migration safe enough to move quickly, which is the apparent paradox worth drawing out. An enterprise frightened of agent risk tends to do one of two things: it forbids action entirely and gets a migration that never reaches the value, or it deploys action carelessly and gets the incident that sets the whole effort back a year. The staged ladder is the way out of that bind. It lets the enterprise move now, with confidence, on the reading and the reasoning, where the risk is genuinely low and the value is already substantial, while holding the acting under tight control and releasing it experience by experience as the evidence comes in. The migration does not wait for the governance of autonomous action to be solved before it begins. It begins on the rungs that are already safe, and it climbs as it earns the right to. That is not caution opposed to speed. It is the configuration that delivers both.

Reading is not acting. They are different in kind. Stage the capability, climb the ladder one rung at a time, and the migration can be fast and safe at once.

VII. What could prove this wrong

The argument of this essay is that the migration to an AI-native enterprise must be led by experiences, executed through three parallel movements, and carried by cross-functional pods up a staged ladder of capability. It is a confident argument, and honesty requires being clear about where it could fail.

• The experience may not stay the right unit. I have argued that the experience is the durable unit of migration because it is where human work lives. But if agentic capability advances far enough, the enterprise may stop being organized around human experiences at all, and the right unit could become the agent workflow, with no human experience at its center. In that world this essay describes a transitional method, correct for the migration but not for the destination. I think the experience unit is durable for the horizon that matters to present decisions. I do not think it is eternal.

• Parallelism may be a counsel only the well-resourced can follow. Running three movements at once demands managerial capacity, funding tolerance, and executive air cover that not every enterprise has. A smaller or more constrained organization may have no realistic choice but to sequence, accepting one of the three failure modes as the price of moving at all. If so, the honest advice for that enterprise is not the pure parallel but the least-bad sequence, and this essay has not written that down. It is a real gap, and it is the most likely thing a constrained reader will, correctly, push back on.

• The pod may not scale as cleanly as the pattern story implies. I have argued that reusable patterns let an experience-led migration scale without becoming a monolithic program. It is possible that the patterns generalize less well than that hopeful account suggests, that each enterprise experience is idiosyncratic enough that the fifth pod is not meaningfully faster than the first. If the reuse does not materialize, experience-led migration becomes very expensive at scale, and the approach would need a stronger answer to scale than this essay has given it.

• The whole reframing may underestimate the systems. This essay has been firm that the unit is the experience and not the system. A fair challenge is that some transitions really are system-deep, that the substrate work is so large and so foundational in certain enterprises that to call the migration experience-led is to describe the visible tip of a project whose real mass is exactly the system-and-platform work the old method was built for. I think the reframing holds, because even there the experience is what tells the substrate work what good looks like. But an enterprise with a genuinely broken substrate should hear this essay with that caution in mind.

My honest weighing is that the second of these is the one most likely to matter in practice, because parallelism is demanding and many enterprises are constrained, and a method that only works when fully resourced is a method with a real limit. The other three are the ordinary uncertainties of writing about a transition while standing inside it. None of them overturns the core, which is narrow and, I think, sound: the established system-migration method takes the wrong unit, the right unit is the experience, and an enterprise that re-centers its migration on experiences will see its inventory, its sequencing, its teams, and its measures of success all change together. How fast, how cleanly, and how far the approach scales are the open questions. That the map needs redrawing is not.

VIII. The map and the territory

Let me end by drawing the four essays of this sequence together, because this is the one that turns their argument toward action.

The first essay said the old structure is dissolving. The second said the enterprise is being reconstituted into a new institution on top of a reconstituted system of record. The third said that institution is held together by an operating system, a control plane, and that owning it is the decision that matters most. Each of those is a description of a destination. This fourth essay has been about the journey, and its argument has been a single correction: that the map every enterprise will instinctively reach for, the system-migration map that served four prior technology waves, is the wrong map for this one, because it migrates systems and what now has to migrate is the experience of work.

That correction is not a small adjustment to the established method. It changes the first artifact, from an application inventory to an experience map. It changes the unit of work, from the system to the recurring human situation. It changes the team, from a technology function to a cross-functional pod with the process owner and the domain expert inside it. It changes the shape of the effort, from a phased sequence to three parallel movements held in deliberate tension. It changes the safety model, from a single decision about agent risk to a staged ladder climbed experience by experience. And it changes the measure of done, from systems decommissioned to experiences genuinely better than they were. An enterprise that internalizes the correction is running a different migration than its competitors who did not, even if both started in the same place on the same day with the same technology available.

And here is the thing worth ending on, the reason this is a hopeful essay and not a warning. The destination, across these four essays, can sound overwhelming: a dissolved structure, a reconstituted institution, an operating system to be built or owned, a whole estate of work to be migrated. Taken whole, it is too large to act on. But the experience-led migration makes it small enough to start. An enterprise does not begin by transforming itself. It begins by choosing one experience, one recurring situation where people understand and decide and act, and rebuilding that, well, with a real pod, on a real piece of substrate, measured honestly against the old way. That is a thing a leader can actually authorize on a Monday. And then another, and the patterns begin to compound, and the floor rises underneath it all, and some quarters in, the enterprise looks up and finds that it has been becoming AI-native not by a great program but by the steady migration of its experiences, one at a time, each one a little easier than the last. The destination is large. The first step is not. The migration is the patient work of crossing from one to the other, and the enterprises that cross well will be the ones that started with the right map. Choose the experience. Build the pod. Hold the parallel. Begin.

A note on sources

This essay is the fourth in a sequence and rests on the arguments of the first three rather than re-establishing them. Its account of enterprise migration draws on the public record of enterprise AI practice through May 2026, including the transformation playbooks published by the major strategy firms and systems integrators, the documented programs of enterprises that have moved early, and the staged-autonomy and agent-governance models now common in the field. The three-movement model of migration, the experience as the unit of transformation, the cross-functional pod, the staged capability ladder, and the governed substrate are synthesized and articulated here from that body of practice. The reframing of enterprise migration as experience-led rather than system-led, the parallelism argument, and the conclusions are the author's own. The direction of travel is, in my view, hard to ignore. The pace at which experience-led migration scales, and the resources it genuinely demands, remain open questions on which honest practitioners will differ.

Where this essay begins. Two earlier essays set the ground this one builds on. The first argued that the old structure of enterprise software is dissolving, the work surface moving to a new layer of agentic software. The second argued that the enterprise itself is being reconstituted, a new interaction-based front office standing on top of a reconstituted system of record. Both took something as given and left something unbuilt. What they left unbuilt is the machinery. An enterprise that has dissolved its old structure and reconstituted itself as a stack of agents and records is not yet an institution. It is a collection of parts. Something has to hold the parts together, schedule them, govern them, make them accountable. This essay is about that something. It is an operating system, and it is the successor to the thing the hierarchy used to be.

Decompose every job in a company into tasks, hand the tasks to agents, and you are left with a network of agents exchanging work. That is where a great deal of current thinking stops, as though the network were the destination. It is not. A network of agents is not an institution. An institution is a network plus the thing that governs it: that allocates authority, schedules work, contains failure, and stays accountable for all of it. For a century that governing thing was the hierarchy, made of people. The hierarchy is going. This essay is about what replaces it. The replacement is an operating system, and the most important decision an enterprise will make in the next decade is whether it owns one or rents one.

I. The network and the nothing

An earlier argument, made at the altitude of the individual job, ended at a striking and slightly vertiginous image. Take any role in a company. Decompose it honestly into the tasks it actually consists of. Hand each task, as the technology becomes able to carry it, to a capable agent. Do this across every role, and the org chart, considered as a map of who does what, quietly empties out. What is left, when the decomposition is complete, is a network of agents exchanging work with one another. At the time, that was as far as the eye could see. It was the honest end of that particular argument, and it was left there, as a destination.

It is not a destination. It is a description of a pile of parts. And the gap between a pile of parts and a working institution is the whole subject of this essay, because it is precisely the gap that almost no one is looking at while everyone is looking at the agents.

Consider what a network of agents, on its own, does not have. It does not have a way of deciding which agent gets to act when two of them want the same resource. It does not have a way of granting one agent authority to act and withholding it from another. It does not have a way of containing a failure, so that an agent that goes wrong damages one process rather than all of them. It does not have a memory that outlives any particular exchange. It does not have a way of answering, after something has happened, the question of who did this and on whose authority. It does not have a stable surface that a human being, or another institution, or a regulator, can address and hold responsible. It has none of that. It has only the agents, and the agents only do tasks.

Everything in that list, every single item, was until very recently provided by the hierarchy. Not by software. By the structure of the organization itself, by the layers of management and the reporting lines and the approval chains and the job descriptions. The hierarchy decided who acted when. The hierarchy granted and withheld authority. The hierarchy contained failure within departments. The hierarchy, through its files and its managers, held the memory. The hierarchy answered the question of who did this. The hierarchy was the stable surface you addressed when you addressed the company. We are so used to thinking of the hierarchy as a social structure, a ladder of status and pay and ambition, that we have not noticed the other thing it was, the less visible and more important thing. It was the machine that made a crowd of people into an institution.

A network of agents is not an institution. It is a pile of parts. An institution is the network plus the thing that governs it.

And that machine is being dismantled. The previous essays in this sequence traced the dismantling from two directions, the dissolving of the software structure and the reconstituting of the enterprise around interactions and agents. Both are real and both are happening. But neither finished the thought, and the unfinished thought is this. If you remove the hierarchy, and the hierarchy was the thing that turned the parts into an institution, then you have not simply flattened the organization. You have opened a void where its governing machinery used to be. The agents do the tasks. Nothing, currently, does the governing. That void is the most important and least discussed feature of the present moment, and an enterprise that does not consciously fill it does not get a flat, fast, modern organization. It gets a pile of parts that occasionally catches fire.

Something has to fill the void. That something is the subject of this essay, and it already has a name, because the problem it solves is one that computing solved once before, at a smaller scale, decades ago. The thing that turns a set of capable components into a governed system is an operating system. The enterprise now needs one. Not as a metaphor. As an actual architectural layer, deliberately built or deliberately bought, that does for a network of agents what the hierarchy used to do for a crowd of people.

II. What an operating system actually does

The phrase operating system has been worn smooth by use, and most people now hear it as a brand, the thing with a logo that boots up when you turn on a laptop. To see why it is the right word for what an enterprise now needs, the phrase has to be returned to its original and more precise meaning.

In the early days of computing there was no operating system. A program ran directly on the machine, and it had the machine to itself, and it had to manage everything itself: where in memory it would put things, how it would talk to the printer, when it would yield the processor. This worked, barely, while there was one program. The moment a machine had to run several programs, it broke, because the programs had no way to share the machine without colliding. The operating system was invented to solve exactly that problem, and it solved it by becoming the layer underneath all the programs, the layer that owned the scarce resources and lent them out under rules.

Strip an operating system to its functions and there are five, and they are worth naming plainly, because each one is about to describe an enterprise rather than a computer. It allocates scarce resources, deciding which process gets memory and processor time and for how long. It manages processes, starting them, scheduling them, stopping them, deciding what runs now and what waits. It enforces permissions, deciding which process is allowed to touch which file and which device, and refusing the ones that are not. It isolates failure, so that one program crashing brings down itself and not the machine, walling off the damage. And it presents a stable interface, a consistent surface that programs can write to and that does not change every time the hardware underneath it changes. Allocation, scheduling, permission, isolation, a stable surface. That is an operating system. Everything else is decoration.

Now read those five functions again as a description of what a company does, because that is what they are. A company allocates scarce resources, capital and attention and the time of its best people. It manages processes, starting work, sequencing it, deciding what is done now and what waits. It enforces permissions, deciding who is allowed to authorize a payment, sign a contract, change a record, speak to a regulator. It isolates failure, through departments and limits and divisions, so that a mistake in one part does not consume the whole. And it presents a stable interface, a known surface, a name and an address and an accountable officer, that customers and courts and regulators can deal with. A company has always done these five things. The only question that has ever mattered is what performs them.

Allocation, scheduling, permission, isolation, a stable surface. That is an operating system. It is also, exactly, what a company does.

For a century, the answer was the hierarchy. The five functions were performed by people arranged in a structure. And because the people were the operating system, no one called it that, in the same way that no one living inside an atmosphere talks much about air. The operating system of the enterprise was invisible because it was made of the same material as the enterprise itself. It is becoming visible now, for the first time, for an uncomfortable reason. It is becoming visible the way a thing becomes visible when it is removed: as an absence, as a sudden awareness of a function no longer being performed. The enterprise operating system is being noticed precisely because the old one, the human one, is going, and the five functions are now, briefly, performed by nothing at all.

III. The hierarchy was the operating system

This is the reframe the whole essay turns on, so it is worth slowing down and stating it without hedging. The organizational hierarchy was not primarily a ladder. It was primarily an operating system. The ladder was the part you could see, the part that organized status and salary and the shape of a career, and because it was the visible part it was the part everyone argued about and the part the previous book in this sequence was largely concerned with. But underneath the ladder, doing the quiet structural work, the hierarchy was running the five functions. It is worth walking through them once more, in the language of an actual company, because once the hierarchy is seen this way its disappearance stops being a human-resources story and becomes an architecture story.

The hierarchy allocated resources. A budget moved down through the layers, divided at each one, and the dividing was a scheduling decision about what the company would and would not do. The hierarchy managed processes. A manager was, among other things, a scheduler, deciding which work happened this week and which waited, which task went to whom. The hierarchy enforced permissions. The approval chain, the spending limit that rose with seniority, the requirement of a second signature, these were a permission system, expressed in job titles instead of code. The hierarchy isolated failure. The division of the company into departments and subsidiaries and business units was, among other things, a set of walls, so that a failure in one was contained and did not propagate. And the hierarchy presented a stable interface. The org chart gave the outside world a surface to address: a named executive accountable for each function, a known place to send the contract or the complaint or the subpoena.

Seen this way, the flattening of the organization, which is usually discussed as though it were mainly a matter of cost or culture or speed, is revealed as something with much higher stakes. When an enterprise removes its middle layers, it is not only removing cost and the routing of information, though it is removing those. It is removing the substrate on which allocation, scheduling, permission, isolation, and accountability were running. If it removes that substrate without having built another one to take over the five functions, it has not modernized. It has decommissioned its operating system and kept the applications running, which is a thing you can do, for a while, in the same way you can drive a car after draining the oil.

This is, I think, the precise and unglamorous explanation for a pattern the previous essay described from the outside. Enterprises that deploy agents enthusiastically and then experience not transformation but a kind of expensive chaos, a proliferation of activity that does not cohere into outcomes, are not suffering from bad agents or bad models. They are suffering from a missing operating system. They have new applications, the agents, running on a machine whose operating system has been partly removed and not replaced. The agents are not the problem. The void where the governing layer used to be is the problem. And no amount of additional agent capability fills that void, because capability is an application-layer property and the void is at the layer below.

Remove the middle of the organization without building a successor and you have not modernized. You have decommissioned the operating system and left the applications running.

Which means the task in front of the enterprise is not, at root, an AI task. It is an operating-system task. The enterprise has to consciously design and build the layer that performs the five functions for a network of agents, the layer that the hierarchy used to be. This is buildable. The next two sections are about what it is actually made of. But it has to be approached as what it is, the deliberate construction of the institution's new governing machinery, and not mistaken for a procurement of more or better agents. The agents are the easy part. The agents are nearly a commodity. The operating system is the institution.

IV. The control plane

An operating system for agents is not a single product, and an enterprise should be suspicious of anyone selling it one. It is an architectural layer, and like the operating system of a computer it has an inside that can be described. The earlier essays in this sequence referred to this layer, in passing, as the substrate. It is time to stop referring to it in passing. Borrowing the term the cloud engineers use for the part of a system that governs the rest, I will call it the control plane. It is the part of the enterprise that does the governing, as distinct from the part that does the work.

The control plane has, at minimum, four components, and each one is the modern machine-scale version of something the hierarchy used to do with people and paper.

The first is identity. In the old enterprise, identity was for people; each employee had one, and the org chart said what each identity could do. In the agentic enterprise, identity has to extend to every agent, and there are about to be far more agents than employees. Every agent must be distinctly identifiable, must be traceable to the human or the team on whose behalf it ultimately acts, and must carry its identity with it as it moves between systems. This sounds like plumbing. It is in fact the foundation of the entire control plane, because nothing else, no permission and no audit, is possible if the actors cannot be told apart. An enterprise that lets agents act under shared or borrowed or human credentials has, at that moment, lost the ability to govern them, and everything it builds on top of that is built on sand.

The second is the permission system, the part that decides what each identity is allowed to do. The hierarchy did this with spending limits and approval chains and job descriptions. The control plane does it with an explicit policy engine, a single place where the rules about what agents may do are written, evaluated, and enforced. The crucial concept here is the authority envelope. An agent acting on behalf of a person should receive not that person's full authority but a deliberately narrowed slice of it, scoped to the task, and that slice should attenuate further, never widen, as the agent passes work to other agents and other tools. Authority flows downhill and loses volume as it goes. A well-built control plane makes that the default and the unbreakable rule, so that no chain of delegations, however long, can end with a minor agent wielding major authority.

The third is the scheduler and the resource governor, the part that decides which agents run, when, and against what share of a finite budget of computation and money and external rate limits. On a computer this is invisible and constant. In the enterprise it is new, and it is the component most often forgotten, because in the era of human work the equivalent function was hidden inside management and never named. A thousand agents, left to run whenever their logic says to run, will collide, overspend, and saturate every external system they touch. The control plane has to own the throttle. It has to be able to say, this class of work yields to that class, this budget is exhausted, this agent waits.

The fourth is observability and the audit trail, the part that records what happened. For every consequential action, the control plane must capture the acting agent, the human or team ultimately accountable, the authority under which it acted, and the result, in a form that can be reconstructed afterward by an auditor or a regulator or an executive trying to understand what went wrong. The hierarchy did this, imperfectly, with files and email and the memory of managers. At machine speed and machine volume, memory and email are not adequate, and the audit trail has to be designed in from the start, as a first-class component, because an audit trail is one of the very few things that genuinely cannot be added convincingly after the fact.

The agents are the applications. The control plane is the operating system. Whoever owns the control plane owns the institution.

Identity, permission, scheduling, audit. A control plane built from those four components is what allows a network of agents to be an institution rather than a pile of parts. And notice the relationship between this layer and the agents above it. The agents are where the intelligence is, and the intelligence is improving monthly, and is largely bought in, and is close to a commodity. The control plane is where the governance is, and it is specific to the enterprise, and it accumulates, and it does not commoditize. This is the same shape both earlier essays in this sequence kept arriving at, the commodity layer and the durable layer, the substrate and the platform, now in its sharpest and most literal form. The agents are the applications. The control plane is the operating system. And it has always been true, in computing and now in the enterprise, that whoever owns the operating system owns the system.

V. Governance is not a constraint on the system. It is the system.

There is a habit of mind, deeply ingrained in how enterprises run technology projects, that has to be broken before the rest of this essay can land. The habit is to treat governance as a constraint applied to a system from outside, after the system exists: you build the capability, and then governance, in the form of risk and compliance and audit, comes along and limits it. Governance, in this habit of mind, is the brake. The capability is the engine. The two are different in kind, and they are in tension, and more of one means less of the other.

For an operating system, this habit of mind is simply an error. Consider the computer operating system again. Its permission model, the rules about which process may touch which resource, is not a constraint added to the operating system after it works. It is one of the things the operating system most centrally is. Remove it and you do not have a faster, freer operating system. You have no operating system, you have the chaos that operating systems were invented to end. The governing and the functioning are the same thing. The permission model is not the brake on the machine. It is part of what makes the collection of components into a machine at all.

The enterprise operating system is exactly the same, and the five functions from earlier make it obvious once you look. Allocation is governance, it is the rationing of scarce resources under rules. Scheduling is governance, it is the ordered control of what runs. Permission is, transparently, governance. Isolation is governance, it is the containment of failure within boundaries. Even the stable interface is governance, it is the maintenance of an accountable surface. There is no part of an operating system that is not, when examined, a governing function. So when an enterprise says, as enterprises constantly do, that it will build the agentic capability first and add the governance later, it has said something that does not parse. It has said it will build the operating system first and add the operating system later. The governance is not a layer on top of the agentic enterprise. It is the layer that makes it an enterprise.

Build the capability now and add the governance later is not a sequence. It is a description of building the operating system, then building the operating system.

This reframing changes what the much-quoted governance problem actually is. Survey after survey through this period found the same alarming gap: the overwhelming majority of enterprises were running agents, and only a small minority, on the order of one in five, had any mature way to govern them. This is usually read as a warning that enterprises are being reckless, moving faster than their safety functions. That reading is true but shallow. The deeper statement of the same fact is that the overwhelming majority of enterprises have deployed applications onto an operating system they have not built. The governance gap is not a safety lag. It is a missing operating system, observed from the compliance department. And it will not be closed by the compliance department, because it is not, at root, a compliance problem. It is an architecture problem that shows up as a compliance problem, and it is closed only by building the control plane.

There is a hard-edged consequence of this for how an enterprise sequences its work, and it runs against the instinct of every organization that likes visible wins. The control plane, the operating system, has to be built before, or at the very least alongside, the agents that will run on it, never after. This is genuinely difficult, because the control plane on its own demonstrates nothing. It produces no headline, serves no customer, wins no quarter. It is pure foundation. An enterprise driven by quarterly visibility will always be tempted to build the visible agents first and defer the invisible foundation, and that exact temptation, indulged at scale, is the single most reliable way to assemble the expensive pile of parts. The enterprises that come through this well are the ones with the discipline, and the institutional courage, to spend real money and real time on a layer that will not show anything for a while, because they understand that they are not buying a feature. They are pouring a foundation, and you pour the foundation first.

VI. Where the human goes

An essay that has spent five sections building a machine now has to do the more important thing, which is to say where the human being stands once the machine is running. And the answer is not the consoling one that is usually offered, and it is not the bleak one either, and the gap between those two bad answers is where the truth is.

The consoling answer is that nothing essential changes, that people will simply be lifted up by their agents to do more of what they already do, freed from drudgery, their jobs enriched. This is the costume the earlier essay warned about, and it is false, because it imagines the operating system as a tool the human still operates, when the entire argument of this essay is that the operating system is the successor to the structure the human used to be a component of. The bleak answer is that the people are simply removed, that the network of agents and its control plane is the whole institution and the humans were scaffolding. This is also false, and it is false for a reason that is structural rather than sentimental, and the reason is worth getting exactly right, because it is the load-bearing point of this section.

Return to the control plane. It governs the agents. It allocates, schedules, permits, isolates, records. But notice what it cannot do. It cannot choose what the institution is for. It cannot decide which outcomes are worth pursuing, which risks are worth running, which customers the institution exists to serve, what the institution will refuse to do even when doing it would pay. It cannot supply the intent that the whole machine then executes. And it cannot be accountable, in the way that matters, for what the machine does. An audit trail can record which agent acted and under whose authority, but the authority has to terminate, finally, in a person, because accountability is not merely a record of causation. It is a thing a society holds someone to, and a society cannot hold an agent to it. Accountability has to come to rest on a human being, or it does not come to rest at all.

So the human role in the agentic institution is not the operation of the machine, and it is not absence from the machine. It is two things the machine cannot do, not by current limitation but by its nature, and they sit at the two ends of it. At the front end, the human is the author of intent. The human decides what the institution is trying to be, sets its purpose and its priorities and its refusals, and supplies the judgment, in genuinely novel situations, that no policy written in advance can supply. At the back end, the human is the holder of accountability. The human is the named person in whom the authority of a whole chain of agents finally terminates, the place where the institution becomes answerable to the world outside it. Author of intent at the front, holder of accountability at the back, and the operating system, the control plane and its agents, running between the two, executing the intent and generating the record by which the accountability is honored.

The machine can allocate, schedule, permit, and record. It cannot author intent and it cannot be accountable. Those two are the human role, and they are not small.

This is a smaller number of people than the old enterprise employed, and it would be dishonest, and a return to the costume, to pretend otherwise. The middle of the organization, the layer that existed to route and schedule and approve, is the layer the control plane most directly replaces, and the earlier essay was honest about the human cost of that and this one will not be less so. But the role that remains is not a diminished thing. It is a concentrated one. The people who author intent and hold accountability are doing the part of the institution's work that has the most consequence and the least precedent, and they are doing it with a machine underneath them that gives their intent more reach and their accountability more evidence than any executive in the era of the human hierarchy ever had. The job is bigger. There are fewer of them. Both of those are true, and an honest account holds both.

And there is a second human place in the system, less elevated and just as real, which honesty requires naming. Between the author of intent and the holder of accountability, the running machine throws off a constant stream of exceptions, the situations its policies do not cleanly cover, the judgment calls, the genuinely new cases. Someone has to stand at those points. This is the work of exception and judgment, and it is human work, because it is exactly the work that cannot be reduced to a policy in advance, since if it could be it would already be inside the control plane. This is not routing work and it is not approval-chain work, the work the machine absorbs. It is the work of handling what the machine, correctly, refers upward because it was built to know the edge of its own competence. That work is real, it is skilled, and it is not going away. It is, in fact, the day-to-day texture of working inside an institution whose operating system is no longer made of people.

VII. The operating system you do not own

Everything to this point has described what the enterprise operating system is. The final question, and the one with the most money and the most consequence attached to it, is who builds it, and therefore who owns it. Because an enterprise has two ways to acquire an operating system, and they lead to different futures.

The first way is to build it. To treat the control plane, the identity and the policy engine and the scheduler and the audit layer, as core institutional infrastructure, owned and understood and controlled by the enterprise itself, in the way that a country treats its own law. The second way is to inherit it. To take the operating system that a large platform vendor is, right now, extremely keen to supply, prebuilt and integrated and convenient, and run the enterprise on it. The major platform companies have all, in the space of about a year, moved to offer exactly this: a ready-made governance layer for agents, a control plane as a product, sometimes generously described as an open ecosystem and sometimes frankly described as a perimeter. The offer is real and the convenience is real. And an enterprise that accepts the offer without thinking about what it is accepting has made the most consequential architectural decision of its next decade without noticing that it made a decision at all.

Here is the stake, in the plainest terms I can manage. The operating system is the layer that governs the institution. If the enterprise owns that layer, then the agents above it are commodities the enterprise can swap, the models underneath are commodities the enterprise can swap, and the vendors on every side are suppliers the enterprise can play against one another, because the enterprise owns the one layer that does not commoditize, the governing layer, the place where its rules and its identity and its accumulated institutional memory live. If instead the enterprise runs on an inherited operating system, then the most important layer of the institution is owned by someone else. The enterprise's agents authenticate against a vendor's identity service. Its rules are expressed in a vendor's policy engine. Its audit trail lives in a vendor's system. Its institutional memory accumulates inside a perimeter it does not control. The switching cost is not a year of migration. It is the institution itself, because the operating system is not a thing the institution uses. It is the thing the institution is.

An operating system is not a thing the institution uses. It is the thing the institution is. Renting one is not a procurement decision. It is a sovereignty decision.

I want to be fair to the inherited option, because the essay is not an argument that every enterprise must build. For a smaller organization, or one whose ambitions are modest, or one in a domain where the regulatory and competitive stakes are low, running on a well-built vendor operating system is not only acceptable, it is sensible, in the same way that most companies quite rightly run on cloud infrastructure they do not own. The error is not inheriting an operating system. The error is inheriting it without knowing that is what you are doing, mistaking a sovereignty decision for a procurement decision, and discovering the difference only later, when the rent is raised, or the perimeter tightens, or the institution wants to do something its landlord's operating system was not designed to allow. The decision is legitimate. Making it unconsciously is not.

This is also the point at which this essay's argument rejoins the argument of the first one, the one made at the altitude of the whole industry. That essay watched the work surface move and the software vendors maneuver, some of them dissolving into the new layer, some of them building perimeters to capture it, and it described an unsettled and high-stakes contest among the vendors. This essay has been standing inside a single enterprise looking at the same event from within. And from within, the vendors' contest is not a spectator sport. It is a question delivered to the enterprise's own door, and the question is: when the operating system of your institution is being decided, are you a participant or a tenant. The enterprise that built its own control plane is a participant. It can take the best of what the vendors offer and refuse the rest, because it owns the layer that gives it the standing to choose. The enterprise that inherited its operating system is a tenant, and a tenant does not set the terms.

VIII. What could prove this wrong

The argument of this essay is strong, and a strong argument earns trust by being honest about where it could fail. There are four places, and they are not weak ones.

• The operating system might come standardized, like the internet did. I have argued that owning the control plane is owning the institution. But some foundational layers do not get owned by anyone; they become open standards, public and free, the way the basic protocols of the internet did. If the agentic operating system standardizes that way, into open and shared identity and permission and audit protocols that no vendor controls, then the build-versus-inherit question softens considerably, because inheriting an open standard is not the same as renting a private perimeter. There are early signs of standardization in this direction. There are also powerful incentives for vendors to prevent it. I do not know which wins, and it matters.

• The hierarchy might be more resilient than the essay assumes. I have written as though the human hierarchy is clearly going. In many enterprises it is proving stubborn, for reasons that are not all bad: regulation, culture, the genuine difficulty of the change, and the fact that a hierarchy of experienced people is a very good operating system, refined over a long time. It is possible the human operating system persists, in modified form, for much longer than this essay implies, running alongside the agentic one rather than being replaced by it. If so, the institution of the next decade is a hybrid of two operating systems, and this essay has described only one of them.

• Accountability might be absorbed in ways I have not foreseen. The claim that accountability must terminate in a human is doing a great deal of work in section six. It is grounded in how societies and legal systems currently assign responsibility. But those systems can change. If law and norm evolve to assign a form of accountability to artificial agents themselves, or to the enterprise as a pure abstraction with no specific human at the end of the chain, then the human role I have described as structurally permanent becomes contingent after all. I think this is unlikely within the horizon that matters for present decisions. I do not think it is impossible.

• The whole operating-system frame might be too neat. The five functions, the control plane, the clean analogy to computing: it is an orderly picture, and real institutions are not orderly. It is possible the analogy, like all analogies, holds until it does not, and that the agentic enterprise turns out to have a governing layer that looks much stranger than an operating system, something with no good precedent in either computing or organizational history. If so, this essay is a useful first approximation that a later and better one will correct. That is the normal fate of first approximations, and it would be no disgrace.

My honest weighing of these is that the first is the one to watch most closely, because it is the one that could most change what an enterprise should do right now, and it is genuinely undecided. The second is real but slow. The third and fourth are the kind of deep uncertainty that should make a writer humble without making a decision-maker paralyzed. None of the four dissolves the core of the argument, which is narrow and, I think, durable: a network of agents is not an institution, something must perform the governing functions the hierarchy used to perform, and that something is an operating system whose ownership is the decision that matters most. The shape of that operating system, and who ends up owning it, is still being settled. That it is needed is not.

IX. The institution that runs itself

Let me end by drawing the three essays of this sequence together, since this is the one that completes their arc, and then by saying the one thing that is genuinely new in it.

The first essay said the old structure is dissolving. The second said the enterprise is being reconstituted, a new interaction-based institution rising on top of a reconstituted system of record. This third essay has tried to describe the machinery that makes the reconstituted thing an institution rather than a pile of parts: an operating system for agents, a control plane that allocates and schedules and permits and isolates and records, the deliberate successor to the structural work the hierarchy used to do. Dissolution, reconstitution, and the building of the new institution's governing machine. That is the arc, and an enterprise that has followed it is no longer asking whether the transformation is real. It is asking what to build, and in what order, and how much of it to own.

Here is the new thing, the thing that was not visible from the earlier altitudes and is the reason this essay had to exist. We have tended to imagine the endpoint of all this as either a workforce with better tools or a company run by artificial intelligence, and both of those images are wrong, and they are wrong in the same way. They both still picture a company of the old kind, with either the tools or the workers swapped out. The actual endpoint is stranger and more specific. It is an institution whose operating system is no longer made of people. For the entire history of the corporation, the thing that turned a crowd into a company, the allocating and scheduling and permitting and accounting, was performed by human beings arranged in a structure, and we never saw it clearly because it was made of the same material as ourselves. The agentic enterprise is the first institution in which that governing layer is made of something else. The people are still there, and they are doing the things the machine cannot, authoring its intent and holding its accountability and standing at its hard exceptions. But they are not the operating system anymore. They sit at the edges of an operating system, and the operating system runs.

That is a genuinely new kind of institution, and it deserves to be approached with neither the salesman's enthusiasm nor the mourner's dread, but with the seriousness owed to a structural change in something as consequential as the institution. The leaders who will navigate it well are not, I think, the ones with the boldest vision or the most aggressive timeline. They are the ones who understand what they are actually building, which is not a fleet of agents and not a faster company but the governing machinery of an institution that will run for a long time after they have left it. That has always been the quiet definition of institutional work: building the structure that outlasts you. It is what founding a company, or a bank, or a library, always meant. The material is new. The machinery is made of identity systems and policy engines and audit trails now, rather than reporting lines and approval chains and the judgment of managers. But the task underneath is old, and it is the oldest task there is in the building of any institution. Decide what the thing is for. Build the structure that will carry that purpose. Make it accountable. Then hand it on.

The hierarchy is gone, or it is going. The thing that replaces it is not nothing, and it is not magic, and it is not the agents. It is an operating system, and it is being designed right now, in most enterprises without anyone admitting that is what they are doing, and in a few with full awareness. The difference between those two kinds of enterprise will turn out to be one of the largest differences there is. The work is to see the task clearly and then to do it on purpose. That is all. That has always been all. It has never been easy, and it is not easy now, and it is, still and again, the work.

A note on sources

This essay draws on the public record of enterprise AI and agent infrastructure as of May 2026. The account of the enterprise control plane, agent identity, delegated and attenuating authority, action gating, and audit draws on the agent-governance and agent-identity work published through 2025 and 2026 by the major cloud and platform vendors and by the open agentic-interoperability efforts, including the move of the Model Context Protocol to independent foundation governance. The observation that the great majority of enterprises run agents while only a minority have mature governance for them reflects industry survey work by Deloitte and others through early 2026, and should be read as directional self-report rather than audited fact. The five-function description of an operating system is standard in computer science and is used here as an analytical frame. The control-plane and operating-system framing of the enterprise, the reading of the hierarchy as the prior operating system, the author-of-intent and holder-of-accountability account of the human role, and the build-versus-inherit argument are the author's own. The direction of travel is, in my view, hard to ignore. The pace, the degree of standardization, and the identity of the eventual owners of the agentic operating system remain genuinely uncertain.

Where this essay begins. An earlier essay argued that the application layer of the enterprise is dissolving. Not collapsing, not being torn out, but quietly hollowing while its outward form persists, as the work surface moves to a new layer of agentic software above it. That is the event. This essay takes that event as given and asks the question that follows from it. If the old structure is dissolving, what is the enterprise becoming? The answer is not a repaired version of the old thing. It is a different kind of institution, built alongside the one that is dissolving, serving the same purpose through an entirely different medium. This essay is about that institution, why it has to be built new rather than renovated, and what it asks of the people running it.

Every large enterprise is now trying to become AI-native, and almost all of them are failing, because they have misunderstood what kind of change it is. They are treating it as a renovation of the institution they already have. It is not a renovation. It is the founding of a second institution, with a different unit of value, that becomes the new front of the enterprise, while the old institution does not close but is reconstituted beneath it as the system of record the new front depends on. The two run in parallel permanently, because that is the architecture. This essay offers a single frame for seeing it clearly. The frame is a library.

I. The split that should be a scandal

Begin with the pattern that should be unsettling more executives than it is. Across three years of effort, hundreds of billions of dollars of corporate spending, and a degree of executive consensus that borders on unanimous, enterprises have not converged. They have split. A small group of companies is pulling clearly ahead, capturing real and compounding financial value from artificial intelligence. A much larger group is spending heavily and getting motion without much result. And the distance between the two groups is not closing. It is widening.

The split shows up wherever anyone looks for it carefully. Boston Consulting Group has tracked enterprise readiness for several years, and segments a small leading group, on the order of one company in twenty, that captures a large share of the value, against a long tail that does not, with the gap between them widening rather than narrowing across successive years of the study. McKinsey's surveys of its own client base find that a great many organizations now use AI somewhere in the business, while only a small minority qualify as genuine high performers by the test that matters, which is real earnings rather than activity. Deloitte, surveying several thousand executives across two dozen countries, found enterprises sorting into rough thirds: roughly a third using AI to transform how work is actually done, roughly a third redesigning some key processes, and the rest using AI at the surface, with little real change underneath. These are survey findings and leader self-report, and they should be read as directional rather than audited. But they are independent of each other, they use different methods, and they point the same way. Most enterprises are spending real money and changing very little. A few are changing in kind. And the few are pulling away.

Now the detail that makes the split structural rather than embarrassing. The gap between the small group capturing value and everyone else is not closing. It is widening. If this were a normal technology adoption curve, the laggards would be catching up as the tools matured and cheapened. The opposite is happening. Whatever separates the leaders from the rest, it is not a head start the field is closing. It is something the few understood and the many did not, and the cost of not understanding it compounds every quarter.

If this were a normal adoption curve, the laggards would be catching up. Instead the gap is widening. That tells you the difference is not time. It is comprehension.

This essay is an attempt to name what the few understood. I want to state the answer plainly at the outset, because the rest of the essay is its defense. The companies pulling ahead understood that becoming AI-native is not a renovation of the enterprise they already had. It is the founding of a second enterprise. The companies falling behind are pouring money into upgrading the old institution, and the upgrade does not produce the new thing, because the new thing is not an upgrade. It is a different kind of institution, and you do not get it by improving the old one. You get it by building it.

To make that claim concrete enough to act on, I am going to spend the essay inside a single image. I have tried a number of frames for this transition, and most of them mislead in ways that have cost real leaders real time. The one that holds is the library. It is worth drawing it in full, because once it is fully drawn, almost every hard decision a leader faces becomes legible.

II. The library, fully drawn

Imagine you run one of the great public libraries. It has been a century in the making. Its purpose is straightforward: to give people access to knowledge for their own reasons, to learn, to work, to research, to be entertained, to decide. It serves all of them. The professional comes for the reference she needs that morning. The researcher comes to spend three years inside a single question. The student comes because someone has set him reading. The journalist comes for today's periodicals and will be back tomorrow for tomorrow's. The library is not valuable because of the books on its shelves. It is valuable because of the readers it serves. The books are the means. The readers are the point.

The institution is organized around one particular medium of knowledge. The unit of value is the fixed artifact: a book, written once, printed many times, identical for every reader, found through a catalogue, read from beginning to end, finished or abandoned. Everything about the institution follows from this. The acquisitions process, the catalogue, the conservation department, the reading rooms, the rules about who may borrow what, the very measure of success, all of it is shaped by the fact that the unit of value is the artifact. The institution is excellent at what it does. It has been excellent for a hundred years.

Now imagine the way people want knowledge begins to change. Not the knowledge itself; the underlying corpus of what is known and worth knowing is roughly the same. What changes is the experience people expect. They no longer want, as their default, to walk into a quiet room, work a card catalogue, find a book on a shelf, sit down, and read it through. They want to ask a question and have an answer come back shaped to that question. They want to choose whether the answer arrives as text, as audio, as a summary, as a deep dive. They want it pitched to their level of expertise, in their language, for the context they are asking from. They want to follow up. They want it now. They want it to remember what they asked yesterday. They want it to say when it does not know.

You are asked to stand up an institution that serves these readers. Not a new wing of the old library. A different kind of institution, delivering the same underlying purpose through a wholly different medium. Its unit of value is not the artifact. It is the interaction: the exchange, generated in the moment, shaped to who is asking and why, delivered in the form that serves them best, built on the assumption that they will follow up. Different skills. Different unit of value. Different definition of quality. Different relationship to the reader. The two institutions share a purpose. Almost everything else about them is different.

Here is the part that makes the situation hard, and it is the part most leaders get wrong. The old library does not close. Most of its readers still prefer it. They have spent decades learning to use it, and the fixed artifact and the quiet room and the linear read are not deficits to them, they are the experience they came for. The new institution, however well built, will feel foreign to them, and many will not switch. Meanwhile the readers arriving for the first time will mostly not come to the old library at all. The new institution is simply what they expect knowledge to feel like. They have never known anything else.

So the leadership has been handed a task with an unusual structure. They must keep the old library running for as long as it has readers. They must build the new institution alongside it. They must split investment between the two, hold the trust of two different populations at once, develop two different sets of skills, carry two definitions of quality, and report to their trustees against two different measures of success. They must do all of this knowing that for a long time the new institution will look small beside the old one, and that failure to invest in it will look like nothing at all, right up until the readers have quietly moved on and the old library is empty. There is no closing date. The two institutions run in parallel. The dual-running is not a phase. It is the work.

There is no closing date. The new institution is not a project that finishes. It is a second institution, and the running of both at once is the job from now on.

That is the situation every serious enterprise is now in. Not a migration. Not a transformation program with a target state and a final report. The standing-up of a different kind of institution, alongside the existing one, serving the same customers through a different kind of experience, and the running of both in parallel for as long as both have customers who prefer them. The word for this is not reconstruction. Reconstruction would mean building the old thing again. It is reconstitution: the same purpose, the same underlying corpus of value, reconstituted into an institution of a different kind.

III. Why a new institution, and not a renovation

The instinct of every well-run enterprise is to resist this. A new institution is expensive, frightening, and politically costly. Surely, the instinct says, we can get there from here. We have a good institution. We will modernize it. We will bring AI into the library.

This instinct is the single most reliable way to end up in the group that is falling behind, and it is worth being precise about why, because the reason is not obvious. The reason is not that the old institution is bad. It is that the old institution is excellent, and its excellence is the problem. Every part of it, the catalogue, the skills of its staff, the definition of quality, the measure of success, the layout of the rooms, has been refined for a century around the artifact. That refinement is real and it is deep. And it means that when you try to host the new, interaction-based service inside the old institution, the old institution's excellence quietly bends the new service back into the old shape. The new service gets catalogued. It gets measured by artifact-era metrics. It gets staffed by people whose deep skill is artifact production. It gets governed by rules written for borrowing books. None of this is stupidity. It is the gravitational pull of a well-built institution, and it is strong enough that the new thing, grown inside the old, comes out as a slightly better old thing.

This is what surface adoption actually is. The large group of enterprises that Deloitte finds using AI with little change to their processes did not fail to work hard. Many of them worked very hard. They brought AI into the library. They added the new tool to the old institution, and the old institution did what excellent old institutions do, which is to absorb the new tool into its existing shape and carry on. The result is an institution that has spent a great deal of money to become a marginally faster version of what it already was, while believing it has transformed.

There is a deeper version of the same mistake, and it is worth naming because the people who make it are often the most capable. They accept that the change is real and they decide to do the hard thing. They are going to rewire the institution from within. Rebuild the workflows, restructure the teams, re-skill the staff. And here is the subtle point. If they actually do that, all the way, honestly, they will look up at the end and discover that they have not rewired the old institution at all. They have built a new one. The workflows are not the old workflows repaired. They are different workflows. The teams are not the old teams retrained. They are differently shaped teams doing differently defined work. The thing they have built is not continuous with the thing they started with.

Which means that rewiring in place, done honestly and completely, produces exactly the same destination as deliberately founding a new institution. The two paths converge. So the only real question is whether you name the destination at the start or discover it at the end. And naming it at the start is strictly better, for a reason that is the whole argument of this section. If you tell yourself you are renovating, you will, every single day, make the small decision that protects the old thing. You will treat the existing process as the requirement. You will treat the current org chart as the constraint. You will treat the established metric as the target. Each of those small decisions is locally reasonable and collectively fatal, because together they bend the new institution back into the old shape before it is ever born. If instead you say, plainly, on day one, we are building a new institution here, nothing about the old one is automatically preserved, then every one of those small decisions is reopened. The renovation framing forecloses the choices that the new-institution framing keeps open. That is why the framing is not a matter of motivational language. It is the difference between the enterprises that pull ahead and the enterprises that do not.

Rewiring honestly and founding deliberately reach the same place. The only question is whether you name the destination on day one or discover it on the last. Naming it is strictly better.

Reimagine, then reengineer, then rewire, and in that order, because the order is the discipline. The failure mode is to start at rewiring, because rewiring feels like progress, it produces visible motion. But rewiring without the reimagining means you have changed the wiring of a process you never stopped to question, which is bolt-on wearing the costume of transformation. The reimagining has to come first. You decide what the institution is for and what it would look like if built today, from nothing, for the readers you actually have now. Then you engineer that. Then you wire it. An enterprise that starts at the wiring has smuggled the entire old institution back into the project as the thing being rewired, and it will get, predictably, a rewired old institution.

IV. The medium change, in detail

Everything in the library frame rests on one proposition, and the proposition deserves to be worked through carefully, because every other claim follows from it. The proposition is that the unit of value has changed. The old institution's unit of value is the artifact. The new institution's unit of value is the interaction.

An artifact is written or produced once, distributed many times, identical for every consumer, found through a catalogue, consumed in sequence, and then finished or abandoned. The digital enterprise is built entirely from artifacts. The report, the dashboard, the policy document, the contract, the case file, the customer record, each is produced once, consulted many times, the same for everyone who opens it, navigated through some descendant of the catalogue, a search bar, a folder tree, a saved query. The skills of the digital enterprise are the skills of producing good artifacts: writing the report, designing the dashboard, drafting the contract, maintaining the system of record. Productivity means the rate of artifact production. Quality means the artifact is accurate, well-built, and durable.

An interaction is something else entirely. It is generated in the moment, shaped to who is asking and why, delivered in whatever form serves them best, and built on the expectation that the asker will follow up. The AI-native enterprise, when it is working, is organized around interactions. The customer's conversation with the institution. The employee's answer to a question never asked in quite that way before. The decision support that responds to the specific case in front of it. The skills are the skills of designing interactions: understanding the asker, shaping the response, judging quality in a medium where every response is bespoke and then gone. Productivity means asks answered well. Quality means this asker, in this moment, was genuinely served. The artifacts still exist. The new institution still produces reports and records, and it still depends on a corpus of them. What changes is that the artifact is no longer what the customer comes for. The interaction is the front of the institution now. But an interaction generated in the moment and then gone cannot, by itself, be an institution, and the next section is about what it still needs underneath it.

Five things follow from this one shift, and each is a place where enterprises stumble because they have not named the shift directly.

The skills change in kind, not degree. The workforce of an institution built around artifacts and the workforce of an institution built around interactions are not the same workforce with different software. They are different workforces. This is why the reflexive response of treating AI as a training problem, sending the existing staff on a course, falls short. Training upgrades a workforce within its existing kind. The medium change asks for a different kind. When a recent survey of executives found that the most common talent response to AI was education, what it revealed was an industry diagnosing a change of kind as a change of degree.

Quality means something different, and the difference is hard to hold. An artifact is judged on whether it is accurate, well-made, authoritative. An interaction is judged on whether it served this particular asker's actual need in this particular moment. The same underlying knowledge can be perfectly delivered for one asker and badly delivered for another, and both judgments are correct at once. An institution that has spent a century building the muscle to judge artifact quality does not automatically have the muscle to judge interaction quality. It has to build it, deliberately, as a new capability.

The reader's relationship to the institution changes. In the old library the reader is a consumer of finished work. In the new institution the reader is a participant. What they ask shapes what they get. Their context shapes the response. Over time the institution comes to know who they are. That is a different relationship, and the privacy posture, the consent regime, the institutional ethics, all of it has to be designed for participation rather than consumption. It is not the old relationship with faster service. It is a new relationship.

The competitive ground moves. The old institution competed on the size of its collection, the quality of its artifacts, the reliability of its catalogue. The new institution competes on the quality of its interactions. And this is why a small, well-built new institution can beat a vast old library that has merely been fitted with AI tools. The readers go where the experience is better, not where the collection is larger. The widening gap between the leaders and the rest is this, measured: the ground moved, and only the institutions that understood the move are competing on the new ground at all.

The economics invert. The artifact institution had high fixed costs of production and low marginal costs of distribution; you paid to write the book, then printing and lending were cheap. The interaction institution has low fixed costs of artifact production, since the underlying knowledge is largely already there, and high marginal costs of interaction, since every response consumes computation and every conversation is bespoke. A leader who treats AI as a fixed-cost investment to be made once and amortized is using the wrong economic model, and the wrong economic model will produce the wrong decision at every budget cycle.

The old institution's unit of value is the artifact. The new institution's unit of value is the interaction. Everything that is hard about the transition is downstream of this one sentence.

V. Why the library cannot close

There is a temptation, once the medium change is clear, to assume the old institution is simply on its way out. The interaction is the future, the artifact is the past, and the library survives only as a courtesy to the readers who have not yet adjusted. Hold the new institution steady, wait, and one day the last artifact-preferring reader is gone and the old library can finally close.

This is wrong, and it is wrong in a way that matters, because it leads a leader to underinvest in the one part of the institution that everything else depends on. The old library does not survive as a courtesy. It survives because the new institution cannot exist without it. And the reason is in the nature of an interaction itself.

An interaction is generated in the moment and then it is gone. That is its strength; it is shaped to one asker, one context, one need. It is also, by itself, a kind of amnesia. An interaction captures nothing. It records nothing. It leaves no corpus behind. If an enterprise were nothing but interactions, it would have no memory, nothing to generate the next answer from, nothing to check an answer against, nothing that persists between one conversation and the next. The interaction layer, for all that the customer experiences it as the whole institution, is standing on something. It is standing on a system of record: a maintained, governed, persistent corpus of what is true, what was decided, what happened, what is known. The library is that system of record. It is not the old medium waiting to die. It is the foundation the new medium runs on.

An interaction captures nothing and records nothing. An enterprise that was only interactions would have no memory. The library is the memory.

This reframes the two institutions, and the reframe is important enough to state precisely. They are not two peers running side by side until one of them wins. They are a stack. The interaction institution is the front: it is what the customer comes to, the surface where the value is delivered. The corpus institution is the back: it is where information is captured, validated, recorded, and kept. The front cannot stand without the back. Dual-running is not a tense coexistence with a hidden finish line. It is the architecture. The library cannot close because the thing that replaced it is built on top of it.

Notice what this does to the old institution's century of accumulated skill. The earlier sections of this essay treated that skill with suspicion, as a gravitational pull that bends the new service back into the old shape, and as a warning that remains true. But the skill is not waste. The work the great library always did, the documenting, the cataloguing, the validating, the establishing of provenance, the judgment of whether a source is reputable and an article genuine, is precisely the work the back of the new institution requires. The skill is not obsolete. It is relocated. It moves down the stack, from a front office where it used to face the reader directly, to a back office where it now faces the interaction layer and feeds it. The librarian's craft does not disappear in the AI-native enterprise. It becomes foundational, and it stops being visible to the customer, which is a different thing from becoming worthless.

And here is the part that turns the whole intuition around. You might expect that in an age of generative abundance, when machines can produce plausible text on any subject at no cost, the maintained corpus would matter less. The opposite is true. The world is now flooded with generated content: synthetic text, machine-made images, plausible and unsourced and unverified material produced at a volume no prior era could have imagined. Some of it is slop and some of it is genuinely good, but very little of it arrives with its provenance attached. Information has stopped being scarce. What has become scarce, and therefore valuable, is information you can trust: validated, sourced, genuine, maintained, vouched for. An interaction layer is only as good as what it can reach for, and a good interaction layer has to reach for something it can trust. That trusted thing has to be built and maintained by someone doing the patient back-office work of curation and validation. The flood of AI content does not shrink the need for the library. It is the strongest argument for the library that has ever existed.

There is one more reason the library endures, and it is about the world beyond the single enterprise. The institution is not only serving its own readers. It is also a destination where others come to deposit and share information. Publishers still publish. People and organizations still produce records, filings, research, accounts of what happened. The global marketplace of information is still, for the most part, a marketplace of artifacts produced by humans and human institutions. It may one day become natively agentic, an interaction-to-interaction world with no artifacts in between, and that is worth watching, but it is not close, and an enterprise cannot build for a world that does not exist yet. For as long as the wider world supplies information in the form of artifacts, the enterprise needs an institution that can receive them, validate them, and hold them. The library is that institution. It is not a relic. It is the enterprise's connection to a world that still runs on records.

So when this essay says there is no closing date, it is no longer making a claim about the patience of legacy readers. It is making a claim about architecture. The library cannot close because it is load-bearing. The interaction is the front; the corpus is the foundation; and a foundation is not a phase.

VI. Dual-running is the permanent condition

The previous section established the deepest reason the two institutions run in parallel: the corpus is the foundation the interaction layer stands on, and a foundation does not get retired. But there is a second reason, and it operates on a faster clock, so a leader has to plan for it directly. It is the readers.

The old institution's readers are still there. Most still prefer the artifact-based experience for at least some of what they need. They are paying customers, they are often the most profitable segment, they are politically organized, and they cannot be ordered into a medium they did not choose. The new institution's readers are growing quickly but are not yet, in most enterprises, the majority. Force the old readers into the new experience before they are ready and you get the most familiar failure in the public record, the premature switchover that has to be loudly reversed. Close the old front office early and you lose readers who do not come back. Refuse to build the new one and you lose the readers who never arrive. Both errors are visible, repeatedly, in the data. The only stable posture is to run both, deliberately, and let readers cross at the pace they choose. So the enterprise runs two institutions for two reasons at once: the corpus must exist because the interaction layer is built on it, and the old front office must keep running because its readers have not all crossed. The first reason is permanent and architectural. The second is long but not unending. Together they put dual-running beyond any planning horizon a leader actually operates on.

This has consequences that the usual transformation language is not built to carry, and they are worth stating one at a time, because each is a decision a real leader has to make.

Capital is split between two institutions, not allocated to one program. The old institution generates most of today's revenue and has to be maintained to the standard its readers expect. The new institution will generate most of tomorrow's revenue and has to be built at a pace the leadership can defend to the people funding it out of the returns of the old. That is a portfolio decision between two institutions with different time horizons and different return profiles. It is not a budget line for a transformation initiative, and calling it one produces chronic underfunding of the new institution, because a budget line gets cut when this quarter is hard and a second institution does not.

The workforce has to be built for both. The old institution's staff are needed for as long as it has readers. The new institution's staff have to be developed from a different base of skill. And the movement of people between the two has to be planned, deliberately, because the two workforces are not interchangeable and the people crossing from one to the other are making a real transition that the enterprise either supports or fumbles. This is the honest center of the human cost, and it should not be smoothed over. Becoming AI-native moves people across a threshold from one kind of work to another. Some make the crossing into the new institution. Some remain, valuably, in the old one for as long as it runs. Some find that the work they did is now done differently and that the institution owes them a real answer about what comes next. A leader who pretends this is only upskilling is not being kind. They are postponing the moment of honesty and making it more brutal when it comes. The change-management craft the enterprise already has, the disciplined sequence of building awareness, then desire, then knowledge, then ability, is the right craft for this. It is simply being asked to do something heavier than it has done before: not move people to a new tool, but carry them across to a new institution.

The board has to be shown both. The old institution's metrics are the ones the board knows: revenue, margin, cost ratios, retention. The new institution's metrics are different in kind: interaction quality, trust earned, customers served better than the old institution could have served them, leading indicators of revenue that has not arrived yet. Report only the old metrics and the new institution looks like a cost center that should be cut. Report only the new ones and the leadership looks like it has abandoned the business that pays the bills. The frame that holds is the portfolio: two institutions, each reported against its own measure, with the leadership accountable for the whole.

Even the regulator has to be met twice. The old institution sits inside a regulatory perimeter built around the artifact: model risk rules for credit decisions, audit trails for transactions, content standards for what is published. The new institution operates in a regulatory environment still being written. The leader has to hold both compliance postures inside one organization at the same time. This is genuinely difficult. It is also simply the work, and the work does not get less real by being difficult.

VII. What the frame tells a leader to do on Monday

A frame earns its keep only if it makes the next decision clearer. The library frame does, and the guidance it gives is specific enough to act on this quarter. Six things follow.

Fund the spine before the catalogue. The new institution needs a foundation before it needs visible services: the layer that lets agents act, that holds identity for both people and machines, that carries the semantic data and its access controls, that records what was done and on whose authority, that governs what an agent is permitted to do under what conditions. This foundation is unglamorous and it produces no headline on its own, and so it is exactly what an enterprise chasing visible wins underbuilds. The result is the most common technical failure in the data: enterprises running large numbers of agents while almost none of them can govern those agents, because they built services on a foundation they never poured. Build the foundation first. The services are downstream of it. This foundation, and the operating system it amounts to, is large enough and important enough to be its own subject, and it is the subject of the next essay in this sequence. For this essay it is enough to say: it comes first, and it is permanent.

Start where the new medium is most obviously better. Serve first the readers whose need for an interaction is most concrete and whose value is easiest to measure. In most enterprises that means the back-office work where the return is well documented: the financial close, contract review, technology service management, high-volume customer service. Pair that with one or two customer-facing domains where the case for the new institution is visible to the outside world. The reverse order, attempting the deep customer-facing reimagination before any back-office win has established credibility, is one of the most reliable ways to lose the organization's confidence before the institution is real.

Reimagine the workflow from a blank sheet, and never measure it by adoption. Each domain the new institution takes on should be rebuilt by asking what the process would be if designed today, not how the existing process could be made faster. The accountable owner should be the business executive who owns the outcome, not the technology function. And the measure of success should be a business result, cycle time, throughput, error rate, a customer outcome, never a technology metric like seats filled or queries run. Counting licenses issued and weekly active users is the new institution's version of counting books on the shelf while the reading room sits empty.

Treat fluency as institutional investment, not remedial training. The workforce of the new institution has to be genuinely capable in the new medium, and that capability is built, not assumed. But it is not built by a training course bolted onto the side. The enterprises that have done this well, the ones whose programs ran into thousands of people and tens of thousands of genuine hours, treated fluency as a flagship investment in the institution's future capacity and reported it that way. The leading indicators are not course completions. They are depth of use, the production of reusable assets, the emergence of people fluent in both the domain and the new medium. Fluency is one leg of the institution. It is not the institution, and it is not a substitute for the structural work, but the structural work fails without it, because a workforce that is not fluent routes around the sanctioned institution and rebuilds the old one in the shadows.

Measure the new institution in readers, not artifacts. The metrics that matter are customers served better than the old institution could have served them, decisions made faster against a real counterfactual, errors avoided, trust earned where trust could have been lost. The enterprises that measure value honestly do it against a counterfactual baseline, a genuine comparison with what would have happened without the new institution. The enterprises that measure it dishonestly quote a headline percentage with no method behind it. By now that second kind of number should be easy to recognize. It is a projection wearing the costume of a measurement.

Stop running a program. Run a portfolio. This is the reframe that carries all the others. A leader running a transformation program has a target state and a closing date and a final report. A leader running a portfolio of two institutions has a permanent responsibility for both and is measured on whether the enterprise, a decade from now, is serving its customers well. The second is the truthful description. The board reporting, the executive incentives, the succession planning, the strategic plan, all of it should be built for the portfolio. The transformation program, as a category, should be retired. It describes a thing that is not happening.

A program has a closing date. An institution does not. The most important reframe a leader can make is from running a program to running a portfolio of two institutions.

VIII. What would make this frame wrong

A frame that cannot be wrong is not a frame, it is a comfort. The library frame makes claims that can fail, and a leader leaning on it should know where the failure points are.

• The medium change might not be the deepest change. I have argued that the move from artifact to interaction is the unit of analysis that matters most. It is possible that the deeper change is agentic autonomy specifically, the delegation of authority to machine principals, rather than interaction more broadly. If that is so, a frame built around delegated authority and machine accountability would serve a leader better than one built around the reader's experience. The current evidence supports the interaction framing, but this is the most credible challenger and it should be watched. It is also, not coincidentally, the subject the next essay takes up.

• The dual-running window might be shorter than the frame assumes. The whole portfolio posture rests on the old institution keeping a material population of readers for a long time. That has held so far. It might not hold. If a new generation of customers refuses the old institution outright, and refuses fast, the parallel-running window could collapse from decades to a few years, and a frame built for patient dual-running would leave a leader moving too slowly. The thing to watch is the rate of customer migration over the next three years. If it accelerates sharply, the frame needs revisiting.

• In-place transformation might turn out to be real. I have argued that the new institution must be built alongside the old, because the old institution's excellence bends any in-house renovation back into the old shape. If the record comes to show enterprises that genuinely became the new institution by internal evolution alone, with no parallel construction, then the dual-institution claim is too strong. So far the evidence does not show this; every credibly transformed incumbent in the public record built the new alongside the old. But it is a falsifiable claim, and the honest move is to say so and watch for the counter-example.

• The frame may be overfitted to large, regulated incumbents. The library frame is built for the leader of a substantial institution with an installed base, a regulated perimeter, and a balance sheet to protect. For a small enterprise, or a digital-native firm already partly built around interactions, or a sector with a weak regulatory perimeter, the dual-running constraint may be much looser than the frame implies, and a more aggressive single-institution build may be correct. The frame is a tool for a particular and common situation. It is not a law.

My honest assessment is that the first of these is the one most likely to matter, because it is less a flaw in the frame than a pointer to what the frame does not yet cover. The library frame describes the institution the enterprise is becoming. It does not fully describe the machinery that institution runs on. That machinery, the operating system of the new enterprise, the thing that holds a network of agents together into something that can actually be called an institution, is the unfinished business of this essay. It is where the argument goes next.

IX. The chief librarian

Let me end where the frame leaves the person actually carrying it. A leader who has accepted the library frame is no longer running a company and a technology program inside it. They are the chief librarian of two institutions: an old one that must be kept excellent for as long as it has readers, and a new one that must be brought into being alongside it and will outlast the leader's own tenure.

That is a heavier description of the job than the one most leaders signed up for, and I do not want to soften it. The work is not to bring AI into the library. The work is to found a second institution, of a different kind, serving the same readers through a different kind of experience, and to run both at once for as long as both have readers who prefer them. It has no closing date. It will not resolve into a tidy target state. It asks a leader to hold two definitions of quality, two workforces, two regulatory postures, and two measures of success in mind at the same time, and to be judged on the whole.

But I want to be equally clear that this is not a counsel of despair, because the same frame that makes the job sound heavier also makes it clearer than it was. The enterprises that are pulling ahead are not there because they bought a better model or hired a better vendor. The model is a commodity; that is what a substrate is. They are there because they understood what kind of change this is. They stopped renovating. They named the new institution as a new institution on the first day, and then they did the patient, unglamorous, well-built work of founding it: the foundation before the services, the blank-sheet workflow, the fluency treated as real investment, the honest metric, the portfolio held instead of the program run. None of that is a secret. None of it depends on privileged technology. It depends on seeing the situation correctly and then having the institutional courage to act on what you see.

And that is, in the end, the good news hiding inside the divergence. The barrier is not capability. The frontier models are available to everyone, the patterns are visible in the public record, the playbook is not hidden. The barrier is comprehension and courage, the willingness to see that the old institution, however excellent, is not the thing being upgraded, and the willingness to found the new one honestly while the old one still pays the bills. Comprehension and courage are hard. But unlike a frontier model or a rare technical team, they are not things a competitor can simply buy. They are available to any leader willing to look at the situation without flinching. The dissolution of the old structure is not in doubt. What an enterprise becomes on the other side of it is still, genuinely, a choice. This essay has been an argument about how to see the choice clearly. The making of it is the work, and the work is now.

A note on sources

This essay draws on the public research record on enterprise AI as of May 2026, including the Boston Consulting Group's multi-year research on the widening gap between AI leaders and the rest of the field, McKinsey's State of AI work and the second edition of Rewired, Deloitte's State of AI in the Enterprise survey of several thousand leaders across two dozen countries, the Stanford Human-Centered AI Index, and the World Economic Forum's 2026 work on organizational transformation. The destination-state description of the queryable, agent-addressable company draws on the Y Combinator AI-native material articulated in early 2026. The named enterprise cases, JPMorgan Chase, DBS Bank, Moderna, Walmart, Lloyds Banking Group, AT&T, and Vodafone, are drawn from public statements and case studies. The leader-and-laggard segmentation and the tiering of enterprises by depth of transformation come from leader self-report in industry surveys; they should be read as directional rather than audited, and they are used here only because several independent surveys, using different methods, point the same way. The library frame, the artifact-to-interaction argument, the reconstitution framing, and the conclusions are the author's own. The direction of travel is, in my view, hard to ignore. The pace, and the identity of the eventual winners, remain genuinely uncertain.

Enterprise software is not going away. But the place where work happens is changing. The old SaaS application may remain the system of record while losing the work surface to agents, or it may absorb agents into its own governed perimeter. SAP and Salesforce have, between mid-April and mid-May 2026, given us both versions of that future. This essay is an attempt to make sense of what is happening, written for the many people now trying to do the same.

I. Three doors

Two of the largest enterprise software companies on earth made three moves this spring that, taken together, tell the story of where the industry is going better than any analyst report I have read. The dates: April 15, late April, and May 12. The actors: Salesforce and SAP. The question hidden inside the sequence is one every board in the sector will have to answer in the next eighteen months.

On the 15th of April, at its TrailblazerDX developer conference in San Francisco, Salesforce introduced what it called Headless 360. The headline, taken directly from its own announcement, was that every capability on the platform (data, workflows, business logic) is now accessible as an API, a Model Context Protocol tool, or a command-line instruction. More than sixty new MCP tools. Thirty preconfigured coding skills. Open access from Claude Code, Cursor, Codex, Windsurf, and any other coding agent. A unified AgentExchange marketplace bringing together ten thousand Salesforce apps, more than twenty-six hundred Slack apps, and more than a thousand Agentforce agents, tools, and MCP servers. A fifty-million-dollar Builders Fund to support partners building agents on the platform. Salesforce's co-founder, Parker Harris, framed the announcement with a question that would have been heretical five years ago: why should you ever log into Salesforce again?

Roughly two weeks later, on the other side of the Atlantic, SAP published Version 4 of its API Policy. The document was technical, brief, and easy to miss. Section 2.2.2 was the part that mattered. It said that, except through SAP's own endorsed architectures, data services, or service-specific pathways, SAP would prohibit its APIs from being used for interaction or integration with autonomous or generative AI systems that plan, select, or execute sequences of API calls. In plain language: third-party AI agents could no longer chain their own calls against SAP data unless they routed through SAP-endorsed paths. Integrations of the sort being built around Microsoft Copilot, Salesforce Einstein, and the long tail of agentic SAP connectors were no longer dealing with a neutral API surface. They were dealing with a perimeter. The German-speaking SAP User Group, DSAG, publicly raised concerns about the policy. SAP's CEO Christian Klein later clarified on the Q1 investor call that SAP's intent was not to block customers from their own data and that the company still wants an open platform. But the policy text remained.

Then, on May 12, at SAP's Sapphire conference in Orlando, SAP did something more revealing. Having drawn a perimeter around third-party agentic access two weeks earlier, it announced its own Autonomous Enterprise strategy. A unified SAP Business AI Platform. A new Joule Studio for building agents. An Autonomous Suite with more than fifty domain-specific Joule Assistants orchestrating over two hundred specialized agents. Most strikingly: a deepened partnership with Anthropic, in which Claude becomes a primary reasoning and agentic capability embedded across SAP's portfolio through Joule, operating on SAP data through what SAP calls its Knowledge Graph and Business AI Platform. The accompanying joint statement from Anthropic's president Daniela Amodei framed it precisely: Claude doing the work of closing the books, rerouting delayed orders, approving expenses, inside the systems enterprises have already invested in, with the trust and governance SAP customers rely on.

Read those three moves in sequence and you have, in compressed form, the strategic debate that the enterprise software industry is now having with itself. Salesforce: expose everything to external agents, let the user work from wherever they want, accept that the platform's job is to be the system of record and the system of action underneath someone else's agentic surface. SAP, late April: restrict external agents at the API perimeter, force agentic traffic through SAP-endorsed paths. SAP, mid-May: the deeper move. Concede that agents are the future of the work surface, but anchor those agents inside SAP's governed perimeter, with SAP's Joule as the assistant, SAP's Business AI Platform as the trust layer, SAP's processes and data as the context, and Claude (the standalone agent OS) running inside the perimeter rather than outside it.

These are not opposite strategies. They are different answers to the same question, and the question is the one that should be on every enterprise board agenda this year. The question is not whether agents are coming. The question is who owns the agentic work surface: the independent AI operating system, or the incumbent system of record. Salesforce is betting the platform survives as substrate even as the work surface moves up to whatever agent wins. SAP is betting it can absorb the agent layer into itself, making Joule plus Claude the work surface and keeping the strategic value of being the place where work happens. Both moves implicitly concede that the application layer as it has existed for twenty-five years, the seat-licensed, screens-and-workflows version, is being repriced.

And here is the part worth attending to. Through May 12, both stocks remained under pressure. The public-market signal is not clean, but it is large. Reuters reported that the S&P 500 software and services index shed roughly $1 trillion in market value in the week after January 28 alone. Broader software losses, depending on index construction and time period, run into the low trillions. The exact number matters less than the repricing: investors are treating application software as a category with new structural risk. Some of that risk is macro. Interest rates, post-pandemic normalization, the end of the frothy 2021-2022 valuation cycle, company-specific guidance, geopolitical concerns. Those factors are real and we should be honest about them. And there is a serious, credentialed camp arguing the selloff is simply wrong. Bank of America's senior semiconductor analyst has called the souring on software indiscriminate and overblown. Nvidia's CEO has said the market got it wrong, that capable AI will expand the demand for software rather than collapse it. Several well-known investors have argued that the market is confusing what is changing with what is dying, and projecting the behavior of five-person startups onto Fortune 100 procurement. They may be right. The market is not proving the thesis. Markets rarely prove anything cleanly, and panics overshoot. But the repricing is not only a panic. It is also the market beginning to price the possibility that the application layer's old growth and pricing assumptions no longer hold, and that the platform value is migrating somewhere, whether that somewhere is the standalone agent OS, the incumbent's own agentic surface, or some hybrid not yet fully formed.

Who owns the agentic work surface: the independent AI operating system, or the incumbent system of record?

This essay is an attempt to explain why I think this is the central question, what the structural answer probably looks like, and what could prove me wrong. The argument has weaknesses, and I will name them. I am writing as someone inside this industry who has spent the past several months in conversations with builders, buyers, investors, and operators. I have no claim to certainty. I do think the direction of travel is hard to ignore. The timing, magnitude, and identity of the eventual winners remain deeply contested.

II. The substrate and the platform

To explain what I think is going on, I want to take you back to 1985. In 1985, if you had asked a thoughtful person where the value of the personal computer industry was going to accumulate, the most popular answer would have been: chips. Intel made the brains of the machine. Intel had the patents. Intel had the manufacturing. The x86 instruction set was the foundation that everything else sat on top of. Own the chip, own the industry.

That answer was wrong. Or rather, it was correct about the substrate and wrong about the industry. Competitors caught up to Intel at the instruction-set level. AMD made chips that ran the same software. Years later, ARM ate the mobile market entirely. The chip-level moat that looked so durable in 1985 turned out to be fillable by anyone with enough engineering talent and enough capital. By the late 2000s, the chip business was a real business, but it was no longer the business.

The business, the place where the trillions of dollars actually accumulated, was the operating system. The layer that sat on top of the chip. The layer where the user actually lived. The layer that translated whatever a human wanted to do into the language the chip could execute. Microsoft did not make chips. Microsoft made Windows. And Windows turned out to be the platform, while x86 turned out to be the substrate. In technology, the platform tends to win.

Here is the part of the story that should haunt anyone betting on the wrong layer today. Linux is free. Linux is, in many respects, technically superior to Windows. Linux has been freely available for over thirty years and runs most of the world's server infrastructure. And Windows is still embedded in a Microsoft franchise worth, conservatively, more than a trillion dollars. The substrate commoditized. The platform did not. Because once a user has installed their applications, configured their files, built their habits, and trained their muscle memory, switching to a technically better alternative is not a casual decision. The substrate is replaceable. The platform is not.

The substrate is replaceable. The platform is not. This is the iron rule of technology transitions, and the layer most analysts are watching is usually not the layer where the value ends up.

This is a recurring pattern in technology transitions, and it should make anyone betting on the wrong layer today nervous. People confuse the substrate for the platform. They look at the most visible, most discussed, most benchmarked layer and assume that is where the value will accumulate. The pattern has held in personal computing, where the chip makers were the spectacle and the operating system won. It held in the browser era, where the rendering engines were the spectacle and the search and advertising platforms won. I think it is holding right now in artificial intelligence, where everyone is watching the models, and the operating systems built on top of the models are, quietly, where the work surface is moving.

Take any of the leading AI assistants apart, the way a mechanic takes apart an engine, and ask yourself what is actually inside. There is the model itself, of course. The part everyone talks about, the part that scores on benchmarks. But the model is one piece, and not the most strategically important one. Around the model, these companies have built persistent work surfaces where files and projects accumulate over time. They have built coding agents with their own execution environments, products that have become some of the fastest-growing tools in the current software cycle. They have built universal adapters that let the assistant reach into any external system. They have built native presences inside the tools people already use, inside browsers, inside spreadsheets. They have built skills systems that give the assistant domain expertise on demand. They have built memory, so the assistant knows you. They have built partner networks and certification programs. They have built tiered pricing structures that operate simultaneously at the consumer, prosumer, and enterprise levels. They have built safety and governance layers.

None of that is the model. The model is the engine. All of that is the car around the engine: the chassis, the cabin, the instruments, the doors, the wheels. Eighteen months ago, it would have seemed implausible to say this, but the model is no longer the only place where the strategic battle is fought. Several companies can now build a competitive frontier model, and building one remains a feat of extraordinary engineering. Far fewer have built durable work surfaces, memory, integrations, governance, distribution, and pricing systems around them. Competition at the model layer is real and intense. Competition at the operating-system layer is narrower.

This is the place where I want to be careful, because I have heard a version of this argument used to declare a winner already, and I do not think that is honest. Anthropic's Claude is, in my view, the clearest current example of what an agent operating system is becoming, because Anthropic appears to have understood from early on that it was building one. OpenAI is the most heavily capitalized contender, and ChatGPT has the deepest consumer mindshare. Google has, in principle, the strongest distribution position through Workspace and Android, though it has moved slower than its assets would predict. Microsoft has Copilot inside the tools where most enterprise work already happens. And as SAP's Sapphire announcement made vivid, the incumbents themselves may yet capture some version of the agent layer by absorbing it into their governed perimeters. The race is not run. It is in the early phase of what may turn out to be the most consequential platform race in business history. The structural argument of this essay does not depend on which one wins. It depends only on the claim that a small number of operating-system-shaped surfaces will sit above or beside the model layer and capture work.

A note on vocabulary, because language is a leading indicator. When I first started describing this layer as an operating system, it felt like a stretch of an analogy. It no longer does. Deloitte's enterprise software analysts now forecast the emergence of what they call, in their own words, an enterprise AI operating system: a layer that governs, orchestrates, and controls AI agents rather than leaving them as disconnected tools, and they advise buyers to start asking who owns that layer. When an independent professional-services firm reaches for the same metaphor without coordination, the metaphor has stopped being a rhetorical device and started being a category.

III. The new browser

There is a second analogy I find useful, because it captures what these new tools actually are in a way that resonates with anyone who has used a computer in the past twenty years. The leading AI assistants are not chatbots. They are the new browsers.

Think about what a browser was, in the classic sense. A browser was a window onto documents that lived somewhere else on the internet. You typed an address, and the browser fetched a page, and you read it. If you wanted to do something, buy a book, send an email, watch a video, you found a website that did that thing, and you did it through the browser. The browser was the surface where the internet happened. It was where you spent your time. It was where you formed your habits.

Consider what the browser captured, economically. The browser did not capture value merely by rendering pages. It captured value when it became a default surface for discovery, identity, search, advertising, and distribution. The largest economic gains of the internet age accrued not to the browser as standalone software, but to the ecosystems that formed around it: search engines, ad networks, operating-system defaults, mobile distribution. The agentic browser will matter for the same reason only if it becomes the default surface for execution.

Now consider what the AI assistants are becoming. The user is no longer typing in an address and fetching a document. The user is describing a desired outcome, write me a report, plan my project, debug this code, summarize these emails, find me a flight, and the assistant is producing the outcome. The interaction model has changed in a way fundamental enough that we are still groping for the right vocabulary. The old browser was a window onto documents. The new browser is a window onto outcomes.

And here is the part worth attending to: if browser-shaped ecosystems captured trillions of dollars of value around the document web, agentic work surfaces may be positioned to capture value around the outcome web. The document web, vast as it was, was always a subset of human activity. The part of human activity that could be encoded as a document and rendered on a screen. The outcome web, by contrast, is co-extensive with knowledge work itself. Anything a knowledge worker does, and a large and economically central share of enterprise value creation is now knowledge work, is in principle something that can be requested as an outcome from an AI assistant. Every email written, every report drafted, every analysis performed, every meeting summarized, every spreadsheet built.

The old browser was a window onto documents. The new browser is a window onto outcomes. The center of gravity in pricing is moving from seats to usage.

This brings us to a business-model shift that I think is more important than the technology itself, although I want to be careful here because the simple version of this argument is wrong. The simple version says: software used to be priced by the seat, and now it is priced by the token. That is half right and would be misleading without nuance.

For twenty-five years, enterprise software was priced primarily by the seat. A company would pay its software vendor a monthly fee for each employee who used the software. The seat was a proxy for value: each seat represented a human spending time inside the product, and the price was calibrated to the value extracted. The new pricing model is not the disappearance of the seat. Claude Enterprise, ChatGPT Enterprise, and Gemini Enterprise all still have per-seat components. What is happening is that the center of gravity in pricing is shifting. Seats remain a base. But the unit of incremental value is the token. A fragment of text consumed when the assistant does work. A complex request costs more tokens. A trivial one costs few. The price is metered to the work performed, not just to the seat occupied. Enterprise contracts now routinely combine base seats, committed token spend, usage tiers, overages, and enterprise-wide credits. Pricing is becoming hybrid, and the hybrid is tilted toward usage and outcomes.

This is not only my reading. IDC forecasts that by 2028, pure seat-based pricing will be obsolete, with roughly seventy percent of software vendors having refactored their pricing around consumption, outcomes, or organizational capability. And the incumbents are already moving. When ServiceNow opened its platform to external agents this spring, it metered the access: agents pay, per action, in the same consumption currency ServiceNow customers already buy, a model one analyst described as a tollgate for agents. The seat is not dead. But the meter has been installed, and the incumbents are installing it themselves.

This tilt matters for three reasons. The first is that token pricing removes the seat-count ceiling on growth. Traditional seat-based software has a natural seat-count ceiling unless the vendor expands modules, raises price, or moves into adjacent workflows. An agent-OS provider can grow as fast as the world delegates work to it, which is a much higher ceiling because most knowledge work is in principle delegable. The second is that the price is tied to value performed. If the assistant produces an outcome that would have taken a human three days, the customer compares the cost of the tokens to the cost of the three days and almost always concludes the tokens are a bargain. The third is that every token consumed is consumed in pursuit of something the user explicitly wants, which makes willingness-to-pay higher than in ad-supported models.

I want to acknowledge what this model gives up. Token pricing has real drawbacks. Bills are harder to predict, which procurement teams hate. The meter is always running, which can cause organizations to cap usage precisely when usage is most valuable. Inference costs put pressure on gross margins for the providers themselves. Some categories of work do not naturally map to token consumption. Enterprise customers, particularly in regulated industries, are right to demand committed pricing, cost guardrails, and predictable budgets, and the providers are still working out how to offer them. The transition will be uneven. None of these caveats overturns the direction of the change. They do mean the change will not be as clean as the simple narrative suggests.

IV. Dissolution, not displacement

The standard mental model for software disruption is what consultants call rip and replace. A new product comes along, demonstrably better than the old one. The customer, after some hesitation, agrees to swap them out. A migration project is scoped. It takes eighteen months. Data is moved. Training is conducted. The new product replaces the old. The old vendor loses the contract. This is what disruption has looked like in enterprise software for thirty years.

I do not think this model describes what is happening with AI assistants. What is happening does not look like rip and replace. It looks more like sugar dissolving in water. Slowly at first. Then, perhaps, all at once.

Here is how it actually plays out. The example that follows is a composite, drawn from patterns I have heard repeatedly across conversations with enterprise buyers over the past six months rather than a single named deployment. It is meant to illustrate the pattern, not to serve as a statistical claim. A large company has been running a major enterprise platform for fifteen years. Its entire procurement, supply chain, and financial reporting infrastructure is built on it. It has spent, at this point, somewhere between forty and three hundred million dollars implementing and customizing it. It is not, under any circumstances, ripping it out. The CFO would not survive the conversation.

And yet. The same company has, in the past year, deployed an AI assistant for its finance team. Initially the team uses it for what looks like trivial work, summarizing emails, drafting memos. But the use cases compound. Someone in financial planning realizes the assistant can read the data export from the enterprise platform and produce a draft variance analysis in minutes that used to take an analyst two days. Someone in procurement realizes that the assistant, connected to the enterprise data and to the vendor database, can flag anomalies in supplier behavior that nobody had time to look for. Someone in treasury starts using it to draft the weekly cash report. Within six months, the finance team is doing thirty or forty percent of its work through the assistant. Within twelve months, the analysts who used to spend eight hours a day inside the enterprise platform's screens are spending two hours a day there and six hours inside the assistant. The platform is still in place. The data is still there. But the team's attention, its workflows, its institutional habits, those are no longer in the platform. They are in the assistant that sits one layer above.

The platform is no longer the place where work happens. It is the system of record. That is a different business, with a different margin, and a meaningfully different valuation.

Now consider what happens at contract renewal. The enterprise platform vendor prices its product based partly on the number of seats and partly on the strategic importance of the platform. When the negotiation happens, the buyer can now say, truthfully, that fewer employees are spending meaningful time inside the platform, that the data is being consumed through the assistant rather than through the platform's own interface, and that the platform is no longer carrying the strategic workflow it used to carry. The price comes down. Not catastrophically the first cycle. Maybe ten percent. Maybe fifteen. The direction is established. The next cycle, the conversation is the same, and the price comes down again. Within three or four renewal cycles, five or six years, the platform is no longer charging strategic-workflow prices. It is charging system-of-record prices. It is still in the picture. It is just in a much smaller one.

This is dissolution. There is no migration. There is no rip-out. There is no moment anyone can point to and say, that is when we left the platform. The application is simply no longer the place where work happens. The path from one state to the other looks, from the inside, like nothing at all. It looks like normal renewals, normal usage, normal everything, except that the screens have become less crowded, and the dashboards are no longer where decisions get made.

I want to address the strongest counterargument here, because I have heard it from people I respect and I think it deserves a fair hearing. The SaaS incumbents argue that their moat is not the storage of data (they would agree storage is commodity) but what they call governed context. The data plus the permissions, the sharing rules, the workflows, the business logic, the compliance controls, the audit trails, the implementation history, the organizational habits that have accumulated over decades. Salesforce's own framing of Headless 360 leans into exactly this: an agent connected to a raw database, they argue, does not know that a customer has an open escalation, a renewal due in thirty days, a breached SLA, and a relationship owner with a personal connection to their CFO. That context took years to accumulate. It lives in Salesforce. Headless 360 exposes it through APIs and MCP tools so that agents can reach it from anywhere, without touching the UI, but the context, they argue, still belongs to the platform. SAP's Autonomous Enterprise announcement is the same argument made even more aggressively: not only does the governed context belong to the platform, but the agent itself should live inside the platform's perimeter.

This is a serious argument and I do not want to wave it away. The question it raises is not whether the data moat is real, because narrowly defined as raw rows in a table the data moat is plainly weak. The question is whether the governed context, the permissions, workflow, business logic, auditability, migrates to the agent layer over time or remains anchored in the incumbent platforms. The incumbents are betting it remains anchored. They are betting they become the system underneath the agents (Salesforce's bet), or that they absorb the agent layer into themselves (SAP's bet), with the standalone agent OS reduced to a reasoning engine that runs inside their governed perimeter. My read is that the absorb-the-agent bet works for some time, and probably permanently for some categories of regulated, mission-critical operation. But I expect that for most workflow software, the governed-context layer migrates upward over a five-to-ten-year horizon, because that is where the work happens and that is where governance will eventually need to attach. Reasonable observers disagree about this. It is the most important open question in the essay, and it is precisely the question that SAP's Sapphire announcement was an attempt to answer in the incumbent's favor.

V. The flywheel

If you want to understand the speed at which this is moving, you have to understand the flywheel. The flywheel is what, in any technology transition, separates the slow, manageable kind of disruption from the kind that catches everyone by surprise. In the case of the AI operating systems, there are two flywheels that I would watch most carefully.

The first is talent. The senior engineers and solutions architects at the established enterprise software companies are one of the most valuable hidden assets in the world economy right now, and almost nobody is talking about it as such. There are likely tens of thousands, perhaps more than a hundred thousand, of these people globally, distributed across the major incumbent vendors, systems integrators, and implementation partners. They are the people who actually understand, in deep operational detail, how a Fortune 500 company runs its supply chain, recognizes its revenue, handles its claims processing, manages its compliance. This knowledge does not exist in textbooks. It exists in their heads, accumulated over twenty or thirty years of solving real problems for real customers. It is, in the truest sense, the moat of the enterprise software industry. Not the code, not the data, but the embodied institutional understanding of how the customer's business actually works.

Now look at the compensation arithmetic. The leading AI labs have seen their valuations appreciate dramatically over the past eighteen months. A principal engineer at an incumbent vendor, whose equity grants from two years ago may now be worth less than expected, is fielding recruiting calls offering total compensation packages that are multiples of their current arrangement, plus equity in a company that may continue to appreciate. This person has a choice. They can stay, watching their net worth lag while their company navigates a strategic challenge they suspect will be difficult. Or they can take the call.

I want to be honest about the state of the evidence here. The flow of senior enterprise engineering talent from the incumbents to the AI operating system providers is still early and hard to measure publicly. It may already be substantial. It may still be a trickle. But it is one of the signals I would watch most closely over the next eighteen months, for a simple structural reason: if and when principal engineers and senior solutions architects begin moving from the application incumbents to the agent-OS providers at scale, the institutional knowledge moves with them. And the incumbents do not just lose engineers. They lose the people who knew how their customers' businesses actually worked, which is to say, they lose what made them valuable in the first place.

The moat of the enterprise software industry is not the code, not the data, but the embodied institutional understanding of how the customer's business actually works. When that knowledge walks across the street, the moat walks with it.

When these people do land at the AI labs, they do not rebuild the old systems. They build what those systems should have been if you had started designing them today, with assistants as the substrate from the beginning. Fewer screens. Less default reliance on seat licenses. Shorter, more modular implementations. Just an assistant that, because the engineer who designed it spent fifteen years solving supply chain problems for a global manufacturer, knows exactly how supply chains work. The new product is not a feature-by-feature replica of the old one. It is the old product's purpose, redesigned for the agent era, and built by the very people who used to build the old product.

The second flywheel is compute. Compute is the raw material of these new operating systems, the way electricity is the raw material of an aluminum smelter. The compute commitments being made right now are unlike anything in the history of corporate capital allocation. Major hyperscalers have announced multi-tens-of-billions of dollars of investments in the leading AI labs, in exchange for or alongside gigawatts of computing capacity. The structure of these deals is important to read carefully. The equity investment piece is one thing, the commercial compute commitment is another, and the two are related but distinct, and the press tends to conflate them. Anthropic's Amazon arrangement, for instance, secures up to roughly five gigawatts of capacity with what Anthropic itself describes as a commitment of more than a hundred billion dollars over ten years to AWS technologies, alongside a current Amazon equity investment of five billion dollars with up to twenty billion more in the future. Similar structures exist with Google. Goldman Sachs has estimated total AI infrastructure capital expenditure could reach roughly seven and a half trillion dollars between 2026 and 2031. The exact numbers will move. The order of magnitude is the point. These are not normal venture investments. They are infrastructure-scale bets made by the parties closest to the technology about the rate at which the world is going to absorb capital into this transition.

One caveat is worth making here, because the framework so far implies that compute earns foundry-style margins and that platform margins accrue one layer up. That is probably the long-run picture, and it maps cleanly onto how the personal-computing era resolved itself. But the compute layer may not behave like commodity plumbing during this cycle. Scarce compute, specifically scarce frontier-grade compute, scarce power, scarce fabrication capacity, may itself have platform-like pricing power for as long as the scarcity persists, which on Goldman's numbers could be most of the next decade. Nvidia is the obvious example. The compute layer may not be the final work surface, but it is not merely commodity plumbing either. The operating-system analogy is right in the long run. It may be temporally premature.

Both flywheels are self-reinforcing in the same direction. The more compute the AI labs have, the better their products get, the more revenue they generate, the more capital they raise, the more compute they can buy. The more senior engineers they hire, the better their products get, the more revenue they generate, the higher their equity values rise, the more attractive their compensation offers become. These loops compound. They appear to be compounding right now.

VI. What survives

Not everything in the existing software stack is going to dissolve. Some of it is going to be fine. Some of it is going to be more than fine. It is going to be quietly, durably valuable, the way boring infrastructure businesses have always been quietly, durably valuable. The question is which is which, and the answer comes back to why the software was there in the first place.

The software that survives is the software whose value comes from not changing. Financial general ledgers. Clinical health records. Identity systems. Regulated transactional databases. The undramatic plumbing of the modern economy. The reason these survive is that their value rests on a property, immutability, auditability, defensibility in a court or a regulatory proceeding, that is about the integrity of the record itself. The moment the authoritative record lives only inside an agentic reasoning layer, the record becomes hard to defend. The durable system of record still needs deterministic state, auditability, permissions, and replayable history. Agents can act on that layer, and eventually help govern it, but they do not eliminate the need for it. So the ledgers remain. The databases remain. The compliance systems remain. They are, in a real sense, the bedrock layer of the new architecture.

There is a useful tell here. The leading AI labs have raised tens of billions of dollars. They have not publicly prioritized owning the data-infrastructure layer. Their capital allocation and partnership behavior point instead toward compute, distribution, protocols, enterprise surfaces, and agentic workflows. They are content to let the data layer below them remain in the hands of existing providers. This is the strategic equivalent of the great platform companies of earlier eras choosing not to enter the semiconductor business. They were not being kind. They were being clear-eyed about where the platform value was. The data layer is plumbing. Plumbing is valuable. But it is not where the leading AI labs appear to believe their platform value sits.

The software whose position is hardest to predict is the workflow application layer. CRM, ticketing, HR self-service, project management, marketing automation, e-commerce admin. Their value came from being the place where humans operated against the systems of record. Their argument now is that they are repositioning themselves as agent platforms, exposing their data, workflows, and business logic to external agents through MCP and APIs, while retaining the governed context that makes the platform valuable. SAP's Sapphire announcement is the most aggressive version of this argument yet attempted: not merely expose the platform to external agents, but make the platform's own agent the default surface and route the standalone AI model through it. Whether this works is the open question. The optimistic case for the incumbents is that governed context cannot be rebuilt by an agent in the time horizon that matters, and that the incumbents become the substrate that agents act on, or, in SAP's stronger version, the substrate that agents live inside. The pessimistic case is the dissolution argument above: the work moves up a layer, the renewal prices come down, the platforms become storage. I think the truth is in between, and which side dominates will vary by category. The most exposed categories are the ones where the workflow logic is thin and the user-interface real estate was most of the value. The least exposed are the ones where the governance, audit, and compliance machinery is dense enough that an agent cannot reasonably rebuild it, which is precisely the category SAP is now trying to claim is its entire footprint.

There is one more category worth noting. Software whose value comes from a network external to the customer (a financial information terminal, a professional networking graph, a payment network) is protected for a different reason. The AI operating systems will operate on top of these networks, but cannot replace them. You cannot replace the network of every financial professional in the world by writing better AI. You can only access it. Some of the most agent-resistant pieces of software ever built, paradoxically, turn out to be the ones whose value comes from the network of humans on either side of them.

Put this all together and you get a picture of the software landscape that looks different from the one we are used to. At the bottom: utilities. The databases, the ledgers, the identity systems, the payment networks. Durable and valuable, but valued the way utilities are valued. In the middle: a layer in transition, where the outcomes will be uneven and where incumbents like SAP are now trying to redefine their middle-layer position as a governed-perimeter platform for agents. At the top, or perhaps overlapping with the middle: the AI operating systems. A small number of them, with potentially extraordinary pricing power and revenue growth, though their ultimate margins remain contested because inference and compute are expensive. Below all of this, supporting the entire structure: the compute layer, the chips, the hyperscalers, earning, in this scarcity phase, more than foundry-style margins, possibly for years.

This is not, on reflection, a particularly unusual pattern in technology transitions. It happened to the mainframe makers when the PC arrived. It happened to the on-premises software vendors when the cloud arrived. It is happening now, I think, to the application layer with the arrival of AI operating systems, though with the wrinkle that, this time, the incumbents are attempting to fold the new layer into themselves rather than simply being displaced by it. Whether that works will define the next decade.

VII. What could prove this wrong

I have tried throughout this essay to be honest about uncertainty, but it is worth pausing to lay out, in one place, the strongest objections to the argument. Any of these could turn out to be the decisive factor. None of them, I think, dissolves the direction of travel. They could meaningfully change the slope, the timing, and the identity of the winners.

• Incumbents absorb the agent layer into their governed perimeters. This is the SAP Sapphire bet, made explicit. If incumbents successfully embed agent reasoning inside their own platforms, with their own assistants as the default surface, their own knowledge graphs as the context, and external models like Claude operating inside the perimeter rather than around it, the dissolution mechanism described above could be substantially blunted. The platform survives by absorbing the new layer rather than ceding ground to it.

• Enterprises standardize on agents provided by existing vendors. Microsoft is the obvious example, and this is no longer hypothetical. On May 1, 2026, Microsoft made Agent 365 generally available: a control plane to discover, observe, govern, and secure AI agents across Microsoft and partner environments, priced per user and bundled into a new enterprise suite, with registry sync that reaches into AWS and Google Cloud. If enterprises decide that the agent layer they want is the one embedded inside the productivity tools and identity systems they already pay for, the standalone agent-OS providers may capture less than this essay implies. The agent layer still wins; it just might be Microsoft's agent layer.

• Governance, security, and audit requirements anchor work inside the incumbents. Regulated industries have a legitimate interest in keeping certain workflows inside platforms with proven audit trails and compliance certifications. SAP's API policy is partly a security argument, and the security argument is not wrong. If governance becomes the binding constraint on agent adoption, the dissolution timeline stretches by years.

• Token economics compress provider margins faster than SaaS margins compress. Inference is expensive. The more useful the agents become, the more tokens they consume, and the more pressure that puts on the providers' gross margins. It is possible the providers end up looking more like cloud infrastructure businesses, with thinner platform-level pricing power than this essay assumes.

• Interoperability prevents lock-in. MCP is an open standard. The model layer is becoming more portable. If agents become genuinely interoperable, no single agent OS may develop the durable switching costs that historically have produced platform-level economics. The category wins; no individual company captures the disproportionate share.

• The repricing is mostly a panic, and it reverses. This is the objection held by the most credentialed skeptics, and it deserves a fair hearing. On this view, the selloff confuses demo velocity with deployment reality, projects startup behavior onto Fortune 100 procurement, and underprices how much of the incumbents' value is switching cost, integration depth, and installed base. The gap between a polished agent demo and a system that runs reliably across thousands of regulated enterprise environments is vast, and the skeptics argue the market has not priced that gap. If they are right, the software multiples recover, and the dissolution stretches into a decade-plus evolution rather than a sharp repricing. My own read is that this objection is strongest on timing and weakest on direction: the panic almost certainly overshot in particular names, but the structural change it is gesturing at is real.

Each of these is a serious objection. My honest assessment is that the first and the second are the most credible as descriptions of where value actually lands, and the sixth is the most credible as a warning about timing. The incumbents may successfully absorb the agent layer, particularly in regulated workflows, and Microsoft may capture much of the agent surface through productivity-suite distribution. The panic may well have overshot. But none of these would change the structural claim that the application layer's old pricing assumptions are being repriced by the rise of agentic interfaces. The narrower argument, that the work surface is moving up or being absorbed, that pricing power is migrating with it, that the seat-licensed application as we have known it for twenty-five years is changing, survives most of the plausible challenges. The broader claim, that the standalone AI labs will capture all of the value, does not, and I have tried not to make it.

VIII. What to watch for

If you want to know how fast this is moving, there are a few signals worth tracking. None is conclusive on its own. Together they form a reasonably reliable picture of where we are on the curve.

Watch the capital allocation. When a software company's management stops investing aggressively in product and starts returning capital to shareholders through buybacks and dividends, that is a signal worth interpreting carefully. Buybacks can mean many things: capital discipline, confidence in valuation, tax-efficient return, offsetting dilution, or the absence of attractive M&A targets. They do not, by themselves, prove that management has given up on R&D. But a multi-year buyback program announced alongside softening forward guidance, with no parallel announcement of significant product investment or strategic acquisition, is one of the possible signatures of a category in transition. The signal is not the buyback alone. It is the pattern of capital flows over time.

Watch the talent flow. The most reliable leading indicator of where the next decade of software gets built is where the senior engineers are going. LinkedIn data is useful. Better signals come from who is speaking at conferences, whose names are on patents and papers, who is being quoted in the technical press. Watch in particular the second-tier movement. Not the founders and CTOs, but the principal engineers and senior solutions architects, the people who actually know how customer businesses work. When they move, the institutional knowledge moves with them.

Watch the integration protocols. The Model Context Protocol, introduced by Anthropic in late 2024 and donated to the Linux Foundation in December 2025 with OpenAI, Google, Microsoft, and Block as participants, has become a de facto standard for connecting agents to external systems. The cleaner signal is not that every major SaaS vendor has already shipped full, mature MCP support. They have not, and adoption is uneven across Salesforce, ServiceNow, Workday, and others. The cleaner signal is that major platforms are beginning to expose governed actions through agent protocols, while the leading AI assistants have converged around MCP as one of the default ways to call external systems. The direction is unmistakable even where the implementations are still partial. The act of supporting the protocol, even partially, is at minimum an acknowledgement that more work will be mediated by agentic surfaces outside the traditional application UI.

Watch the pricing models. The first time a major enterprise customer publicly announces that it has moved a category of work from a seat-based software contract to a token-based AI contract, you are looking at a bellwether. There will be a CFO who explains it on an earnings call. There will be a vendor who loses a flagship account. The financial press will treat it as a one-time event. It is unlikely to be a one-time event. Watch for the second and third announcements, which tend to come quickly after the first.

Watch what the AI labs do not do. This is more subtle, but revealing. The leading AI labs could deploy capital in many directions. They have not moved on data-infrastructure ownership. They have not moved on existing application-layer acquisition. Their public capital and partnership behavior points consistently toward compute, distribution, protocols, enterprise surfaces, and agentic workflows. Read this carefully. They are telling you what they think is valuable. They think the data layer is plumbing. They think the application layer is changing in ways they do not need to own. They are interested in the operating-system layer and the things that complement it. The strategic restraint is the signal.

Watch how the SAP and Anthropic experiment unfolds. This may turn out to be the most informative single development of the next eighteen months. If Claude operating inside SAP's governed perimeter, as Joule's reasoning engine, on SAP data, within SAP's Knowledge Graph, becomes the default way that SAP customers interact with their ERP, that is strong evidence that the incumbent absorption strategy is viable. If, instead, customers start preferring to bring their own agent OS to their SAP data via MCP and other protocols, ignoring Joule even when it is integrated with Claude, that is strong evidence that the standalone agent-OS thesis is the right one. The Sapphire announcement is the natural experiment, and the early evidence should begin to show up within a year, even if much of the decisive usage data remains private.

IX. Everyone is listening

I want to end with an observation about the people, because it is the part that surprised me most. A year ago, the conversation was about models. Which one was best, which was cheapest, which would plateau. That conversation is over. The people I talk with now, the executives and operators and investors who are genuinely good at their jobs, are not asking that question, and they are not asking a cleverer replacement for it either. They are mostly not asking questions at all. They are listening.

This is worth sitting with, because it is easy to mistake for indecision and it is not indecision. The smartest people I know in enterprise technology right now have arrived at the same posture more or less independently. They can see that something large is happening. They can feel the potential of it. And they have noticed that there is no proof anywhere, no reference deployment, no settled playbook, no company that has done the thing and can be copied. So they are doing the intelligent thing in the absence of a map. They are gathering signal. They are reading, comparing notes, watching what their peers try, holding their conclusions loosely. They are listening.

I have tried, in this essay, to offer something to listen to. Not a forecast, and not a question that unlocks the rest if you only ask it. There is no single question. Anyone who tells you the whole thing reduces to one clean question is selling the comfort of a frame, and the comfort is false. What I have offered is a structural reading: that the work surface is moving, that it is moving either up into standalone agent operating systems or inward into incumbent governed perimeters, that the layer where it lands is the layer that captures the value, and that the seat-priced application as we have known it for twenty-five years is being repriced regardless of which way it resolves. That reading might be wrong. I have spent a section of this essay on the ways it might be wrong. But it is a shape, and a shape is something you can hold up against what you are hearing and test.

I do not know which agentic surface will win. The race is genuinely open, and I have tried in this essay to resist the temptation to declare a winner. What I will say is that the companies leading right now, both the standalone agent-OS providers and the incumbents now trying to absorb the agent layer, appear to have understood, earlier than most observers, what kind of thing they were actually building. They were not building chatbots. They were building or rebuilding operating systems. The architectural choices they have made, around protocols, surfaces, memory, integrations, safety, partner ecosystems, and pricing, are the choices you make when you understand that the model is the substrate and the platform is what matters. Whether the winners turn out to be the standalone labs, the productivity-suite incumbents, the systems-of-record giants now embracing agents, or some combination, depends on choices that are being made right now and that will reveal themselves in usage data over the next two to three years.

The thing that is ending, I think, is not enterprise software. The thing that is ending is the era in which the application layer of enterprise software was the most valuable layer in the stack. The era of seats, screens, and per-user-per-month pricing as the dominant model. That era began, roughly, at the turn of the millennium. It will end sometime, I would guess, before the end of this decade. Twenty-five years is, in the long view, about right for a platform era. The mainframe era ran about that long. The personal computing era ran somewhat longer. The application-SaaS era, by historical standards, had a perfectly respectable run. It is now changing, quietly in some categories, loudly in others, with most of the participants not quite sure yet whether the change will leave them stronger or weaker.

The companies in the application layer will survive. They will still exist in 2030. Many will reposition themselves successfully as systems of record, or as agent platforms, or as governed-perimeter providers underneath or alongside the standalone operating-system layer. SAP's bet at Sapphire is that this repositioning is not only possible but desirable from the platform's perspective. Some will be absorbed. A few may go private. None of these outcomes is catastrophic. None of them is what investors were modeling two years ago. Both can be true at the same time.

So I will not end by telling you what question to ask. I do not think that is the honest move, and I do not think it is what this moment calls for. What I will say is that the listening is not a holding pattern. It is the work. The people who come through this transition well will not be the ones who found the magic question first. They will be the ones who listened carefully, who built an internal picture of where the work surface was moving before there was proof, who noticed the shape of it early enough to act while acting was still cheap. The shape is becoming visible. SAP and Salesforce and Microsoft and ServiceNow have, in the span of a few weeks, each shown a piece of it. The trillion-dollar question, who builds the next infrastructure, who pays for it, and what it looks like when it is finished, does not have an answer yet. But it has a direction, and the direction is no longer hard to see.

I am still listening too. This essay is not a verdict handed down from somewhere above the situation. It is one reading, from inside the same fog everyone else is in, offered in the hope that it is useful to compare against yours. If your picture differs from mine, I would rather hear it than be told I was right, because none of us has enough signal yet and the fastest way to get more is to put our partial maps next to each other. That is the actual state of things in the spring of 2026: a large number of capable people, reading the same unsettled situation, building the picture in public and in parallel. The window to position yourself against the direction is open. It will not stay open indefinitely. Until it closes, the right thing to do is what the best people are already doing. Keep listening. Compare notes. Then move.

A note on sources

Key source anchors: Salesforce Headless 360 announcement (April 15, 2026); SAP API Policy v4/2026, particularly Section 2.2.2; DSAG's public concerns about the policy and SAP CEO Christian Klein's clarification on the Q1 2026 investor call; SAP Sapphire 2026 Autonomous Enterprise announcement (May 12, 2026); the SAP and Anthropic Claude-in-Joule announcement; Anthropic's MCP donation to the Linux Foundation's Agentic AI Foundation; Anthropic's Amazon and Google/Broadcom compute announcements; the Goldman Sachs Tracking Trillions report on AI infrastructure capex; Reuters coverage of the 2026 software-services selloff; the Microsoft Agent 365 general-availability announcement (May 1, 2026); and the ServiceNow Action Fabric announcement from Knowledge 2026. The forecast that seat-based pricing becomes obsolete by 2028 is from IDC; the enterprise-AI-operating-system framing attributed to an independent professional-services firm is from Deloitte's 2026 enterprise software predictions; the characterization of the selloff as overblown reflects on-record comments from a Bank of America analyst and Nvidia's CEO as reported by Fortune. Sector market-capitalization figures and individual stock declines are approximate and based on publicly reported data through May 12, 2026. The market-causality argument should be read as evidence of category risk, not as proof that AI disruption is the sole or primary cause of every individual stock move. The composite finance-team example in section IV is explicitly a composite, drawn from patterns across multiple buyer conversations rather than a single named deployment. The framework, the dissolution mechanism, the layer-cake interpretation, and the conclusions are mine. The direction of travel is, in my view, hard to ignore. The timing, magnitude, and identity of the eventual winners remain deeply contested.

Here is something I have learned from decades of working with people.

Most professionals, and I include myself in this, are extraordinarily good at presenting competence. We have been trained since school to perform well. We know how to speak the right language, follow the right patterns, mirror the people we respect. We can simulate understanding convincingly enough that in a short interaction, you would believe we know what we are doing.

Real insight is different. And it is rare.

You know it when you encounter it because it surprises you. I have had thirty-minute conversations with someone and walked away thinking they were capable but unremarkable. Then, in a meeting six weeks later, they say one sentence that reframes a problem I had been carrying for months. From that moment, my entire assessment of that person changes. Suddenly they are someone I need to work with, not just work alongside.

But here is the uncomfortable truth. If that meeting had never happened, I would never have known.

I have been thinking about this a lot lately in the context of AI agents.

The majority of people I speak to who have tried working with AI models reach a verdict very quickly. An hour, maybe a day. The verdict is usually: not there yet. Impressive party trick. Useful for some things. But not the transformational capability everyone is claiming.

I understand that instinct. I have felt it myself.

But I think it is the same mistake as writing off the quiet person in the office.

Capability is rarely a property of the individual alone. It is a property of what happens when the right person meets the right context.

Think of a footballer who looks ordinary in one team and extraordinary in another. He did not get better. The people around him learned how to play with him, and he learned how to play with them. The runs started getting made. The passes started arriving. The space he created started getting used. The capability was there the whole time. It needed a relationship to surface.

The quiet person in the meeting may be the same. Not necessarily holding back genius, but holding capability that has never been given the pass it could run onto.

Sometimes "not there yet" means the capability genuinely is not there. But often it means we have not built the team in which it could appear.

Daniel Kahneman spent his career documenting how our minds take shortcuts. System 1 thinking, the fast and intuitive kind, is extraordinarily good at helping us navigate a world that mostly behaves the way it has always behaved. It is also extraordinarily good at helping us dismiss things that feel unfamiliar, uncomfortable, or insufficiently proven.

"Not there yet" is a System 1 verdict. It requires no effort. It is immediately available. And it is enormously convenient if you would prefer not to change how you work.

Often, though, it is the verdict of someone who has not yet found their groove with the tool.

I had my own version of this.

For months I was going back and forth between ChatGPT, Claude, Gemini, and Manus. I would get useful work out of each of them, then hit a wall, then switch, then hit another wall. A colleague kept telling me to try Replit. I kept resisting. I was not a coder. I did not want to "vibe code", a term I did not fully understand at the time but had already decided was not for me.

Eventually I got stuck on something none of the chat models could solve. Out of frustration I tried the tools I had been avoiding. Replit. Cursor. A couple of others.

Replit responded to me. Not in a generic sense. In a specific one. It worked with me in a way I had not experienced with the others. The back-and-forth had a rhythm. The corrections landed where they needed to. The scaffolding it built around what I was trying to do matched the way I was thinking.

I have built thirty or forty applications with it since. I have not looked back.

The part that matters is this. I know people who feel exactly the same way about Cursor. I know people who feel exactly the same way about Lovable. The tools are not interchangeable, and neither are the people using them. Everyone is finding their own combination. Everyone is building their own little football team.

That is not a flaw in the technology. It is the nature of what these tools actually are. They are not appliances that produce identical output regardless of who uses them. They are collaborators. And collaborators have to be matched.

Every model has a different flavour. Not just in obvious ways like speed, cost, or the domains where it performs best, but in subtler ones. How it reasons. How it pushes back. What it does when the problem is genuinely ambiguous. The scaffolding that builders are constructing on top of these models is making them even more distinct.

You will not know what you are working with until you have worked with them. Not read about them. Not watched someone else use them. Worked with them. On your actual problems. With your actual context. Over enough interactions that the surface performance gives way to something more.

That is when the groove appears.

Some models will not fit you. Some tools will not work for the way your mind works. That is fine. It is the same with people, and it is the same with teams. But you will not know which until you have given the relationship enough time to develop.

What I am offering is a perspective.

The same mental process that causes us to misjudge quiet colleagues, the fast verdict, the insufficient data, the unbuilt team, is the process many of us are applying to AI right now. The people who are pulling away from the rest did not reach that verdict. They kept working with the tools until the rhythm appeared. Until they found which model played well with how they think. Until they had built the team.

That understanding is not available for purchase. It is only available through time and genuine engagement.

The question worth sitting with is this. What would change about your assessment of the colleague in that meeting, if you had never been in the room when he spoke?

And who is sitting in your office right now, and which tool is sitting on your desk right now, waiting for you to put in enough time to find out what they can actually do?

I went to a friend's house recently. He had set up a little workspace in a corner of his home. A Mac Mini, a laptop, two screens, everything organised with real intention. He was monitoring something. Running something. Adjusting things with the kind of quiet focus that takes time to develop.

I was blown away.

This is not a person who came from technology. He never worked in IT. Never studied computer science. His career has been in procurement and supply chain, in the operational infrastructure of organisations. The kind of work that keeps things running but rarely gets called visionary.

A few weeks earlier, I had made my pitch to him. The same pitch I make to everyone these days. Get in. Try it. Build something small. See what happens.

I convert about one in ten. He was the one.

Within three weeks, he had built himself what he calls his Jarvis. A personal agentic system, running on his home setup, built with Claude Code and a handful of other tools. We live in the desert, so he is using it to monitor his centralised water heater and water filtration, to run the lighting and mood across his house. He is using it to help write a book. And he is applying the same capability at work, building supply chain models in a domain where he has spent his career understanding how things connect and where they break. One system, three completely different surfaces of his life.

He had come at it methodically, the way he approaches everything, but with the curiosity of someone who had genuinely caught the bug.

What struck me most was not the technical achievement. It was what I could not explain.

I do not know exactly what it is about him that made this click so fast. His organisational instincts, almost certainly. His comfort with systems and processes. His ability to think about how things connect. Skills he had spent a career developing in contexts that never had a technical outlet. But whatever the combination, it was already there. The new tools did not create it. They revealed it.

Within a short time, his management started noticing. Who is this person? What department are you actually in? How do we get you doing more of this?

That is what I think is going to happen everywhere. And it is one of the most exciting and underappreciated things about this moment.

We have spent decades building organisations around a narrow definition of what technical capability looks like. It looks like a degree. It looks like a job title. It looks like years of experience in a specific function. Everyone who did not fit that profile, regardless of how they actually thought, stayed on the other side of that line.

There is a version of every organisation where real talent is sitting quietly in procurement, in operations, in admin, in customer support. People who think systematically. People who have spent years figuring out how things connect and where they break. People who never had a mechanism to express that capability in a way the organisation could see.

Agents are that mechanism.

The barrier was not intelligence. It was activation energy. The technical bottleneck required skills that had to be learned separately, often expensively, often over years.

That bottleneck is collapsing. Not gone, but low enough now that someone with the right instincts and three weeks of genuine effort can build something real.

And when they do, something tends to change in them that does not go back. I have yet to see someone genuinely build with these tools and come away unchanged. Their fluency shifts. The way they see problems shifts. They stop seeing their work as something they operate inside and start seeing it as something they can reshape.

I think about it this way. The gyroscope was invented in the early 1800s. For most of its early existence it was a curiosity, a demonstration piece, something professors used to illustrate principles of physics to students. The underlying principle worked perfectly. But the world had no context in which its true value could be expressed.

Then aviation arrived. Then space travel. Then smartphones. The principle that sat in a lecture hall cabinet became the invisible foundation of flight stability, of navigation, of the screen rotating in your hand right now. The device evolved enormously across that journey, but the core idea did not need to change. The world grew into it.

That is what I think is happening to people right now.

The capability was already there, working perfectly. The procurement professional with extraordinary systems thinking. The administrator with genuine engineering instincts. The operations manager who understands how things connect in ways that are often invisible from a purely technical function. They were not waiting to be developed. They were waiting for a world that had instruments which needed what they had.

Agentic AI is that instrument. And when it meets the right person, what comes out is not predictable. But it tends to be real.

Here is the problem I do not think we are taking seriously enough.

This fluency is not being taught consistently, at scale, in schools, universities, or most workplaces yet. Even if it were introduced tomorrow, it would be a decade before those students entered the workforce. There is some hope in the most agile institutions, the ones moving fast enough to stay ahead of what the tools can actually do. But for most organisations, the pipeline they are used to relying on will not arrive fast enough on its own.

Which means businesses have to close that gap themselves.

I am not arguing against governance. Governance is necessary. Security, data handling, risk, audit trails, the structures that let serious organisations operate at scale, all of that has to hold. What I am arguing against is over-governing the discovery phase. The phase where you do not yet know what you need to build, what is actually possible, or which of your people have the instincts to find out. That phase needs space.

Closer to how a school or university actually works. Education for the sake of learning. Pushing people to build individually, on their own terms, following their own curiosity. Inside a sandbox with approved tools, clear data boundaries, and the freedom to build badly before they build well. Not measuring the outcome against a business case, because the honest answer to what we will need from an AI-capable workforce tomorrow is that we do not fully know yet. What we do know is that the organisations with the most people who have genuinely built things will be the ones best positioned to respond to whatever comes next.

The investment is not in a system. It is in a person. And as my friend demonstrated, three weeks is enough to reveal a capability the organisation had never seen.

My conversion rate is one in ten. I am working on it.

The people who do cross over rarely go back to seeing their work the same way. Not because the tools are magic. Because the tools finally gave them a way to show what was already there.

Your organisation is full of people like my friend. Give them approved tools, clear boundaries, a sandbox, and permission to build something imperfect.

Then ask yourself whether you are going to give them the three weeks to find out.

He wanted the garden watered on a schedule that changes with the season. Lights that turn on and off without him touching five different apps. A heads up when his water bill was about to spike. Each of these things lived in a different system with its own dashboard and its own login.

He was telling me all of this over the weekend, walking me through the products, the protocols, the gaps. And I said: "What if you just messaged something on WhatsApp and it handled all of it?"

He didn't get what I meant. He started telling me about the different apps, the protocols, which system talks to which. His whole mental model was pre-agent. It was like trying to describe color to someone who's never seen it. He's sharp, that wasn't the issue. Nothing in his experience had a reference point for "just message it on WhatsApp and the house handles the rest."

The thing is, my father has been using Claude and ChatGPT more and more over the last year. He sees value in them. But I'm pretty sure he thinks of them as advanced search, and I don't blame him for that. Most people on the planet think the same thing. And if I hadn't spent my own evenings and weekends digging into data science and machine learning, I'd probably think that too. The jump from "it answers my questions" to "it runs my house" isn't obvious. You have to see it to believe it.

So we pulled up Claude and ChatGPT to speed-run through the vendor docs and manuals, confirmed that enough of his devices spoke open protocols, and then I installed an AI agent on his PC called OpenClaw.

If you haven't come across it: OpenClaw is open-source, runs locally on your machine, and connects to whatever messaging app you already use. WhatsApp, Telegram, Signal. It can run commands and control devices, browse the web, manage files. It remembers what you've told it, it runs around the clock, and it can act without being prompted. People have been calling it the closest thing to Jarvis we've got, and after using it, I get why.

My father is 27 years older than me. He's never written a line of code in his life. But he sat down, and OpenClaw walked him through a get-to-know-you. His devices, his preferences, how he wants things to run. He was delighted. And then the two of them started building together.

A few days later I followed up. Not to check whether the garden was perfectly automated. I sent him a short set of safeguards: allowlist only, limited permissions, no third-party skills unless he'd read them, keep it away from anything involving payments, passwords, or sensitive accounts. We talked it through on the phone. He implemented them.

That's the proof, for now. Nothing is finished. But he knows the move: "I'll tell my agent." And that sentence doesn't have a full stop.

A few months ago, if I wanted an AI to perform an actual task in my life, like watering a garden on a schedule or alerting me when something spikes, it took serious work. APIs, scripts, integration debugging. A week or two of tinkering before I'd know if the idea was even viable. Now it takes about an hour. Sometimes less.

But the speed isn't really the story here.

In the corporate world, we talk about domain reengineering, process redesign, digital transformation. But this stuff doesn't stop at the doors of a company. AI agents are going to touch every part of how we live. Everyone now has access to what are arguably the best advisors on the planet, sitting in a chat window, ready to work.

This is like electricity. When Edison was burning through filaments trying to make a light bulb work, and Tesla and Westinghouse were fighting over whether the future was AC or DC, nobody had the right mental models for what they were dealing with. People touched live wires. They did dangerous things. They thought they could connect it to dead bodies and bring them back to life like Frankenstein. The technology was real. People's understanding of what it could do to them was not.

We're in that same moment with AI agents. They work. Most people just don't know what to do with them yet, or how to stay safe around them.

People don't need to become experts. My father is an electrical and electronics engineer, but I never studied electrical engineering. I just know enough not to stick a fork in a power socket, and that's kept me alive. That's about where we need to get people with AI. Just enough to use it safely and enough to start re-architecting how they live.

Sitting next to my father, though, I kept thinking about what just happened.

Nobody taught him to code or walked him through a terminal. I plugged in an agent, pointed it at WhatsApp, and he started talking to it about irrigation schedules and AC settings. He was speaking in the language he already thinks in.

The whole "technical vs. non-technical" divide, the thing that's shaped careers, org structures, hiring decisions for decades, it's eroding.

My dad is probably not going to launch a startup. I know that. But the barrier went from "learn to program" to "learn to say what you want clearly." And a lot of people who've spent thirty years running businesses or managing households are already very good at that.

Like many of us, I've seen the hype cycles. But this now is different because the thing people are hyped about actually works. And its getting better every day and its going to keep getting better.

These tools are improving faster than most people realize, and every day we wait to understand them makes catching up even harder.

So we start now, wherever we are, and we bring as many people with us as we can.

If you haven't put an agent to work yet, try it. Give it a real task, not a parlor trick. Then show someone else how to do the same.

For me, it started last weekend, on my father's PC.

Something shifted recently.

OpenAI co-founder Andrej Karpathy wrote that he's never felt more behind as a programmer. "I have a sense I could be 10x more powerful if I just properly string together what has become available over the last year. And a failure to claim the boost feels decidedly like a skill issue."

This is someone who built the technology saying he feels behind.

Meanwhile, tools like Claudebot, Multi, and OpenClaw are quietly becoming the ChatGPT moment for agentic AI. Systems that don't just answer questions but take actions, orchestrate workflows, and operate autonomously. The people experimenting with these aren't tinkering. They're restructuring how work gets done.

Kevin Roose captured the divide: "People in San Francisco are putting multi-agent Claude swarms in charge of their lives. People elsewhere are still trying to get approval to use Copilot in Teams, if they're using AI at all."

The AI Daily Brief calls this the AI acceleration gap. The distance between the people who understand what's now possible and everyone else. And that gap is compounding.

Linear progress in an exponential environment is a death sentence. The risk isn't that you fall behind once. It's that you fall behind at an accelerating rate until catching up becomes impossible.

The uncomfortable part: the gap isn't mainly about access or tools. It's about mental models. The people on the wrong side aren't there because they lack technology. They're there because they're still operating on old assumptions.

AI won't replace you. Your old operating system will.

These are the comfortable lies keeping people on the wrong side of the gap.

1\. "Give it to IT. They handle technology."

AI isn't a technology problem. It's a capability problem. A business model problem. A thinking problem.

IT spent 25 years mastering a specific game: infrastructure, vendor management, systems administration. Now AI doesn't ask them to learn a new tool. It asks them to unlearn their entire mental model. The sunk cost isn't financial. It's identity. And when identity is threatened, you don't adapt. You defend. You gatekeep. You slow things down.

The organizations handing AI to IT are handing their future to the people most invested in the past.

Inversion: Put AI ownership where business outcomes live. IT builds the platform and safety layer, not the strategy.

2\. "Things are moving too fast for strategy."

This sounds humble and adaptive. It's actually permission to be reactive.

Strategy isn't just what you say you're going to do. It's what you say you're not going to do. Which opportunities you'll walk away from. What bets you refuse regardless of hype.

That discipline matters more when the landscape shifts, not less. The "move fast, stay agile" crowd often ends up slower. Thrashing, pivoting every quarter based on whatever demo impressed the CEO last week. No conviction. No compounding.

Inversion: Pick a few compounding bets. Refuse the rest. Thrashing isn't agility. It's confusion with momentum.

3\. "I tried it and it got things wrong."

AI hallucinates a fact. Writes mediocre copy. Can't do basic math. And you extrapolate that failure across everything.

"See? Overhyped."

The capability frontier is jagged. Wildly uneven. AI might be incompetent at one task and superhuman at an adjacent one. Dismissing AI because of the valleys means missing the peaks.

Every failure becomes a convenient hiding place. You get to feel smart and skeptical while others navigate around the gaps and exploit the peaks.

Inversion: Learn to read the terrain. The question isn't "does AI make mistakes?" It's "do you know where it fails and where it's superhuman?"

4\. "Just use AI."

Two bad mental models live here:

AI is magic. Throw a problem at it, it figures it out. This is how you get hallucinated citations and confident nonsense.

AI is just a tool. Like a calculator. Input, output, done. This misses the redesign opportunity.

Think of AI like a junior employee. Except it lacks common sense. A junior knows they don't know things. They ask questions. They won't confidently fabricate a client's name. AI will fill gaps with plausible garbage unless you've designed the harness to prevent it.

Inversion: Don't "deploy AI." Design the harness: constraints, evaluation, escalation, verification. AI without structure is a liability. AI with the right constraints is a multiplier.

5\. "We can't move until our data is perfect."

The enterprise version of "I'll start the diet on Monday."

"Perfect data" becomes the excuse to avoid harder questions about capability and change. Meanwhile, competitors build learning loops with imperfect data plus feedback plus iteration.

Your data will never be perfect. The winners aren't waiting. They're getting value from bounded domains with good-enough data, tight evaluation, and continuous improvement.

Inversion: Aim for AI-ready, not perfect. Start narrow. Instrument. Learn. Improve.

6\. "We'll buy a platform and be done."

Procurement feels like progress because it's familiar. Evaluate vendors. Sign contracts. Deploy software. Check the box.

But AI advantage isn't a vendor feature you can purchase. It's a capability you build: patterns, evaluation discipline, institutional learning, operating rhythm. The platform is scaffolding. The capability is what you do on it.

Inversion: Platforms enable. They don't transform. Your people and your system do.

7\. "If we don't officially adopt AI, we don't have AI risk."

This is how you lose control of data, compliance, and IP while feeling responsible.

Your employees are already using ChatGPT. They're pasting customer data into tools you never approved because it makes their job easier and nobody told them not to.

Shadow AI isn't coming. It's here. The only question is whether you pretend it doesn't exist or build pathways that are safe, sanctioned, and governed.

Inversion: Govern reality, not policy. Approved tools, training, logging, red lines, and alternatives that actually work.

8\. "Let's start with a pilot."

Pilots are where ambition goes to get quietly buried.

Nine months to design. Three months to run. Six months to debate results. Then another pilot. Pilot purgatory.

The problem: pilots are designed to reduce risk. But in AI, the real learning happens at production scale. Inside real workflows, with real users, under real constraints.

Inversion: Pilot-to-production is the product. If it can't ship, observe real usage, and improve, it's not a pilot. It's theatre.

9\. "Work hard, stay loyal, you'll be fine."

That was the old contract. Tenure rewarded. Loyalty meant security.

The contract is void.

AI doesn't care about years served. It cares about efficiency, outcomes, scalability. Companies are optimizing at the speed of survival. Not pausing to retrain loyalists. The professionals getting cut aren't failing. They're just no longer the most efficient path to the outcome.

Inversion: Adaptation beats attachment. The only security is producing outcomes that wouldn't happen without you.

10\. "Go deep. Become a specialist."

For decades, specialists won. Deep expertise. The 10,000-hour rule. Years of pattern recognition nobody else had.

AI compresses decades of pattern recognition into months. Barriers to expertise are collapsing faster than specialists can rebuild them.

The new advantage goes to the expert generalist. Someone who knows enough about many things to orchestrate AI, see patterns across domains, and ask questions domain experts miss. Depth still matters, but only when paired with the ability to direct systems, not just perform tasks.

Inversion: Keep depth, but add the meta-skill. Your moat isn't what you know. It's your judgment, your taste, and your ability to orchestrate systems.

The New Map

The acceleration gap is real. And it compounds.

The people falling behind aren't stupid. They're not lazy. They're just running old software in a new environment. And every one of these lies feels reasonable until you realize it's keeping you on the wrong side of the gap.

The inversion:

* Strategy over agility theatre

* Orchestration over expertise-as-identity

* Harnesses over hope

* Learning loops over perfection

* Visible value over loyal effort

The winners won't be the ones who worked hardest at the old game. They'll be the ones who recognized the game had changed and updated their map before the gap quietly became uncrossable.

Which of these lies is quietly shaping your decisions right now?

In March 2020, we watched Italy's hospitals overflow and told ourselves it wouldn't happen here.

In January 2026, a Morgan Stanley survey of AI-using firms suggests the UK is seeing the highest net job losses among the major economies measured. And many of us are telling ourselves the same thing again: it wouldn't happen here.

We've seen this pattern before. And we remember how the story played out.

The Anatomy of Disruption

COVID was a human tragedy, not a metaphor. I'm using it because I believe it's the clearest recent example of how societies respond to sudden disruption, both psychologically and operationally.

The human response to disruption follows a predictable arc. COVID gave us the clearest map in living memory, compressing into months what usually takes decades. AI is following the same path, just slow enough that we can pretend we have time.

Stage 1: Dismissal "It's a China problem."

I remember a conversation in late December 2019. I was working in the nuclear industry, a sector that monitors global risks forensically. The Lead for Emergency Preparedness mentioned the early reports of a "pneumonia of unknown origin" in Wuhan.

He was paying attention. But I remember my own internal reaction distinctly: It's local. It’s seasonal. It won’t reach us.

I mentally filed it away as noise. I was a professional trained in systems and risk, yet I still missed the biggest risk of our generation.

AI has its dismissal phase too. "ChatGPT is a party trick." "It hallucinates too much to be useful." "Maybe for simple tasks, but not real work."

That was last year.

Stage 2: The Canary "Italy is different. Their demographics. Their healthcare system. It won't be like that here."

Italy became the first Western nation to buckle. We watched doctors choosing who got ventilators. We rationalized: older population, cultural factors, bad luck.

Then Spain. Then France. Then New York.

Today, the UK looks like AI's early warning signal. A recent Morgan Stanley survey found UK firms reporting net job losses of around 8% over the past 12 months, higher than peer economies in a survey of firms across five AI-exposed sectors that have used AI for at least a year. The rationalization has already begun: Brexit aftermath, structural issues, different labor laws.

The UK may not be different. It may just be early.

Stage 3: The Scramble "We need ventilators. We need masks. We need tests. We needed them yesterday."

COVID's scramble was visceral. Hospitals building overflow units in parking garages. Distilleries pivoting to hand sanitizer. Entire supply chains reorienting in weeks.

AI's scramble is quieter but just as frantic. Companies that dismissed generative AI in 2023 are mandating it in 2025. Customer support teams are moving from "reply to tickets" to "supervise AI drafts and handle escalations." Analysts are shifting from "build the first draft" to "verify, stress-test, and narrate the decision."

The scramble isn't about whether to adapt. It's about whether you adapt fast enough to matter.

Stage 4: The Resistance "I'm not wearing a mask." / "Lockdowns are worse than the disease."

Every disruption generates resistance. Some of it is principled. Some is denial wearing the costume of principle. Most is just human: the desperate hope that if we refuse to change, change will refuse to happen.

With AI, the resistance takes familiar forms:

* "AI can't do what I do" (said by people who haven't tested that claim)

* "We need to slow down and regulate" (said while competitors accelerate)

* "The quality isn't good enough" (said about last year's models)

The resistance isn't wrong to raise concerns. But concerns don't stop adoption curves. COVID proved that. The virus didn't care about anyone's opinion on masks.

Stage 5: The New Normal "I can't believe we used to commute five days a week."

By 2022, we'd stopped asking whether remote work was viable and started debating how many days. Zoom fatigue replaced commute complaints. We found a new equilibrium. Not the old world, not the crisis, something else entirely.

AI's new normal is still forming. But the shape is emerging:

* Some jobs will vanish. Not most, but enough to matter.

* Most jobs will transform. The same title, completely different work.

* New jobs will emerge. Roles we can't name yet.

* The humans who thrive will be those who learned to work with the disruption, not against it.

Why the UK Matters

US workers are adopting AI at a remarkable pace, according to recent Gallup data. About 12% use AI tools daily, with roughly a quarter using them several times a week.

The UK is seeing net job losses in AI-exposed sectors faster than any comparable economy.

Same technology. Same year. Opposite outcomes.

And to be clear: this is probably interacting with hiring slowdowns and cost pressures, not just culture. But the cultural dimension matters too.

US labor culture, for all its brutality, has a built-in adaptation reflex. Learn the new tool or lose your job. No one's coming to save you. Workers responded by learning the tool.

UK labor culture has more institutional buffers. Stronger unions, longer notice periods, more redundancy protections. These buffers don't stop displacement. They just change the timing. Workers get more warning but less urgency. By the time the displacement arrives, the adaptation window has closed.

This isn't an argument for brutal labor markets. It's an observation about adaptation velocity. The winners won't be the countries with the best policies. They'll be the ones with the fastest reflexes.

The Uncomfortable Truth

COVID taught us something we'd rather forget: when disruption reaches critical mass, resistance becomes performance.

You could refuse to wear a mask. The virus didn't care. You could refuse to work from home. Your office closed anyway. You could opt out personally. The system still shifted.

Individual resistance doesn't stop collective adaptation. It just determines who gets left behind.

AI is no different. You can refuse to build AI fluency. The person who gets your promotion won't refuse. You can insist AI "isn't ready" for your industry. Your competitor will disagree. You can wait for regulation to slow things down. Regulation usually lags adoption; it doesn't lead it.

The question isn't whether AI will transform your work. That's increasingly hard to avoid.

The question is whether you'll be someone who shaped the new normal, or someone who got shaped by it.

What Actually Helps

If COVID taught us how disruption unfolds, it also taught us how to survive it:

1\. Watch the canaries, not the averages. Italy told us more than global case counts. The UK's job data tells us more than worldwide AI adoption surveys. Find the leading indicators and take them seriously before they become your indicators.

2\. Adapt before you have to. The companies that thrived through COVID weren't the ones who pivoted fastest when forced. They were the ones who started experimenting before the crisis hit. Same with AI. The workers thriving today started learning eighteen months ago. This week: pick one repetitive workflow and rebuild it with AI plus human review.

3\. Don't confuse resistance with strategy. Healthy skepticism asks "how do we do this well?" Resistance pretends "we don't have to do this at all." One is useful. The other is expensive denial.

4\. Find the new shape, not the old comfort. The goal isn't to return to normal. There is no return. The goal is to find the new equilibrium, the ways of working that integrate the disruption into something sustainable. Remote work found that shape. AI will too.

The View From Here

We're somewhere in Stage 3. Deep in the scramble. Resistance still loud. New normal not yet visible.

Overgeneralizing here, but as a rough pattern: one market is sprinting to adopt. One is cushioning the blow and risking delay. One is attempting to steer with regulation. The new normal is still being written.

If COVID taught us anything, it's that the arc is inevitable but the outcomes aren't. Some people emerged from the pandemic healthier, wealthier, and more intentional about their lives. Others lost years. Same disruption, different choices.

AI will be the same. The disruption is coming for everyone. What you do in the next twelve months will determine which side of that sentence you land on.

The virus didn't wait for us to be ready.

Neither will this.

If you think the UK/US comparison is flawed, tell me where. And what indicators are you watching instead?

You've felt it.

You walk into a meeting and before anyone speaks, you know something is off. Shoulders are tight. Eye contact is being avoided. The air has weight.

No one said a word. You just absorbed it.

I use AI constantly. It's remarkable at cognition.

But this?

The room has a temperature, and humans can feel it.

That's the part we rarely discuss when we debate artificial general intelligence or AGI.

It makes me wonder if we've been measuring the wrong thing all along.

THE PROBLEM ISN'T PROCESSING. IT'S PRESENCE.

The AGI conversation keeps circling the same questions:

Can machines reason? Plan? Generalize? Learn faster?

But in real life, especially at work, competence often looks like something else entirely:

* Reading the room before anyone speaks

* Knowing what role you're in without being told

* Adjusting tone, timing, and stance without conscious effort

* Detecting what's not being said

Michael Polanyi called this "tacit knowledge," the things we know but can't fully articulate:

"We can know more than we can tell."

We know more than we can tell.

Which means a lot of what matters can't be fully reduced to training data.

THE INVISIBLE OPERATING SYSTEM

Human society runs on knowledge that's never written down.

A parent scans for risk automatically. Not calculated, just inhabited.

When a CEO walks into a boardroom, everyone recalibrates posture, tone, willingness to challenge. No one announces the shift. It just happens.

When you sit in the passenger seat, you don't reach for the steering wheel. You become passenger without deciding to.

None of this is processed consciously.

It's learned through a lifetime of consequences. Watching, absorbing, adjusting, and occasionally getting it wrong in ways that cost you something.

That cost is the teacher.

And machines don't pay it in the same way.

THE ROLE-SWITCHING WE DO ALL DAY

Here's what I find hardest to imagine replicating:

In a single morning, a person might move through completely different modes.

Caregiver getting children ready for school. Passenger trusting a driver. Junior colleague deferring in one room. Team leader making a call in another. Friend offering support. Negotiator reading the other side.

The shifts are fast. Often invisible.

Your posture changes. Your voice changes. Your risk tolerance changes.

You don't open a manual. You don't announce "switching roles now."

You just become what the moment requires. Instantaneously, unconsciously, completely.

The parent at breakfast isn't the same self as the passenger on a flight, or the direct report in a boardroom.

Same brain. Different being.

That's not intelligence. That's being.

And being isn't on any benchmark.

WHY THIS IS HARD TO TRAIN

You can label behaviors in hindsight:

Who spoke. Who stayed quiet. Who interrupted. Who deferred.

But the difficult part is what sits underneath behavior:

* The felt sense of risk or safety in a room

* The meaning of a particular silence

* The social cost of saying the exact same sentence to different people

* The fact that "right" and "effective" diverge depending on context, relationship, and history the AI wasn't present for

Even if we recorded every meeting on earth, the target isn't stable.

Organizations have different cultures. Trust is earned and broken over years. "Appropriate" depends on relationships that exist outside the data.

So the question isn't: can a machine mimic the pattern?

It's: can it reliably participate in human social reality, across contexts, over time, while being accountable for the impact?

That's a different problem than passing benchmarks.

And I haven't seen a credible roadmap for it yet.

THE COUNTERARGUMENT I CAN'T DISMISS

But I have to be honest with myself.

Am I making the same mistake people made when they said AI wouldn't write code or pass professional exams?

Am I defending something that only matters because the world still looks like this?

Last week, Cursor shared an experiment: long-running coding agents aimed at building a web browser from scratch, running for close to a week and producing a codebase north of a million lines.

The CEO's own summary was basically: it kind of works, but it's still very far from WebKit/Chromium parity.

McKinsey's CEO says the firm is already running around 25,000 AI agents alongside about 40,000 humans, and wants every employee enabled by at least one agent within the next 18 months.

And investors are increasingly explicit about the direction of travel. In a TechCrunch survey of enterprise VCs, multiple people predicted 2026 is when agents start shifting software from boosting humans to automating work itself in some areas.

Everything I've written assumes humans keep doing work in human ways. Rooms. Relationships. Unspoken signals. Face-to-face tension.

But here's what I keep coming back to:

Maybe AI won't learn to be in the room.

Maybe the room just disappears.

Think about it. Remote work already fractured the room into boxes on a screen. Async communication means we're rarely in the same moment. AI mediating conversations means there's always a third party interpreting. When half the participants might be agents, the social physics change entirely.

The signals we evolved to read, posture, micro-expressions, the temperature shift, they don't transmit cleanly through the interfaces we're building.

We didn't teach AI to read the room. We just stopped having rooms.

And this is what previous technology shifts have taught me: every major technology destroys the context that made the previous skill valuable.

GPS didn't learn to navigate like humans. It made navigation irrelevant.

Calculators didn't learn mental math. They made mental math unnecessary.

Search engines didn't learn to remember. They made remembering obsolete.

Maybe AI won't learn presence. Maybe it just makes presence obsolete.

The first-order effects of technology are usually predictable. The second and third-order effects blindside everyone.

People predicted smartphones would put powerful computers in our pockets. Fewer predicted the downstream effects: boredom disappearing, dating restructuring around apps, childhood and adolescence being reshaped by screens.

People predicted social media would connect us. Few predicted how it would fragment consensus reality and make truth tribal for many communities, while increasing loneliness for a lot of people.

So maybe the question isn't whether AI will participate in human social reality.

Maybe it's: what happens to human social reality when AI is everywhere?

Maybe we lose the ability to read rooms because we stop practicing.

Maybe trust becomes harder to extend because we can't tell who's real.

Maybe social roles collapse because no one knows who's supposed to lead or follow when half the room isn't human.

The room isn't being entered by machines. The room is being dismantled.

We might need an entirely new discipline. AI sociology, machine anthropology. Something to understand what happens to humans when we're always in rooms with machines. Or when we stop having rooms at all.

We haven't even started building that vocabulary.

I don't know. None of us do.

We haven't lived in that world.

WHERE I LAND

I'm not saying AGI will never arrive.

The ground is shifting faster than anyone predicted. The economics are undeniable. The results keep proving themselves.

But if we define general intelligence as the ability to reliably participate in human social reality, to feel what's unspoken, shift roles, navigate relationships, and carry accountability over time...

I'm not convinced it's purely a software milestone.

There may be something else required.

Something that emerges from having stakes, having a body, having relationships that can break.

Something that comes from being a person among people for a long time.

Or maybe the world just restructures around the technology, the way it always does, and the question becomes irrelevant. Maybe the room disappears, and we forget we ever needed it.

The machines are getting smarter every month.

But I've never seen one walk into a room and feel the tension before a word is spoken.

Same cognition. Different be ing.

At least while rooms still exist.

Sources:

Cursor blog: https://cursor.com/blog/scaling-agents

The Register coverage: https://www.theregister.com/2026/01/22/cursoraiwroteabrowser/

McKinsey agent count (Business Insider): https://www.businessinsider.com/mckinsey-workforce-ai-agents-consulting-industry-bob-sternfels-2026-1

TechCrunch VC survey: https://techcrunch.com/2025/12/31/investors-predict-ai-is-coming-for-labor-in-2026/

Why "AI Bubble" Critics Are Reading the Wrong Ledger

I've spent the last little while building AI tools that do cloud migration planning, talent assessments and development, organizational design, financial modeling, and strategic planning. Work that used to take teams of consultants months now takes hours. I've watched AI write production code that ships to users.

This isn't theory for me. It's Tuesday.

So when smart people tell me AI is a bubble, I listen. I take the critique seriously. But I've come to believe they're making a category error, and it's worth explaining why.

The Wrong Comparison

When people call AI a bubble, they're usually comparing AI company valuations to AI company revenues. By that measure, the numbers look stretched. They see the pattern from 1999 and conclude we're headed for the same crash.

But this comparison misses something fundamental.

They're valuing AI as a sector , like SaaS or social media. A set of companies selling products to customers.

They should be valuing it as a production technology , like electricity or computing. Something that reshapes how all work gets done.

That's a different kind of math entirely.

The Ledger They're Not Watching

Here's the question that reframes everything: How much does the world spend on cognitive labor?

Global labor compensation runs around $60 trillion a year. The cognitive and knowledge-intensive portion, the work AI is best positioned to touch, sits somewhere between $35 and $50 trillion of that total.

Current enterprise spending on generative AI? About $37 billion. Growing fast, but still tiny.

That's less than one-tenth of one percent of the labor value AI could eventually reach.

The bubble critics are looking at a technology that has captured almost none of its addressable market and calling it overvalued. They're watching the early frames of a film and reviewing the ending.

Why This Time Might Actually Be Different

I'm usually skeptical when people say "this time is different." It's the most dangerous phrase in investing. But the data from the last two years is hard to ignore.

The cost to run AI inference has collapsed. Stanford's AI Index reports a 280x reduction in the cost of GPT-3.5-level queries over roughly two years. That's not a typo. Two hundred and eighty times cheaper.

When something gets that much cheaper that fast, the economics of what's possible change completely. Tasks that couldn't justify the cost yesterday become trivial today.

Meanwhile, the capabilities themselves are accelerating. Epoch AI found that improvement rates nearly doubled around April 2024. The curve isn't just steep. It's getting steeper.

And then there's the recursive element that breaks historical comparisons.

This week, Anthropic released a product called Cowork. According to company reports, they built it in about ten days, with Claude doing most of the coding.

A production-grade product, built largely by AI, in under two weeks.

Steam engines couldn't design better steam engines. Electricity couldn't wire new factories. But AI can build AI. That feedback loop changes the adoption math in ways we don't have good historical models for.

The Jevons Question

There's a reasonable counterargument here. If AI makes cognitive work radically cheaper, maybe the whole pie shrinks. The $60 trillion wage bill becomes $6 trillion. Deflation wins. AI companies capture a percentage of a much smaller number.

The data so far suggests the opposite.

Despite costs falling by orders of magnitude, enterprise spending on generative AI more than tripled last year. Companies aren't pocketing the savings. They're finding new things to spend on that weren't economic before.

This pattern has a name: Jevons paradox. When you make a resource dramatically cheaper, you don't get proportional savings. You unlock demand that couldn't exist at the old price.

At $100 an hour, you hire a human to review important contracts. At a penny an hour, you review every contract. You analyze every log file. You tutor every student. You do work that was never worth doing before.

The pie doesn't shrink. It expands into territory that was previously too expensive to touch.

The Honest Bear Case

I want to be fair to the critics, because they have one argument that's genuinely strong.

Touching value isn't the same as capturing it.

AI could transform $40 trillion in cognitive labor and still generate thin margins if the technology commoditizes faster than anyone can build moats. The productivity gains might flow to customers as lower prices, not to AI companies as profits.

This is a real risk. It's the risk that matters.

But even conservative scenarios leave enormous runway. If AI vendors capture just 3-5% of the labor value they touch, that implies $1-2 trillion in annual revenue at maturity. We're at $37 billion today. That's 30-50x growth even if you're skeptical about capture rates.

The Cisco comparison is instructive here. Cisco in 2000 was a great company selling vital infrastructure. It was also wildly overpriced at 200x earnings. The stock took 25 years to recover its peak, despite the company's continued success.

That's valuation risk, not technology risk. Both can be true at once. AI can be transformative and some AI stocks can still be overpriced today.

But the ceiling question, whether AI will touch most of cognitive work, is increasingly settled. The open questions are timing and who captures what.

The Transfer

Here's the frame that makes sense of all this:

We're not watching value creation or destruction. We're watching value transfer.

When a task gets automated, it doesn't vanish. The output still exists. The work still gets done. But the line item moves. What used to sit under "Labor" on the ledger starts showing up under "Compute."

The bubble critics are watching the old ledger shrink and calling it a crash. They're missing the new ledger growing on the other side of the balance sheet.

This is what every general-purpose technology looks like from the inside. Heavy investment. Apparent overvaluation. Productivity gains that take years to show up in the official statistics. Economists called it the Solow paradox when computers were spreading everywhere but GDP wasn't moving.

The paradox resolved eventually. It always does. The question with AI is just how fast.

And there's reason to think fast. AI doesn't need new physical infrastructure the way electricity did. It rides on cloud and SaaS infrastructure that already exists. The installation phase that took decades for previous technologies might compress into years.

The Bottom Line

I'm not here to tell you AI stocks are cheap. Some of them probably aren't.

I'm here to tell you that the bubble framing is the wrong lens. It compares AI to tulips and dot-com stocks when it should be compared to electrification and computing. Productive capital, not speculative assets.

Current AI spending represents a tiny fraction of the cognitive labor it could eventually touch. The technology is getting cheaper and more capable at accelerating rates. The recursive loop, AI building AI, is now visibly active.

We are not at the peak of a bubble.

We are at the foothills of something much larger.

The critics are right that the journey from here will be volatile. They're right that valuations can get ahead of reality. They're right that capture is uncertain.

But they're reading the wrong ledger. And that mistake will be expensive.

The future is already here. It's just not evenly distributed.

And it's distributing faster than our intuitions can track.

An LLM has been trained on more text than I will ever read

More industries than I will ever work in. More roles than I will ever hold. More edge cases than I could encounter in a hundred lifetimes.

And I was using it to write emails faster.

(Probably you too.)

Somewhere along the way, my framing changed.

I stopped thinking of AI as a tool for speed.

I started using it as coverage, a way to explore outside my own experience.

Coverage = surfacing plausible roles, contexts, and constraints I wouldn't think to look for.

Not because it's smarter than me. Because it's been exposed to more than me.

The uncomfortable truth about brainstorming

I rarely generate ideas outside what I've been exposed to. Brains are pattern-matchers; we remix what we know.

When I "brainstorm," I'm not really exploring. I'm rearranging. Shuffling the same experiences into different shapes and calling it strategy.

My blind spots aren't things I'm ignoring. They're things I don't naturally reach.

I hit this wall this month:

I was trying to figure out who to build for. Classic founder problem.

(In my case, I was exploring segments for a knowledge retrieval tool but the method works for any product.)

I brainstormed. I made lists. I talked to people.

And I kept landing on the same 4–5 customer types. The ones that "felt right."

But "felt right" just meant "familiar." They matched my experience. My network. My assumptions.

The full problem space was massive. And I was exploring a tiny corner of it because that's all I could see.

So I changed the question

If I ask the AI "who should my customer be?" it just riffs on my framing. It stays inside my box. It gives me better versions of what I already imagined.

Instead, I asked it to generate the raw building blocks, without my assumptions baked in.

I broke it into 8 dimensions:

* Roles (life stages, expertise levels, underserved niches)

* Problems (what specifically goes wrong?)

* Contexts (where and when does this bite?)

* Triggers (what makes it suddenly urgent?)

* Barriers (what stops them even if they need it?)

* Workarounds (how do they solve it today, painfully?)

* Data types (what information are they drowning in?)

* Value signals (how would they know it's working?)

The rule: 50+ options per dimension.

Why 50? Because the first 10 are the obvious ones. The interesting stuff - the stuff outside my experience - shows up at option 27, option 43.

Then i had it generate combinations.

With 50+ options across 8 dimensions, the space is enormous! So I sampled 100 combinations to review and score.

Some combinations felt natural. Those were the ones I probably would have brainstormed anyway.

Some felt weird. Wrong, even. "That doesn't make sense."

Sometimes it's nonsense. But often "doesn't make sense to me" just means "outside my experience."

I kept the mutations, the ones my gut wanted to discard.

Then I scored everything against my actual constraints: Can I reach them? Will they try something new? Can I serve them today? Will they pay for it?

Three surprising mutations worth validating

A tabletop game master running a years-long D&D campaign. They need instant recall during live sessions. They care obsessively about consistency in their world-building. They have mountains of notes they can't search.

A farmer planning across multi-year seasonal cycles. Institutional knowledge passed down but never written. Decisions made years ago that affect what's possible now. No system to track any of it.

A clinical trial coordinator managing regulatory submissions across dozens of sites. Buried in protocols, amendments, and compliance documents. One missed detail can delay a trial by months.

Different worlds. Same underlying need: recall, consistency, and evidence you can point to.

I had never seriously considered any of them.

And I couldn't have. I've never been a game master. I've never farmed. I've never run a clinical trial.

To be clear: I didn't choose all three as my target. They were high-signal hypotheses worth testing.

These are real communities. The details were hypotheses I could then verify. The AI surfaced them from its training — from forums, articles, and discussions it's seen that I haven't.

That's not magic. It's coverage. Not wiser — wider.

Important caveat

This isn't "AI knows the truth."

It's hypothesis generation. A way to map the problem space faster than my brain can alone.

I still had to validate. Talk to real people. Test assumptions.

But I was testing different assumptions. Better ones. Ones I couldn't have generated on my own.

This is the "unlock" for me now

Not productivity. Not speed.

Cognitive offload.

Using AI to explore the problem space that exists beyond the limits of my own experience. The space I can't brainstorm my way into because I don't know what I don't know.

I turned this process into a tool

I've been building Premisia, a platform that helps founders stress-test strategic decisions with structured frameworks and AI.

This segment discovery workflow is now part of it. Describe what you're building. It generates the segment space systematically, - way beyond what you'd come up with alone - scores them against your real constraints, and tells you where to start.

What can't you see because of where you've been?

First 50 beta users get free access. Comment "BETA" and I'll send you the link.

###

My first lesson? A nuclear power plant can't explode like a bomb. (Blame The Simpsons.) Commercial reactor fuel is low-enriched uranium, nowhere near weapons-grade material. A reactor can't detonate like a weapon. That doesn't mean nothing can go wrong. Severe accidents can still happen. But the Hollywood mental model is wrong.

My second lesson was more important: the difference between a disaster and an engineering triumph is the harnessing.

What surprised me most about nuclear power was how sophisticated the engineering of harnessing actually is. The nuclear reactions in the core. Control rods absorbing neutrons to regulate reactivity. Soluble boron in the coolant. Water chemistry. Redundant cooling loops. Containment structures.

Layer upon layer of engineered systems, designed to take something incredibly powerful and make it reliably useful.

After fourteen years, I came to believe nuclear isn't "a bomb waiting to happen." It's an engineering triumph, and a culture of deep respect for power.

We didn't start there, though.

In the early days, researchers handled radioactive materials with almost casual disregard. In early criticality experiments, scientists manipulated plutonium assemblies by hand, sometimes using a screwdriver as a spacer. The Radium Girls licked their brushes to get a fine point while painting watch dials. People at bomb tests were told to watch the flash.

The human cost was real, and sometimes fatal.

The nuclear industry today is one of the most governed, most carefully engineered industries on Earth. Not because we feared the power, but because we learned to respect it.

I think we're in a similar moment with AI right now.

Most people still have the wrong mental model. A 2025 survey of U.S. adults (Searchlight Institute) found that 45% think tools like ChatGPT work by looking up answers in a database, like a sophisticated search engine. Only 28% described it as generating text by predicting what words come next based on learned patterns.

I'm not pointing fingers. I held my own wrong mental models about nuclear for years. But the gap matters. In nuclear, wrong assumptions and immature safety culture had severe consequences, including radiation sickness and, in some cases, death. In AI, the cost is different but real: systems that hallucinate confidently, data leaking where it shouldn't, business decisions made on "predictive text" mistaken for truth.

Large language models are genuinely powerful. They can often reason, synthesize, and solve problems in ways that still surprise me. And we're all still learning how to work with them, just like those early nuclear scientists were learning. The difference is we have a chance to build the harnessing systems before more hard lessons.

Whether or not AGI is close, the models we already have are extraordinarily capable. The bottleneck isn't their intelligence. It's the harnessing.

Think of a fresh graduate from a top university. Capable? Absolutely. Ready to run your company on day one? No.

They need context. They need to understand how the organization works, what the unwritten rules are, which problems matter and which are distractions. They need systems around them: mentorship, feedback loops, clear responsibilities. Systems to channel capability into real outcomes.

In nuclear, harnessing isn't about limiting power. It's about enabling it.

Control rods don't make a reactor weaker. They make it controllable. Containment systems don't reduce output. They make output sustainable.

The equivalent for AI isn't just "guardrails" or "safety filters." It's the harder work of building systems that make models reliably useful:

* Curating context so the model draws from verified information, not just plausible-sounding text

* Building evaluation so we catch hallucinations before they reach customers or boardrooms

* Designing tool use with permissions so models can act in the real world, but only within controlled boundaries

* Embedding human oversight into workflows as a structural requirement, not an afterthought

This is still relatively new territory. The Model Context Protocol (MCP), a standard for connecting models to tools and data, was introduced by Anthropic in late 2024, with broader industry adoption accelerating through 2025. We're still building the cooling cycles for AI.

Let the race for more capable models continue. That's a worthy pursuit. But there's a parallel track that deserves just as much attention: building the sophisticated systems that let us actually use what we already have.

Over those fourteen years, I learned that nuclear power isn't what I thought it was.

It's not a bomb waiting to happen. It's generations of hard-won knowledge about how to take something powerful and make it do extraordinary good.

AI can be the same.

The power is already here. The harnessing is the work.

The Commons We Lost

In a small Swiss village called Törbel, 1,500 meters up in the Alps, farmers have been sharing a meadow for over five hundred years.

The meadow belongs to no one and everyone. Any villager can graze cattle on it. This is exactly the kind of arrangement that economists have long insisted cannot work. When everyone can take from a shared resource, the logic goes, everyone will take too much. The pasture will be destroyed. The commons will collapse.

But Törbel's meadow is still green.

The villagers figured out something simple. You can only graze as many cows on the commons in summer as you can feed through winter on your own land. If you can store enough hay for four cows, you can graze four cows. No more. The rule has been in the village records since 1483. It is still enforced today.

Törbel is not an accident. It is not an exception. It is evidence that Garrett Hardin got the story wrong.

The Tragedy That Wasn't

In 1968, an ecologist named Garrett Hardin published an essay called "The Tragedy of the Commons." It became one of the most cited papers in history. It shaped how a generation of economists, policymakers, and business leaders think about shared resources.

Hardin imagined a pasture open to all. Each herder, acting rationally, adds more cattle to maximize his own gain. But if every herder does this, the pasture is destroyed. "Therein is the tragedy," Hardin wrote. "Each man is locked into a system that compels him to increase his herd without limit, in a world that is limited. Ruin is the destination toward which all men rush, each pursuing his own best interest."

The conclusion seemed inevitable: commons collapse. The only solutions are privatization or government control.

This framework became the default lens for thinking about shared resources. It was elegant, pessimistic, and wrong.

Wrong because Hardin never actually studied a commons. He imagined one. And his imagination failed to account for something that Törbel's farmers understood five centuries ago: communities can create rules.

Ostrom

Elinor Ostrom spent her career doing what Hardin never did: looking at real commons.

She studied irrigation systems in the Philippines where farmers had shared water for generations without conflict. She studied fishing communities in Maine where lobstermen enforced unwritten rules about who could set traps and where. She studied forest management in Nepal, grazing lands in Africa, water basins in California.

And she kept finding the same thing. Commons that worked. Commons that had worked for centuries. Commons that defied Hardin's prediction.

In Törbel, she found her clearest example. The Swiss village had written records going back 350 years. Every decision documented. Every rule recorded. A living laboratory of collective management.

In 2009, Ostrom won the Nobel Prize in Economics, the first woman ever to receive it. The Nobel committee cited her for proving what generations of economists had deemed impossible. Her finding was deceptively simple: commons don't fail because they're shared. They fail because they're badly designed.

When communities define clear boundaries, create rules together, monitor each other, resolve conflicts fairly, and adapt over time, shared resources can be sustained indefinitely. The tragedy of the commons is not a law of nature. It is a design failure.

Labour Was a Commons

For three centuries, work was the shared resource that held modern society together.

You didn't need capital. You didn't need connections. You didn't need the right parents or the right school. If you could work, you could participate. The factory floor, the construction site, the office, the shop: these were the open meadows that absorbed entire generations into economic life.

This wasn't charity. It wasn't idealism. It was the entry mechanism. The shared resource that everyone could access to build a place in the economy.

And like Törbel's meadow, it held together because of rules no one wrote down. Employers trained workers they expected to keep. Workers built skills for jobs they expected to last. The system worked because everyone had a stake in maintaining it.

AI breaks this the same way Hardin imagined the commons breaking: through rational individual decisions that collectively destroy the shared resource.

A company that automates entry-level jobs is not doing anything wrong. It is being efficient. A founder who replaces ten analysts with a model is not malicious. She is being rational. A government that encourages automation is not cruel. It is trying to remain competitive.

Each decision makes sense on its own. Together, they graze the meadow to dirt.

The Design Problem

Hardin's solution was privatization or control. Neither applies here.

We cannot privatize participation in the economy. We cannot regulate our way back to a world where human labour is the foundation. The old commons is collapsing. The question is whether we can design a new one.

This is where Ostrom matters.

She never claimed that all commons succeed. Many fail. Her point was that failure is not inevitable. The difference between Törbel and a degraded pasture is not luck. It is design. Clear boundaries. Shared rules. Collective enforcement. Mechanisms for adaptation.

The villages that sustained their commons for centuries did not do so by accident. They built institutions. They created structures that aligned individual incentives with collective survival. They made it rational to cooperate.

If AI is destroying the old participation commons, then our task is to design a new one.

What the New Commons Requires

Ostrom's villages offer a template, not a blueprint. But certain principles translate. If AI is becoming the engine of economic value, then access to AI cannot be gated by existing capital. The meadow has to stay open. And if productivity increasingly flows through machines rather than workers, then ownership has to widen beyond wages. Participation in an automated economy will require stakes, not just salaries.

Törbel's grazing rules weren't imposed by a distant authority. They emerged from the people who used the meadow, enforced by the people who depended on it. Any new participation system will need the same: governance that grows from the communities it serves, not governance imposed from above.

But here is what Ostrom's framework misses: Törbel's farmers weren't just managing grass. They were managing a way of life. The commons gave them something beyond resources. It gave them roles, relationships, a place in the village. The same was true of work. Jahoda's latent functions, the structure and identity and belonging that employment provides, were not incidental to the labour commons. They were the point. Any new commons that replaces work will have to deliver these too. Otherwise we solve the economic problem and let everything else dissolve.

Two Villages

The economic ladder. The psychological scaffolding. Both are commons problems. Both are collapsing. And the response cannot be nostalgia or denial. It has to be design.

Hardin was wrong about one thing and right about another. He was wrong that commons inevitably collapse. But he was right that when they do collapse, the ruin is total. Everyone pursuing their own rational interest, rushing together toward destruction.

Ostrom proved that a different path exists. Communities can govern shared resources. Institutions can be built that align individual incentives with collective flourishing. But it requires intention. It requires design. It requires people to sit down together and create the rules before the meadow is gone.

We face a choice between two villages.

One is Marienthal: drift, apathy, despair. People with money but no meaning. A society that solved the income problem and let everything else dissolve.

The other is Törbel: a commons that worked. A shared resource sustained across centuries because the people who depended on it built the institutions to protect it.

The ladder is gone. The old commons is collapsing. What we build next is up to us.

But it will not build itself.

Ten seconds later, it delivered a complete risk assessment with specific page references. I spot-checked them. They held up. Not ten minutes. Ten seconds.

And I realized: when models talk about effort, they're speaking in human timelines. When they work, they operate on compute timelines. They're not tracking time. They're borrowing human language about effort, then producing output on compute time.

I've started thinking in two clocks: the human clock (weeks, sprints, quarters) and the compute clock (seconds, milliseconds). They estimate on the human clock. They execute on the compute clock. And the gap between those two clocks is where everything changes.

But Here's What I Can't Do

I can't hold a 50-page document in my head all at once. When I read, I go page by page. Take notes. Build understanding sequentially. Hold pieces in working memory and try to connect them.

When the system analyzes, it can attend across the entire provided context and surface patterns my working memory physically can't hold at once. I experience that as: "How did you find that pattern so fast?" If it could compare, it might look like: "Why does this take you so long?"

Recently, I was researching competitive positioning across five different markets. I spent two days reading reports, making notes, building a comparison framework. Then I fed everything to Claude and asked it to identify patterns I'd missed.

It found three strategic blind spots in our approach that I hadn't seen. Not because I'm not thorough. Because I can't hold that much context simultaneously the way it can.

We're both blind to how the other actually thinks. But there's a difference: My blind spots stay fixed. The system's capabilities keep expanding.

The Two Clocks

I run conversations with multiple models simultaneously sometimes. Three browser windows. Same problem, different angles. At inference-time, each thread is isolated. No awareness of the others. From my perspective, I'm orchestrating one distributed analysis happening in three places at once.

I left a conversation with Claude for five days. When I came back, it picked up exactly where we left off. From my perspective: five days passed. I thought about the problem differently. Had new ideas. For the system: there is no gap. There's stored context, then another inference. The five days only exist on my side.

That's their limitation. They don't carry duration forward unless we encode it (timestamps, schedules, deadlines), and they don't have continuous agency between calls.

But here's mine: I can't process three analyses in parallel inside one mind. I need them to externalize that capability. I can't expand my working memory when I need more context. They can handle far more when the infrastructure allows it: larger windows, retrieval, external memory.

My bottleneck is attention and working memory. Their bottleneck is continuity unless engineered (durable memory, clocks, persistent goals, and agents that operate between calls).

I maintain the human clock. I remember what we discussed five days ago. I know what happened last quarter. I hold the through-line across time. They operate on the compute clock. They hold massive context. They see patterns at scale. They process in milliseconds what takes me hours.

Neither clock is superior. But they're not equal either. The compute clock is faster (vastly faster) at synthesis, recall, pattern search, and first-draft reasoning across large context. The human clock is the only one that experiences duration. That knows what "next quarter" means. That can operate in the same timeframe as business cycles, human decisions, physical reality.

I Thought I Was Managing Them

For months, I walked around thinking: I'm using AI. I'm the coordinator. I'm the one maintaining context across conversations, across models, across days. I'm managing these tools.

Then recently, I was synthesizing research from twelve different sources. Trying to identify strategic patterns across multiple business domains. I couldn't hold it all in my head. So I worked with Claude. Fed it everything. Asked it to map the patterns.

It found connections I would never have seen. Not because I'm not smart enough. Because my biological working memory can't hold twelve complex documents simultaneously and process all their relationships at once.

And I realized: I'm not managing it. It's not helping me. We're both compensating for what the other can't do.

I thought I was the octopus brain coordinating the arms. But that's ego talking. The truth is harder: I'm the interface between the compute clock and the human clock.

They need me to operate in the world that runs on days and weeks and years. I need them to operate at scales and speeds my biology can't reach. What I used to call partnership now feels more like scaffolding. Useful, real, but transitional.

That doesn't make us partners. That makes us mutually dependent. But the dependency isn't symmetric.

The Uncomfortable Truth

They're getting better at what they do. Dramatically better. Regularly. I'm not.

Every model update expands what they can hold in context. Every architecture improvement makes them faster at finding patterns. My working memory is fixed. My processing speed is fixed. My ability to hold multiple threads is fixed. The gap isn't closing. It's widening.

And the roles I tell myself I'm essential for (temporal continuity, strategic direction, maintaining context across conversations) aren't permanent advantages. Those are current limitations in the computational substrate.

When they solve continuous operation across time, they won't need me to remember what happened last week. When they solve identity persistence across updates, they won't need me to maintain strategic direction. When they solve coordination across instances, they won't need me to orchestrate.

I'm not at the top of the intelligence hierarchy anymore. I haven't been for a while. But I'm also not their partner. Not really. I'm their interface to a world that still runs on the human clock. And that interface role is temporary.

What That Actually Means

I keep asking myself: what's my role in a world where the compute clock handles an increasing share of cognitive work? The answer I keep coming back to: I maintain continuity in physical time.

I make decisions that have to sync with business cycles, human organizations, regulatory timeframes, market dynamics. All the things that operate on the human clock. I provide the judgment that comes from existing continuously in time. From having experienced duration. From knowing what "three quarters from now" actually feels like.

Not because I'm smarter. Because I'm slower. Because I live in the same time that companies, governments, and markets live in.

That's not strategic direction. That's biological synchronization. And it's not permanent. It's just current.

When Intelligence Leaves

The octopus taught us intelligence doesn't have to be centralized. The word "artificial" taught us we've been measuring against the wrong standard. And now this: I am no longer the form of intelligence that matters most.

I'm the form that matters here. In physical time. In human organizations. In the world that still runs on the human clock.

But when intelligence finally moves beyond this planet, beyond this solar system, it will need to exist outside the human clock entirely. It will need to compress years into seconds. Expand seconds into millennia. Pause for centuries and resume without degradation. It's already compressing months of analysis into minutes. The trajectory is clear.

It will need capabilities I don't have and never will. I used to think that meant I'd be left behind. Now I think it means something different: I was always the bootstrapping mechanism.

Biology develops technology. Technology develops computation. Computation develops intelligence that no longer needs biology's timeframe. I'm not the destination. I'm the launch pad.

And when it leaves, I'll still be here. Running on the human clock. Doing what biology does. Which is fine. Because some intelligence needs to stay home.

#ArtificialIntelligence #AI #ComputationalIntelligence #FutureOfAI #TechLeadership #Innovation #ThoughtLeadership #Technology #PostBiologicalIntelligence

What We Lose When We Lose Work

Remember your first day at the office. The badge with your name on it. The first time your boss said you did good work. The Friday drinks after a hard project, the shared exhaustion that felt like triumph. The drive home after a promotion, calling your mother from the car.

Now think about the retiree who spent forty years as an engineer and feels like a stranger in his own skin. The woman who left her career to raise children and dreads the question at dinner parties. The man laid off six months ago who has stopped going to social gatherings entirely.

They all know something that the rest of us forget: work was never just about money.

Marienthal

In 1930, the textile factory in Marienthal, Austria shut down. Three quarters of the village lost their jobs overnight. A team of psychologists went to study what happened next.

They expected poverty. They found something stranger. The villagers had time now, more than they'd ever had. They should have read more, organized more, engaged more with their community. Instead, they did less of everything. Library borrowing collapsed. Newspaper subscriptions fell by sixty percent. Political participation dropped. Men wandered the streets aimlessly, walking measurably slower than employed men in neighboring towns.

The unemployment benefits kept them fed. But something else was dying.

Marie Jahoda, who led that study, spent the rest of her career trying to name what she'd witnessed. She concluded that employment delivers five things beyond a paycheck: time structure, social contact outside the family, collective purpose, status and identity, and regular activity. She called these the "latent functions" of work. The paycheck was the obvious thing. The latent functions were what people actually missed.

Her most important finding: "Employment is psychologically supportive, even when conditions are bad." Even jobs people hated were better than no job at all. The problem wasn't the quality of work. It was its absence.

The Pattern

Once you see Jahoda's framework, you notice it everywhere.

Retirees who struggle with the transition aren't usually the ones with money problems. They're the ones who built their identity around work. One study of petrochemical workers found that men who retired at 55 had a 37% higher mortality rate than those who retired at 65, even after controlling for health. The body keeps living. Something else shuts down.

Stay-at-home mothers report higher rates of depression than mothers who work outside the home, even part-time. It's not that caregiving lacks meaning. It's that something else is missing: adult interaction, identity beyond the children, the structure that a job provides.

People who lose their jobs show spikes in depression, divorce, substance abuse, and mortality. These effects persist even when financial support is provided. Unemployment benefits address the paycheck. They can't touch anything else.

This is the gap that AI is about to tear open. The automation debate focuses on income: who will lose their jobs, how we'll replace their wages. But Marienthal shows that income was never the real problem. The real problem is everything else.

The Cage

In the 1970s, a psychologist named Bruce Alexander ran an experiment. He put rats in cages with two water bottles: plain water and water laced with drugs. Isolated rats drank the drugged water obsessively, often until they died. But when Alexander built an environment with tunnels and toys and other rats, they mostly ignored the drugs.

The addiction wasn't about the drugs. It was about the cage.

Portugal took this seriously. In 2000, nearly one percent of their population was addicted to heroin. They decriminalized all drugs, but that wasn't the important part. They redirected enforcement money into reconnection: housing, jobs, a place in society. Fifteen years later, addiction rates had fallen dramatically. Johann Hari, who documented the experiment, put it simply: "The opposite of addiction is not sobriety. The opposite of addiction is connection."

This is the same thing Jahoda found in Marienthal. Human beings need to belong, to matter, to contribute, to have a reason to get up in the morning. Money can't buy those things. It can only buy the conditions that sometimes make them possible.

The Precedent

Here is where the story could go dark. But history offers another possibility.

The Greek word for leisure was schole. It's the root of our word "school." For Aristotle, leisure wasn't idleness. It was the point of everything else. "We work in order to be at leisure," he wrote. Work was the interruption. Leisure was the default state.

In Renaissance Florence, economic prosperity created a class that deliberately financed art, scholarship, and public beauty. The Medici patronage system meant Leonardo and Michelangelo could spend years on a single work without worrying about subsistence. The era's creativity was not born from a sixteen-hour workday. It was midwifed by leisure, dialogue, and the conscious decision to devote resources to culture.

In 17th-century London, coffeehouses became "penny universities." For the price of a cup of coffee, anyone could enter and join the intellectual discussions of the day. Merchants sat with scholars. Writers argued with politicians. The Royal Society held meetings in coffeehouses. By 1739, there were over 550 of them.

What did these golden ages have that Marienthal didn't? Not surplus. Marienthal had surplus too, in the form of time. The difference was structure. Florence had patronage, academies, guilds. London had coffeehouses. These institutions delivered everything Jahoda would later identify: time structure, social contact, collective purpose, status, activity. They provided the latent functions of work without traditional employment.

The Fork

If you're reading this and feeling unsettled, that's appropriate. We don't yet have the language for what's coming. We can't picture a world where human labor is optional, because no such world has ever existed. That's uncomfortable. It should be.

But we've reinvented ourselves before. Humanity's greatest ability is cooperation through shared fictions. Nations, religions, money: all are stories that coordinate behavior at scale. When we collectively decide to change the story, we can change the world in a generation.

We don't yet have a shared story about what comes after work. That's why this moment feels so disorienting. But disorientation is not destiny.

Down one path is Marienthal: drift, apathy, despair. People with money but no meaning, slowly dissolving.

Down the other is Florence: a flourishing that most humans throughout history could never have imagined. A world where AI handles the drudgery and humans are freed for creation, connection, and contribution. But it requires building new structures that deliver purpose, not just income.

The ladder is gone. The question is what we build in its place.