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.

A 10,000-Person Case Study in Digital Transformation

Something remarkable is happening in the consulting industry right now. A major global firm recently announced $4.1 billion in AI-related bookings, with generative AI revenue rising from approximately $100 million to $900 million in just one year. That same quarter? They reduced their workforce by over 10,000 positions. Their largest organizational restructuring to date. Stock value declined 35%, erasing $86 billion in market capitalization.

This isn't isolated. It's a pattern emerging across industries. And if you're celebrating AI revenue growth, this analysis deserves your attention.

The Data Reveals an Uncomfortable Truth

Let's examine what's happening across sectors:

Professional Services:

* Leading firms reporting 9x growth in AI revenue (from $100 million to $900 million annually) while conducting historic workforce reductions

* Job postings for non-senior consulting roles down 44% in key markets (February 2022-2025)

* Major consultancies facing client demands for price concessions as AI reduces billable hours

* Federal contract pauses and spending cuts triggering additional restructuring

Enterprise Software:

* Major SaaS providers experiencing 20-28% stock declines despite AI feature launches (as of August 2025)

* Combined market capitalization losses exceeding $160-188 billion across leading platforms

* One prominent platform saw a 27-30% single-day decline on AI disruption concerns

* Traditional licensing models facing unprecedented pressure from AI alternatives

The Key Insight: Organizations are generating substantial AI revenue while their traditional business foundations shift. It's reminiscent of historical technology transitions where early leaders often struggled most.

Understanding the Innovation Challenge

This situation mirrors Clayton Christensen's research on innovation. In his studies, he found that successful organizations often struggle with transformative technologies precisely because they excel at their current models.

The pattern is consistent: Organizations invest heavily in new technology. They grow revenue in emerging areas. They serve existing customers well.

Yet structural challenges remain.

Why? Transitioning business models proves more difficult than adopting new technology.

Three Structural Challenges

1\. The Service Delivery Evolution

Professional services traditionally bill based on time and resources. AI fundamentally changes this equation.

As one industry observer noted: "When time-based work disappears, revenue models must evolve."

Consider the numbers. Major firms are booking billions in AI revenue while simultaneously restructuring their workforce at unprecedented scales. This isn't contradiction. It's transformation.

2\. The Subscription Model Question

Software companies built their success on per-user pricing. But what happens when automation reduces user counts?

The challenge is mathematical. If AI reduces the need for multiple licenses, how do subscription models adapt? The entire framework assumes human users. Automation changes that assumption.

3\. The Speed of Change

Technology adoption typically follows predictable curves. AI is different.

The pace is unprecedented:

* Major platforms seeing massive valuation shifts

* Consulting firms restructuring faster than ever

* Software companies reimagining their products in months, not years

Current Market Dynamics

Who's Adapting Successfully:

* Platform providers with usage-based models ($123B AWS, $75B+ Azure, $50B+ Google Cloud run rates)

* Companies achieving $13 billion annualized AI revenue through platform strategies

* Organizations with outcome-based pricing maintaining 57% free cash flow margins

* Infrastructure providers benefiting from 200%+ valuation increases over two years

Who's Facing Challenges:

* Organizations dependent on time-based billing (seeing 40%+ decline in hiring)

* Companies with rigid per-seat pricing (20-28% stock declines despite AI investments)

* Service providers whose value proposition centers on manual processes

* Research firms cutting revenue guidance as clients shift to AI self-service

The Real Lesson About AI Revenue

Here's what the data suggests: AI revenue growth doesn't automatically equal business health.

Consider this scenario: A firm grows from minimal AI revenue to $4.1 billion in two years. Impressive growth by any measure. But if their core business model becomes obsolete, that growth represents transition, not expansion.

It's like excelling at one technology while the market shifts to another. Historical precedents abound.

Three Sustainable Models Emerging

1\. Consumption-Based Pricing Cloud providers demonstrate this model's effectiveness with remarkable run rates: $123 billion, $75 billion, and $50 billion+ respectively. Customers pay for compute, storage, and data transfer. More AI adoption means more revenue. The model scales with technology adoption, not against it.

2\. Value-Based Agreements Some firms now tie compensation to outcomes, achieving 57% adjusted free cash flow margins while surpassing $1 billion quarterly revenue milestones. Revenue grows when clients succeed. This alignment creates sustainable partnerships.

3\. Platform Economics Usage-based data platforms are seeing surge in demand as AI boom drives consumption. These platforms monetize through compute and storage usage, with marketplace capabilities enabling additional revenue streams. They profit from activity volume, not fixed fees.

Strategic Considerations for Leaders

For executives navigating this transition:

□ Evaluate whether your revenue model remains viable with increased automation □ Assess if current growth represents genuine expansion or model transition □ Consider how pricing structures adapt to AI-driven efficiency □ Examine whether your value proposition survives automation □ Plan for workforce evolution, not just technology adoption

The Path Forward

Recent analyses of AI implementation show that while individual employees successfully adopt AI tools at high rates, enterprise initiatives face significant challenges. Success depends heavily on approach rather than technology, with purchased AI tools succeeding approximately 67% of the time versus 33% for internal builds.

The issue isn't AI capability. It's organizational adaptation paired with business model evolution.

Consider the consulting industry paradox: A firm growing from $100 million to $900 million in AI revenue in one year, alongside historic workforce reductions exceeding 10,000 positions. This isn't failure or success. It's transformation under intense pressure.

The mathematics are compelling yet concerning. When AI reduces time requirements by 10x, how do time-based business models survive? When automation eliminates user seats, what happens to per-seat pricing?

The question facing every organization: Are you building for the emerging landscape or optimizing the current one?

Conclusion

We're witnessing unprecedented business model transformation across industries. Organizations generating the most AI revenue often face the greatest structural challenges. The data is striking: 9x AI revenue growth paired with 35% value decline and $86 billion in lost market capitalization at just one firm.

A company achieving exponential AI revenue growth while reducing workforce by 10,000+ in one quarter isn't celebrating. They're adapting to survive. The question isn't whether AI transforms your industry. It's whether you transform with it.

Because when record AI revenue coincides with record restructuring and significant value destruction, the message is clear: Traditional business models are approaching obsolescence.

The organizations that thrive won't be those generating the most AI revenue through legacy models. They'll be those who rebuild for usage-based, outcome-driven economics in the world AI creates.

Platform players with consumption models are already winning. Application layer companies with seat-based pricing are struggling. The pattern is clear, the transition accelerating.

Where does your organization stand?

What's your perspective? Are we witnessing the greatest business transformation in history, or will traditional models adapt? Share your thoughts below.

#AI #Innovation #BusinessTransformation #FutureOfWork #DigitalTransformation #Strategy

Published on ---

