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.