I’ve spent most of my career on transformation—strategy, operating models, change management and integrated programs. I’m also a computer scientist. The more I work with agentic AI, the more obvious the intersection becomes: an operating model is a machine‑readable spec for how a company should work. If we express that spec cleanly, agents can build from it, run against it, and improve it continuously.

TL;DR

Treat your operating model as code. Compile it into a graph of agents that plan, act, and coordinate with guardrails. Start with a Super‑Agent (the “Chief Orchestrator”) that reads the model, provisions specialist agents, routes work, and enforces policy. Instrument everything so you can learn with reflection and reinforcement learning using verifiable rewards tied to process and outcomes. This turns the operating model from a slide deck into a living operating system.

1) From blueprint to executable spec

Most leaders agree: strategy doesn’t deliver itself—the operating model is the bridge to execution. In management language, it’s how roles, processes, governance, tech, and data combine to deliver outcomes. In engineering language, it’s a spec we can compile. Recent guidance from major firms frames operating models exactly this way: explicit choices about structure, governance, processes, talent, and technology that translate strategy into results.

Key shift: write the operating model in a formal schema (think: capabilities, value streams, processes, RACI, SLAs, policies, data contracts, controls). That schema becomes the single source of truth for agents to read, reason over, and act on.

2) What “agentic” really means in a company

Agentic systems don’t just answer questions; they plan, call tools, take actions, coordinate with other agents and humans, and verify results. Frameworks like AutoGen and LangGraph already provide patterns for multi‑agent orchestration, tool use, long‑running state, and supervision. Use them to express your firm as workflows + policies + tools + data contracts—not as a pile of dashboards.

Agent roles you’ll reuse again and again:

Planner: decomposes goals into steps with dependencies and deadlines.

Executor: calls systems (APIs, RPA, scripts), writes records, files tickets.

Reviewer: checks outputs against policy, SLAs, and controls.

Liaison: handles human‑in‑the‑loop cases and escalations.

Observer: logs traces and metrics to the evaluation store.

Lilian Weng’s canonical overview is a good mental model: planning, memory, tool use, and feedback loops are first‑class components—not afterthoughts.

3) The Super‑Agent pattern (your “Chief Orchestrator”)

Think of a top‑level agent that reads the operating‑model spec, compiles it into an agent graph, provisions the right specialists, and enforces policy:

Inputs

Operating‑model schema (capabilities, processes, RACI, policies, KPIs, risk controls)

System catalog (APIs, tools, permissions)

Data products & contracts

Guardrails (allow/deny lists, rate limits, segregation of duties)

Behaviors

Generate the agent graph (who does what, with which tools, under which controls).

Provision skills (deploy skill packs per process/capability; bind tools).

Route work (queueing, priority, load).

Enforce policy as code at decision points (see below).

Evaluate & adapt (close the loop with reflection + RL).

Outputs

Completed tasks w/ audit trails

Policy and conformance logs

Metrics for reward signals

Why this matters: you don’t need a brittle, monolithic “AI COO.” You need a compiler + scheduler that makes your operating model executable and evolvable. Tools like AutoGen and LangGraph show how to orchestrate and supervise multi‑agent systems today.

\---

4) Policies and controls: encode them, don’t slide‑deck them

Compliance, approvals, SoD, rate limits, PII handling—these must be executable. Use policy‑as‑code (e.g., Open Policy Agent/Rego) so agents can query “may I do X on Y given Z context?” at runtime. OPA is widely used for unified, low‑latency policy enforcement across stacks; it’s a proven pattern to lift into agentic work.

\---

5) Make the company observable: DTO + process mining

A Digital Twin of the Organization (DTO)—a dynamic model tied to operational data—gives agents a live map: who’s doing what, where bottlenecks are, and the state of key flows. Combine DTO with process mining to discover actual flows from event logs and check conformance to your model. You get verifiable traces that support learning, audits, and root‑cause analysis.

\---

6) Learning loops: reflection + RL with verifiable rewards

This is where it gets powerful—and safe.

Reflection: Agents critique their own trajectories and update their next attempt using verbal feedback (e.g., Reflexion) or structured checklists. This improves decisions without retraining weights.

Process supervision: Don’t just reward the final outcome; reward each correct step. OpenAI and DeepMind show process‑based feedback can reduce reasoning errors and produce more reliable chains of action.

AI‑assisted evaluation (RLAIF / LLM‑as‑Judge): Where expert human labels are scarce, use vetted models to supply scalable preference or rubric scores—with safeguards and spot‑checks.

Verifiable rewards: Tie rewards to tamper‑evident signals:

Process rewards from signed event logs (e.g., “all required fields populated,” “policy check passed”).

Outcome rewards from systems of record (e.g., paid invoice, first‑contact resolution).

Quality rewards from human or AI judges with sampling and adversarial tests.

Design this carefully to avoid specification gaming/reward tampering—measure the real thing, not just the easy proxy—and keep humans in the loop for sensitive actions. Recent work shows why this matters.

\---

7) What this looks like in practice (a 90‑day build)

Weeks 1–2 — Model it

Express one end‑to‑end workflow in your schema (e.g., customer issue to fully resolved case).

Map tools/APIs and write the policies (OPA) the flow requires.

Weeks 3–6 — Make it executable

Instantiate the Super‑Agent and 3–5 specialists (Planner, Executor, Reviewer, Liaison).

Wire to systems via APIs; stand up the evaluation store and event logging.

Run in a sandbox with reflection and process‑based checks.

Weeks 7–10 — Operate with guardrails

Move to a limited production cohort with human‑in‑the‑loop at defined checkpoints.

Track % straight‑through, time to resolution, defect rate, escalation rate, policy violations.

Weeks 11–13 — Learn and scale

Convert your metrics into verifiable rewards; run safe RL to improve routing/steps.

Package the working pattern as a reusable skill‑pack + tests; roll to the next workflow.

\---

8) Where to start (and what to avoid)

Start here: pick a high‑volume process with clear rules and measurable outcomes (support resolution, claims adjudication, collections, onboarding). Make policy and data contracts explicit. Keep the first graph small, but fully end‑to‑end.

Avoid:

“Co‑pilot theatre” (assistants with no authority to act).

Opaque scoring (no auditable link from reward → action).

Fragmented identity/permissions (agents need first‑class IDs).

One‑off bespoke agents (template everything you can repeat).

\---

9) What changes when you do this

The operating model stops being a PowerPoint and becomes a runtime.

New capabilities deploy as policy + skill‑pack + test suite, not multi‑month programs.

Risk and compliance become real‑time, not after‑the‑fact.

Improvement is continuous: you measure, reflect, and learn directly from execution traces.

This isn’t wishful thinking; the building blocks exist: multi‑agent orchestration, policy‑as‑code, DTO/process mining, and process‑based evaluation are mature enough to start now.

\---

A question to close

If your operating model is the spec, what’s the first workflow you’d be confident compiling into agents next quarter—and what reward signals would prove it’s truly better?

\---

Further reading (selected)

Operating models: McKinsey—A new operating model for a new world (2025); Bain—Design principles for a robust operating model.

Agentic AI: Lilian Weng—LLM‑Powered Autonomous Agents; Microsoft AutoGen; LangGraph multi‑agent workflows.

Policy‑as‑code: Open Policy Agent—docs & CNCF overview.

DTO & process mining: Gartner—Digital Twin of an Organization (category overview); van der Aalst—Process Mining.

Reflection & process supervision: Reflexion (Shinn et al., 2023); OpenAI—Improving mathematical reasoning with process supervision; DeepMind—process vs outcome feedback.

RLAIF / LLM‑as‑Judge: RLAIF (Lee et al., ICLR 2024); Survey on LLM‑as‑a‑Judge (2024).

Reward tampering/spec gaming: DeepMind—Specification gaming; Anthropic—Reward tampering study.

1\. The Camry‑Lamborghini Lesson

Picture dropping a Lamborghini V‑10 into a reliable Toyota Camry and expecting an instant super‑car. The engine roars… then the transmission slips, the chassis rattles, and the brakes panic. The upgrade is brilliant—but the supporting systems were never re‑engineered to handle the new power.

Over the last decade I’ve witnessed the Shared‑Service Center (SSC) equivalent of that engine swap across multiple organizations and industries. Teams centralize IT, facilities, HR, or finance, bolt on shiny tools, and declare victory. Yet the “retained” business units—the Camry frame—rarely redesign their own processes, interfaces, or governance to harness the new horsepower. Service tickets bounce, escalations pile up, and the promised agility never materializes.

2\. Two Sides of the Fence Must Mature Together

Inside the SSC we need catalogue clarity, charge‑back logic, clean data, automation pipelines, and a culture of continuous improvement.

Outside the SSC, every business unit must evolve too:

* Decision rights —crystal‑clear on what’s delegated and what isn’t.

* Standard intake channels —no more back‑door emails or hallway asks.

* Data at source —fields completed accurately so automation can run end‑to‑end.

* Service‑level thinking —requests planned ahead, not dropped in “urgent” at 4 p.m. Friday.

When only the “engine room” changes, the car still drags.

3\. Why Traditional SSCs Plateau

* Savings stall early. Labour arbitrage and lean clean‑ups top out near 30‑40 % OPEX.

* Maturity gap. Running an SSC “like a business within the business” demands design discipline that’s rarer than many assume.

* Rising expectations. Customers and internal partners now want real‑time answers, personalisation, and instant compliance—needs that rule‑based workflows struggle to meet.

Deloitte’s 2024 Global Shared‑Services survey echoes this: more than half of SSC leads admit their organizations “still operate mainly at a transactional level”—exactly the Camry‑with‑a‑Lambo‑engine problem.

4\. A Better Upgrade: The AI‑Native Operating Fabric

McKinsey’s latest State of AI report shows 70 % of companies already pilot generative‑AI in at least one function. Analysts expect SSCs to morph into AI orchestrators within two years. An AI‑native fabric changes the game:

* Distributed intelligence, not a single factory. AI agents live where data lives and coordinate via an enterprise LLM “control plane.”

* Policy generates process on demand. Agents interpret rules and context, assembling the workflow as needed—no rigid SOP required.

* Compounding speed. Minimum‑viable agents launch in three‑to‑six months, then learn their way to bigger impact.

* Expanded upside. Studies project 50‑70 % extra OPEX reduction plus revenue and experience gains from continuous insight.

5\. Concrete Signals Across Sectors

* Finance – “InvoiceGPT” auto‑codes and posts most supplier invoices, flagging anomalies for human review.

* Customer Support – Chat agents resolve routine queries, draft tailored responses, and update back‑end systems.

* Operations – Sensor data feeds models that schedule maintenance and adjust service levels via smart contracts.

Notice the common thread: the process is generated from policy, data, and context—no manual bolt‑on required.

6\. A Four‑Step Roadmap—With Upgrades on Both Sides

Phase 1: Scout & Sandbox (Months 0‑6) Launch an agentic MVP on a single pain point—invoice matching, password resets, benefit FAQs. • SSC task: Build a secure data pipe; run a privacy‑impact check. • Retained‑org shift: Route all requests through one intake portal and shut down informal channels.

Phase 2: Lay the Fabric Foundation (Months 3‑9) Deploy an LLM control plane that routes prompts, enforces security tiers, and logs reasoning. • SSC task: Stand up an API gateway and specialized “memory store” (vector database). • Retained‑org shift: Agree common data definitions and ownership; clean source data.

Phase 3: Expand Into Domain Pods (Months 6‑18) Spin up FinanceGPT, OpsGPT, HRGPT clusters; integrate with existing RPA bots. • SSC task: Aim for ≥50 % touchless throughput; re-skill staff into model curators and policy designers. • Retained‑org shift: Re‑map decision rights; embed service‑level planning into annual cycles.

Phase 4: Evolve to a Self‑Optimizing Enterprise (Beyond Month 18) Agents watch KPIs, propose rule tweaks, and A/B‑test improvements in sandboxes. • SSC task: Reinforcement learning, bias testing, continuous assurance. • Retained‑org shift: Replace manual sign‑offs with explainable AI audits; focus human effort on innovation and exception handling.

7\. Leadership Imperatives

1. Lock data contracts early. Otherwise every agent invents its own language.

2. Cultivate explainability. Audit algorithmic reasoning, not a human signature.

3. Celebrate the human upside. AI frees people from repetitive chores, unleashing judgement, creativity, and client connection.

4. Plan for regulation. Provenance, transparency, and locality requirements are coming—bake them in now.

8\. The Road Ahead

SSCs thrived when moving people to the work was cheaper than moving intelligence to the data. Generative and autonomy‑grade AI flip that logic. With matching maturity on both sides of the fence, organizations can bypass a decade of SSC headaches and accelerate into an AI‑native fabric—redeploying their best talent where it truly moves the needle.

Remember our Camry‑Lambo swap: upgrading the engine is thrilling, but without re‑engineering the chassis and controls, you’re still stuck in the slow lane.

Ready to leap?

Drafted by Saleh Hamed with editorial support from generative‑AI tools.

Saleh Hamed Enterprise & AI Transformation | Operator at Scale February 28, 2026 And You Built Your Entire Organization Around It.

A NOTE FOR SENIOR LEADERS • MARCH 2026 I am going to say something that might offend you.

It is not your strategy that is failing. It is not your team. It is not the technology. It is you. Or more precisely, it is the model of intelligence you have built your entire organization around. The model that says: collect the data, clean it, process it, surface it to a human being, and then, finally, let the intelligence happen.

You made yourself the destination. And in doing so, you became the constraint.

The Dashboard Is a Monument to the Wrong Idea Somewhere in your organization right now, a team is six months into building an AI-powered dashboard. The demo looks incredible. The data is beautiful. Leadership is going to love it.

It will fail.

Not because the technology does not work. Because the premise is wrong. The premise is that better information in front of a human being produces better decisions. But faster humans are just optimization. You are polishing a model that is already broken. Dashboards are necessary. But they are not the lever. They stop at awareness. They make the bottleneck more informed. The bottleneck is still you.

You cannot fix a throughput problem by giving the bottleneck a better view.

Somewhere in your portfolio right now is a multi-million dollar project that exists to do exactly that. And you approved it.

This Is a Physics Problem Think about the last major decision your organization made. A real one. Not a small approval but an actual strategic call.

Someone gathered the data. Someone cleaned it and made sense of it. Someone packaged it into a format that could survive a boardroom. Then you needed the right people in the room, which meant scheduling across calendars, pre-reads that nobody fully read, a meeting where half the time went to aligning on what the data actually meant, then follow-up, then another meeting.

By the time the decision was made, how old was the data? A week? Two weeks? And how long until implementation actually started?

You were not slow because your people are not smart. You were slow because human intelligence has hard physical limits. One brain, one focus, one timezone, eight useful hours on a good day. And to get two brains aligned, you do not add them together. You multiply the coordination cost.

While you are sleeping, the signal is decaying. While you are in the alignment meeting, the market has already moved. In the UAE, where a government initiative can go from announcement to execution in months and a competitor can pivot overnight, that gap is not an inconvenience. It is a forfeit.

By the time your decision travels from data to dashboard to boardroom to implementation, you are executing on a snapshot of a world that no longer exists. The Expensive Funeral Picture the two smartest people in your organization.

Now picture getting them synchronized on a single decision. Calendar invite. Pre-read nobody finished. Meeting that started late. Forty minutes aligning on what the numbers mean. Action items. Follow-up. Another meeting.

You have two of the most expensive, highly-tuned biological computers on the planet. And you are using them to argue about data from last week.

That is not a meeting. That is an expensive funeral for a dead data point.

Neither of those people is the problem. The system is the problem. The system that treats human intelligence as the only kind available.

It is not the only kind anymore.

You Already Knew This. That Is What Is Embarrassing.

Henry Ford wrote in 1922: "Many people are busy trying to find better ways of doing things that should not have to be done at all." He was writing about building cars. Deloitte cited that line in their 2025 agentic AI strategy paper because it describes enterprise AI perfectly. Most organizations are automating processes that should not exist. They are finding better ways to bring data to humans instead of asking the more uncomfortable question: does this decision need a human at all?

The embarrassing part is that business schools have been trying to tell us the answer for decades.

Management by Exception was never about approving less. It was about designing systems that run on their own and only pull you in when something genuinely falls outside the norm. We understood the theory. We kept approving everything anyway. Drucker spent a career arguing that decisions should be made at the lowest level capable of making them well. We centralized anyway. Not because we did not understand. Because we did not trust the periphery. We never gave the periphery the capability to be right.

Gerber warned us in The E-Myth: stop being the technician. Design the system that does the work. Walk into most organizations today and the senior leader is still the technician. Just with a larger budget and a better dashboard.

These frameworks did not fail because they were wrong. They failed because the infrastructure to run them did not exist. You could not trust the periphery because the periphery was not capable enough.

That has changed.

Satya Nadella said it plainly: business applications are just databases with business logic hardcoded into them. That logic is now moving to the agent layer.

The agent orchestrates across systems. It acts within defined rules. It escalates what falls outside them. You designed that system. You are not the one running it.

What that looks like in practice is not complicated:

The system detects the signal. It acts within defined guardrails. It escalates the exceptions that genuinely need judgment. It learns from outcomes and adjusts its own thresholds.

That is management by exception. That is subsidiarity. That is what every framework you already know has been pointing at. AI is the first infrastructure capable of actually running it.

You do not need a new book. You need to actually do what the books you already own told you to do.

Which Dot Are You?

A widely shared February 2026 visualization maps global AI adoption across 2,500 dots, each representing roughly 3.24 million people. The numbers are estimates and the definitions matter. But the shape of the curve is the point. (earliest post I could find was by Noah Epstein here https://x.com/NoahEpstein_/status/2025605338779496797) Around 84% of the world has not meaningfully used AI, defined here as a standalone chatbot or coding tool. Around 16% are free users. They have made themselves slightly faster humans. Around 0.3% are paying subscribers. They have better tools, and they are still consumers.

Roughly 0.04% are builders: power users deploying agentic AI to actually rewire how their organizations operate. Not making themselves smarter. Making intelligence ambient.

McKinsey put a harder number on this in their 2025 State of AI survey. Six percent of organizations are genuine high performers. What separates them from the other 94% is not the technology they use. It is whether they treat AI as a catalyst to redesign how the organization works, or as a tool to make existing work slightly faster.

The 94% are optimizing. The 6% are rebuilding.

Most senior leaders reading this will assume they are in the advanced group. They have an AI subscription. Their team uses Copilot. They approved an AI strategy last quarter. If you are approving dashboard projects, you are in the 94%. You are a faster human. That is not nothing. But it is not the transformation available to you.

The gap is not a technology gap. It is a mental model gap.

What You Actually Need to Do Stop asking: how do I get better information to make better decisions?

Start asking: where in my organization do decisions happen that do not need to wait for me?

That question is uncomfortable. It challenges the belief that your judgment is what makes the organization run. It does, for the decisions that genuinely need a human who understands context, consequence, and culture. Those are real and they need you. But the decisions queued up waiting for your calendar to open? The signals sitting in a system until someone packages them into a slide? The patterns your data already contains that nobody is acting on?

Those are costing you more than you know. Not just in money. In time, in market position, in the gap between what your organization could know right now and what it is actually doing with that knowledge.

This week: list the last 20 decisions your organization made. Mark which ones genuinely required senior judgment. Everything else is a candidate for bounded autonomy.

Systems that act within defined guardrails, escalate the exceptions, and learn from outcomes. Your job is to design the escalation policy. Not to be the policy.

Your job as a leader is not to be the brain. It is to build the nervous system.

Stop bringing data to your intelligence.

You are not the destination. You are the exception. The last resort for decisions that genuinely need a human soul.

Everything else? Send the intelligence in.

Further Reading: The Books You Already Own You do not need new frameworks. You need to implement the ones sitting on your shelf. Peter Drucker, The Effective Executive (1967) -- Decisions at the right level. Still the most practical leadership book written. Every chapter argues against routing everything through the top.

W. Edwards Deming, Out of the Crisis (1982) -- Improve the system, not the people. Your outputs are a function of your process design, not your talent density.

Peter Senge, The Fifth Discipline (1990) -- The organization that sees itself as a system, not a collection of individual decision-makers, is the one that survives disruption. Michael Gerber, The E-Myth Revisited (1995) -- Stop being the technician. The failure mode Gerber described in 1995 is the most common failure mode in enterprise AI today.

Management by Exception -- Not a book. A principle most organizations claim to follow and almost none actually do. AI makes it executable for the first time.

Sources: Henry Ford quote documented by The Henry Ford (Ford News, 1922). Deloitte agentic AI strategy paper, Tech Trends 2026 (December 2025). McKinsey Global Survey on the State of AI (November 2025, 1,993 respondents across 105 countries). Satya Nadella on AI agents and SaaS, B2G podcast (2024). AI adoption dot visualization, widely shared February 2026; methodology estimates standalone chatbot or coding tool usage.

Saleh Hamed is an AI strategist and entrepreneur based in Abu Dhabi, with 25 years of enterprise experience in the UAE. He works at the intersection of organizational design and agentic AI.

Tenants Do.

There is an iron law at work in every platform economy, and almost nobody talks about it clearly.

I want to name it.

Call it the Tenant Rule: for any platform to survive, the people building on top of it must collectively generate more economic value than the platform captures.

By "value" here, I mean gross throughput — GMV, billings, sales — not platform profit. This is not a theory. It is pure logic.

The landlord would not maintain the building if the sum of rents didn't cover the cost of the capital deployed to build it. And the tenants would not stay if they weren't generating more from the space than what they pay to occupy it.

Both sides must be true simultaneously.

Which means the builders — in aggregate — must always be generating more gross value than the platform captures. Always.

When you look at the numbers, the pattern is hard to ignore.

In 2025, Alphabet reported that YouTube revenue across ads and subscriptions exceeded $60 billion. Netflix reported $45.183 billion in total revenue for the same year. YouTube crossed Netflix. Quietly.

Independent market research estimates the global creator economy — across platforms and revenue streams — at roughly $250 billion in 2025. The total creator ecosystem is multiple times larger than any single platform's revenue line. The key point isn't that YouTube "caused" all of that value, but that once a platform becomes infrastructure, its own revenue is usually just a slice of a much larger downstream economy.

And YouTube's own economic impact report, produced with Oxford Economics, found that its creator ecosystem contributed over $55 billion to U.S. GDP in 2024 — supporting more than 490,000 full-time equivalent jobs in editing, production, brand partnerships, analytics, and merchandise that didn't exist as industries when the platform launched. The platform built the rails. The builders built the economy around the rails.

It's not just YouTube:

→ Apple App Store: In 2024, Apple-supported research estimates the App Store ecosystem facilitated approximately $1.3 trillion in billings and sales. Apple collected no commission on more than 90% of that total. The builders' economy is vastly larger than the platform's revenue line.

→ Shopify: In 2025, Shopify merchants processed $378.4 billion in GMV while Shopify booked $11.556 billion in revenue. The merchants' economy is approximately 33× the platform's own revenue.

→ Amazon Marketplace: Amazon doesn't publish marketplace GMV directly. What it does disclose is that in 2025 it reported $172.162 billion in third-party seller services and $68.635 billion in advertising services — both tied directly to seller ecosystem activity. The seller ecosystem generating those fees is, by definition, substantially larger than the fees themselves.

→ Substack: Writers have earned roughly an order of magnitude more in aggregate payouts than Substack has kept in fees. A single newsletter platform created dozens of million-dollar-a-year individual media businesses.

Across every major platform ecosystem with public data, the pattern is consistent: the builders' aggregate economy is substantially larger than the platform's own revenue. The Tenant Rule holds.

We've watched this movie twice. We missed it both times.

In 2005, YouTube launched.

Most of us thought it was a place to watch funny videos. We watched our friends start uploading content and thought it was a phase — something silly people did. We had no framework for understanding that the site was not a product.

It was infrastructure.

By the time we understood, MrBeast had built a media conglomerate valued at $5 billion. Kids' channels had been acquired for $3 billion. And around all of them, that 490,000-job ecosystem had quietly materialized — editors, agencies, merchandise operations, analytics tools, talent managers — entire industries built on top of a platform we'd dismissed as a video website.

Then the iPhone arrived in 2007. Same story.

We debated whether apps would replace websites. We asked whether mobile would hurt PC sales. Almost nobody predicted ride-sharing as a default transport layer, food delivery as a global industry, or mobile-first banking as a viable business model. The conversations were about the technology. The wealth was being created in the ecosystem.

We are at that moment again.

Except this time, we have the benefit of having seen it happen twice.

AI is not a chatbot. It's infrastructure.

The most important mental reframe available right now:

AI is not a product you use. It is infrastructure on which an entirely new economy will be built.

The conversations we're currently having about AI sound exactly like 2005 and 2007: ❌ "Will it replace copywriters?" ❌ "Will it automate analysts?" ❌ "Is it accurate enough to trust?" Those are the wrong questions — not because they're unimportant, but because they're the questions people ask when they're staring at the technology instead of the ecosystem it will generate.

The right questions are:

✅ What new job archetypes will exist that we don't have language for yet? ✅ What businesses become viable for the first time when a solo founder can operate what looks like a 20-person firm? ✅ What markets open when anyone can orchestrate AI agents as easily as a creator today uploads a video?

Every platform goes through three phases Phase 1 — The App Phase We debate features, benchmarks, accuracy. We compare it to what came before. We ask if it's "good enough." (YouTube: 2005–2008. AI: right now.) Phase 2 — The Infrastructure Phase We realize it's a platform, not a product. New categories of work become possible and cheap. Early movers build foundational positions. (YouTube: 2009–2014) Phase 3 — The Ecosystem Phase The real value shows up around the platform: new careers, companies, and communities that were impossible before. The tenant economy dwarfs the landlord. (YouTube: 2015–now) YouTube is in Phase 3. The smartphone ecosystem is deep in Phase 3. AI is barely out of Phase 1.

That gap — between where we are in the conversation and where the real value will eventually sit — is the opportunity.

Why did we miss it last time?

This is the question worth sitting with.

We had the internet. We had smartphones. We had YouTube. We watched creators build empires in real time. We had every piece of information we needed.

And most of us still stood on the sidewalk.

It was not ignorance. The tools were accessible. The economics were demonstrably in the builders' favour.

Most people who missed the YouTube wave were not uninformed.

They were embarrassed.

Making videos felt silly. Starting a channel felt narcissistic. Building a personal brand felt like something other people did. That psychological barrier — the friction of feeling foolish — is the real reason most people didn't participate in the last platform economy. And that same barrier is active right now with AI.

Building with AI feels technical. Automating your work feels premature. Starting something feels like getting ahead of yourself.

It's the same costume on the same instinct.

The embarrassment is the signal, not the warning.

What the AI ecosystem will generate that doesn't exist yet Based on the pattern from YouTube and the app economy:

New job archetypes with no names yet. "YouTuber" would have sounded absurd in 2004. "Influencer" would have sounded like parody. In five years, roles like agent orchestrator, AI workflow designer, and synthetic studio lead will be normal professional titles — and people who moved early will be the senior practitioners commanding the highest rates, exactly as the first serious YouTubers became the highest-paid talent on the platform. The one-person company that looks like a firm. A complete AI operating stack in 2026 costs between $3,000 and $12,000 per year — a 95–98% reduction in operating costs compared to building a human team to do equivalent work. In many domains, a solo founder can already run what looks, from the outside, like a 20-person professional services business. This isn't theoretical. It's happening now at the margins. In five years it will be the default model for a certain class of entrepreneur.

The second-order economy. The majority of jobs created by AI won't be "AI jobs" in any obvious sense. Just as YouTube created brand deal lawyers, thumbnail designers, and channel management agencies — entire professions that sound absurd until they're everywhere — AI will create its own surrounding trades. Trust verifiers.

Human-in-the-loop editors. Agent workflow consultants. Ethics auditors for automated systems. The ecosystem economy, not the model economy, is where the volume of opportunity will sit.

The keys are on the table.

OpenAI, Anthropic, Google — they are the new Landlords. They are collectively pouring hundreds of billions of dollars per year into infrastructure. And critically: they are competing with each other for your tenancy. That competition is a structural gift to builders — it means the unit cost of intelligence, of inference, of the fundamental raw material of AI-powered businesses, has been driven sharply down and will continue to fall.

The Stanford AI Index 2025 found that the cost of running AI inference has dropped by more than 280× in recent years. The landlords are subsidizing your rent in order to win your occupancy.

The tenant economy around AI will, by the iron logic of platform economics, generate more aggregate gross value than the platforms themselves.

This is not speculation. It has been true in every major platform economy we have data on. It will be true here.

The only question is whether you will be in the ecosystem when it enters Phase 3 — or whether you will be standing on the sidewalk, remembering the moment you watched it happen to someone else.

We had this choice in 2005. We had it in 2007. Most of us chose the sidewalk — not because we lacked information, but because building felt premature, strange, or foolish. The feeling of foolishness is the entry point. It always has been.

The people who walked through it built the creator economy.

The people who walk through it now will build the AI economy.

And if history holds — and it always holds — the tenants will, once again, collectively generate more than the landlord ever could alone.

What are you building?

Sources 1.​ Alphabet FY2025 earnings release (YouTube >$60B):

https://s206.q4cdn.com/479360582/files/doc_financials/2025/q4/2025q4-alpha bet-earnings-release.pdf 2.​ Netflix FY2025 annual report:

https://www.sec.gov/Archives/edgar/data/1065280/000106528026000034/nflx- 20251231.htm 3.​ Creator economy market size (~$250B):

https://www.grandviewresearch.com/industry-analysis/creator-economy-market- report 4.​ YouTube/Oxford Economics U.S. impact report ($55B GDP / 490K jobs):

https://services.google.com/fh/files/misc/us_full_report.pdf 5.​ Apple App Store ecosystem report (~$1.3T, >90% commission-free):

https://www.apple.com/newsroom/pdfs/2024-Apple-Global-Ecosystem-Report-J une2025.pdf 6.​ Shopify FY2025 financial results:

https://s27.q4cdn.com/572064924/files/doc_financials/2025/q4/Shopify_Invest or_Press_Release_Q4-25_FINAL.pdf 7.​ Amazon FY2025 annual report (3P seller services + advertising):

https://www.sec.gov/Archives/edgar/data/1018724/000101872426000004/amz n-20251231.htm 8.​ Stanford AI Index 2025 (inference cost down 280×+):

https://hai.stanford.edu/ai-index/2025-ai-index-report #ArtificialIntelligence #CreatorEconomy #Entrepreneurship #FutureOfWork #PlatformEconomics

TL;DR: Administrative AI can run on sovereign infrastructure for pilot costs in the $15K-$145K range and dramatically cut turnaround times for routine cases. But the hard part? It's never been the models. It's building governance into the bones of the system: policy grounding, decision records, oversight triggers, transparent appeals. Get that right from day one or don't build it at all.

The smartphone analogy worked because phones are real. Tangible. You can hold one, show someone how to use it, watch them figure it out.

Administrative AI needs that same level of concreteness.

When I talk about AI compressing institutional capacity costs by orders of magnitude, the natural response is: "Show me what that actually looks like." Fair question. Here's the answer. Not a vision statement, an architecture.

What Gets Built Start with procurement. It's universal and it's politically sensitive. Every government buys things. Every government struggles with corruption, favoritism, opacity.

What does a procurement system with administrative AI actually do?

It verifies vendors against business registries, tax databases, sanction lists. Posts tenders and checks submissions for completeness and compliance. Extracts the evidence that matters: pricing tables, certifications, delivery terms. Then it generates a scoring recommendation for the objective criteria and documents its reasoning in structured form. When something looks off (outlier bids, missing disclosures, potential conflicts), it flags those for human review. And it produces a complete audit trail with clause citations and reviewer sign-offs.

Humans still award the contracts. That's non-negotiable. The AI proposes and documents. People authorize. What changes is that the process becomes legible and auditable by default.

Estonia already demonstrates end-to-end digital procurement with public transparency. The AI layer adds automated compliance checking, plain-language explanations, scalable triage. Award authority stays human.

Benefits administration works similarly.

Policy teams encode the eligibility criteria and calculation rules into a versioned ruleset. Applications get validated against authoritative data sources: tax records, employment databases, prior claims. Routine cases move quickly. Ambiguous cases and high-impact decisions route to human review. Every outcome includes a plain-language explanation citing specific policy clauses. Citizens get clear appeal pathways with full access to the decision records.

India's Direct Benefit Transfer program operates at massive scale. Cumulative transfers crossed ₹43.95+ lakh crore as of May 2025, with reported savings of ₹3.48 lakh crore (2015-March 2023) from eliminating duplicate and ineligible beneficiaries. Adding LLM-based natural language processing means the system can handle unstructured applications, answer questions in local languages, explain decisions without requiring applicants to parse policy jargon.

Business licensing follows the pattern.

A founder uploads documents. The system validates them against regulatory requirements, checks compliance, routes approvals to the right departments. Either it approves the license or it explains exactly which requirements aren't met yet.

Processing time drops from weeks to hours. Cost per application drops from tens of dollars to cents. Consistency improves: every applicant gets evaluated against the same criteria, every time.

The Sovereign Deployment Stack Why sovereignty matters: Administrative capacity is state capacity. If your benefits system depends on foreign cloud providers, you've outsourced sovereignty. Those providers exit your market? Your government stops functioning. Your data flows to foreign servers? You're subject to foreign jurisdiction, including extraterritorial laws like the U.S. CLOUD Act.

You can build this without dependency on foreign infrastructure. Your data never leaves national boundaries.

First layer: policy grounding.

Not "scan PDFs." You need a structured policy knowledge base where every policy clause has a stable, unique identifier. Amendments are version-controlled. Every decision cites the exact legal authority it relies on. Rwanda's IremboGov platform shows service digitization at scale. The next step for administrative AI is this versioned, machine-navigable policy knowledge base that makes automated decisions auditable rather than opaque.

Second layer: processing engine.

Runs on-premise using open-weight models like Llama, DeepSeek, Qwen, Mistral. You download them, modify them, deploy them under their respective licenses. No ongoing fees. A pilot-grade node can be built for a few thousand dollars for small models, especially if latency requirements are modest. Need low-latency throughput at scale? Add GPUs and redundancy.

For routine workflows (classification, validation, extraction), a single node processes thousands to tens of thousands of cases daily. Exact throughput depends on case complexity, latency requirements, GPU usage. Recent open-weight model developments weakened the "only hyperscalers can do this" argument. Small states can deploy administrative AI on infrastructure they own and control.

Third layer: accountability architecture.

This separates "institution-in-a-box" from "automation disaster." Here's what matters: the deterministic ruleset and validated data determine eligibility and calculations. Models handle intake, routing, summarization, explanation. Everything anchors to clause IDs and retrieval.

Every decision generates a complete decision record. Input data (what information was considered). Policy clause IDs (which rules applied). Calculations performed (how the decision was reached). Model outputs used, if any, with retrieval citations. Calibrated risk score based on validation checks and historical error patterns. Human review triggers defining what patterns require oversight. System versions covering model ID/version, ruleset version, retrieval snapshot, reviewer ID for reproducibility. When a citizen asks "why was my application denied?", the system shows exactly which eligibility criterion wasn't met, cites the specific policy clause, explains what would need to change. When an auditor reviews the system, they can inspect decision patterns, identify bias, verify rules are being applied consistently.

This isn't bolted on after deployment. It's built into the architecture from day one. Fourth layer: data sovereignty.

All data stays on local servers. Encryption follows national standards. Citizens can view and correct their data, with deletion and retention governed by national records law. This materially reduces exposure to foreign jurisdiction and third-party access by keeping compute and data under national control.

What Accountability by Design Prevents Australia's Robodebt is the cautionary tale everyone should study.

The system made assumptions about income averaging that violated actual law.

Removed human oversight for decisions affecting vulnerable people. Created institutional resistance to admitting error. Result: 794,000 false debt notices. Severe harm including cases where families attributed suicides to the scheme. $1.8 billion in settlements.

An accountability-by-design system would have prevented this through explicit policy grounding (the system would have cited the specific social security legislation defining income calculation, making the gap between law and assumption visible in decision logs), mandatory human review triggers (decisions deviating from standard patterns would have flagged for review, so when thousands disputed debts the system would have escalated rather than doubled down), citizen appeal pathways (every notice would have included the decision record and specific legal authority, letting citizens challenge the logic before accumulating months of false debt), and audit transparency (regulators could have inspected the decision algorithm, identified the flawed assumption, corrected it before harm scaled).

The Netherlands childcare scandal followed the same pattern: opaque algorithms, no explanations, vulnerable populations harmed, institutional resistance to correction. An accountability-by-design system surfaces problems early because transparency is structural, not optional.

The Cost Breakdown Initial pilot deployment runs $15,000-35,000 for hardware, integration, fine-tuning. Ministry-scale deployment covering multiple use cases with redundancy:

$70,000-145,000. Annual operating costs for power, maintenance, human oversight: $60,000-170,000.

Compare that to traditional systems: $500,000-$5,000,000 annually in personnel costs alone. Add 8-26 weeks training time. Days-to-weeks processing. 5-15% error rates. In many workflows, marginal processing cost falls by an order of magnitude or more. But total program cost? Still dominated by integration, data quality, security accreditation, oversight. Those costs don't disappear. They just shift.

Implementation Timeline This isn't a five-year digital transformation. A credible pilot targets one service line (license type, benefit, permit), one clear ruleset, a defined appeals workflow, published metrics covering turnaround time, error types, override rates, appeal rates.

First two months focus on policy digitization and model selection. Legal teams work with technologists to structure regulations. IT teams evaluate models and hardware. Months three and four cover fine-tuning and pilot testing with parallel human processing. Months five and six involve limited deployment where real applications flow through both paths and discrepancies trigger review and refinement. Months six through twelve: full deployment with continuous monitoring, system handles routine cases, humans focus on exceptions and appeals and oversight, metrics published monthly. Then scale to additional services based on demonstrated results.

The Real Blockers Aren't Technical The core building blocks are no longer exotic. Models, hardware, integration patterns exist. What remains hard: governance, data quality, institutional adoption.

Procurement rules written for traditional software don't map to AI systems. Vendors lobby against open-weight models because rent extraction disappears. Labor concerns about job redesign versus elimination are often valid and require honest engagement, not dismissal.

Legal frameworks are catching up. Templates exist: Canada's Algorithmic Impact Assessment (mandatory under the Directive on Automated Decision-Making), the EU AI Act's phased approach whose deadlines are now subject to proposed amendments under the Commission's "Digital Omnibus on AI." These need adaptation and adoption. Cultural trust requires transparency and demonstrated accountability. Estonia succeeded because they made government data visible to citizens and gave people control over access. That same transparency must be structural in administrative AI, not aspirational.

From Blueprint to Reality This isn't speculative infrastructure. Deployable technology. Proven precedents. Documented costs. Concrete accountability mechanisms.

The question isn't "can it be built?" Technical answer: yes. Cost answer: affordable. Real question: who builds it first, and will they build it right?

First movers set the standards. Those standards will either prioritize accountability from day one (policy grounding, decision records, human review triggers, transparent appeals, real oversight), or optimize for speed and discover the Robodebt lessons at higher velocity.

This blueprint is open. Models are open-weight. Architecture is replicable. What's needed now: political will, implementation discipline, commitment to building capacity that serves people rather than extracting rent from them.

When capability becomes cheap, it doesn't stay contained. Question is whether it spreads with safeguards built in or bolted on after damage is done.

Sovereign AI isn't a tool for making the governments of today faster. It's a tool for building the governments of tomorrow sooner.

___ Question for discussion: If you work in government, policy, or oversight: which institutional process in your context is currently the biggest "black box" where decisions lack transparency and citizens can't get clear explanations?

There's a moment in the smartphone story that people in rich countries don't fully appreciate.

In the developed world, the iPhone became standard urban equipment. A badge. A default.

But the real revolution wasn't the iPhone. It was what happened when smartphones became cheap enough to spread.

Before smartphones, access required infrastructure. Before infrastructure, access required permission. A young person in a rural village couldn't participate in modern commerce without traveling to a city, finding a bank branch, presenting the right documents, getting approval from someone behind a desk.

Then suddenly, dozens of manufacturers started producing devices that didn't carry a premium logo but did carry capability. And modern life collapsed into something anyone could hold: a camera, a library, a classroom, a bank branch, a marketplace, a navigation system.

It didn't make the world equal. But it made the modern world reachable.

That is what "cheap" does to technology. It stops being a product. It becomes substrate. And it does something else: it flattens institutional asymmetry. Banks had branches. Media had printing presses. Governments had records. Corporations had distribution. After phones, individuals had tools once monopolized by institutions.

Now imagine the same thing happening, but for institutions themselves If you care about development, you eventually run into a hard truth. A huge portion of global poverty isn't caused by a lack of intelligence, ambition, or culture. It's caused by weak institutions, not as buildings but as reliable systems that do basic things predictably: a benefit reaches the right person, a business license doesn't require six months and three bribes, a procurement tender isn't a casino, a rule gets applied the same way twice, a citizen can appeal a decision and be heard.

Development economists have been saying versions of this for years. Rodrik, Subramanian, and Trebbi showed that when you control for institutional quality, it tends to "trump" trade and geography in explaining income differences.

But here's the part that rarely lands emotionally: weak institutions don't just slow growth. They make life feel arbitrary. And arbitrariness is where dignity gets crushed. The institutional bottleneck isn't just real. It's persistent.

The traditional path to building state capability is slow, expensive, and often doesn't move. Andrews, Pritchett, and Woolcock describe a "Big Stuck" where many developing states show little capability improvement over long periods, and some go backwards. Meanwhile, the fiscal reality is brutal. In low-income countries, wage bills can consume nearly half of all government revenue. When that much money goes to paying salaries, there's nothing left for services, maintenance, or investment. The World Bank has documented this exact trap.

So the story becomes: we know what good governance looks like, but we can't afford the headcount, the training, the oversight, and the time.

This is where AI becomes a moral technology Most AI talk is trapped in a workplace frame: jobs, productivity, disruption. But if smartphones collapsed modern tools into a device, AI can collapse institutional capacity into hardware and code.

Not "institutions" as legitimacy or politics, but institutions as service capability: interpreting policy, processing cases, verifying eligibility, routing decisions, checking compliance, detecting fraud, generating audit trails, answering citizens consistently. AI is now capable of performing the core informational work of administration. And it's getting cheap at a rate that changes what's possible.

GPT-4 level performance that cost $20-30 per million tokens in 2022 now costs under $1, and the rate of decline is accelerating.

Here's what that means in structural terms: processing a government benefit application costs five to fifty dollars when a trained clerk does it. The marginal cost of processing the same application via AI is now less than a penny.

If the barrier to administrative capacity is no longer money, it becomes design. That is a development economics earthquake. Because it means the constraint isn't funding or training timelines anymore. The constraint is whether you build the system with the right accountability architecture.

And this isn't theoretical. It's already emerging.

In Malawi, a woman sits outside her home with a borrowed smartphone. She opens an app called Ulangizi, which means "advisor" in Chichewa. She asks a question about her maize crop in her own language. The response comes from a government agricultural manual, processed by AI, delivered conversationally in seconds.

She doesn't have an agronomist. She doesn't have an extension officer who visits. She has a phone and an AI system grounded in official guidance.

That isn't an isolated anecdote. Systems like Farmerline's Darli AI were used by 110,000 farmers across 27 African languages by late 2024 and recognized in TIME's Best Inventions of 2024. AI advisory capacity works in rural contexts, in local languages, for people who don't have professionals on call.

Not because she becomes superhuman. Because capability becomes portable.

Digital made government cheaper. AI compounds that advantage.

Before AI, digitization already proved the principle. The UK government found that digital transactions were around 20 to 50 times cheaper than manual processing. Estonia's X-Road platform saves the equivalent of 2% of GDP annually, approximately €760 million, while handling over 1.3 billion queries per year. India's Direct Benefit Transfer system has channeled over ₹40 lakh crore (approximately $490 billion) while saving ₹3.5 lakh crore ($42 billion) by eliminating ghost beneficiaries and reducing leakage. India's UPI payment system now processes 49% of global real-time payment transactions.

Digitization moved the form online. AI can now process that form, validate the data, route it intelligently, flag exceptions, and generate audit trails without human review. The cost reduction doesn't stop at 20x or 50x. It compounds further, potentially by orders of magnitude.

This is not automation for convenience. This is institutional capacity where there is none.

What this means, in human terms It means the less fortunate may not have to wait two generations for functioning services. It means a mother doesn't lose months to a broken process, a farmer gets guidance today instead of waiting for an extension officer who may never come, a young founder registers a business without begging, a benefit goes to the right person, a decision can be explained, a rule gets applied consistently.

And consistency is not a bureaucratic detail. It's dignity.

This can also go wrong, and we have proof Australia's Robodebt scheme generated 794,000 false debt notices and resulted in multiple suicides. The Netherlands wrongly accused 35,000 families, causing government resignations over institutional racism. Michigan's system achieved a 93% error rate.

The pattern: remove human oversight, apply automation to vulnerable populations, resist correction when errors emerge.

So the mission isn't "deploy AI everywhere." The mission is to deploy institutional AI with constraints that protect people: policy grounding (what rule was applied?), audit trails (why did it decide this?), human oversight (who is accountable?), appeal pathways (how does a citizen challenge it?), sovereign control (who owns and governs the system?). These aren't nice-to-haves. They're the difference between capacity and cruelty. The real question The smartphone didn't change the world because it was beautiful. It changed the world because it was cheap enough to spread.

AI is approaching that moment for institutional capability. And when institutional capacity becomes cheap, portable, and replicable, something fundamental shifts. Not just in developing countries, but everywhere.

In rich countries, citizens won't tolerate six-month delays if AI can process applications in six minutes. Legitimacy expectations will rise. In poor countries, governments won't be able to justify institutional inertia as easily. That's not just economic compression. That's political compression.

The question isn't whether this happens. The question is whether it happens with accountability built in from the start, or bolted on later after the damage is done. We're not just talking about productivity. We're talking about extending functional governance to places that have been locked out of it for decades. We're talking about a world where participation in modern governance becomes as reachable as participation in modern commerce became when phones got cheap.

That's not a tech story. That's a civilization story.

And it's already beginning. When capability becomes cheap, it does not stay contained.