The most ambitious part of McKinsey’s report on the AI operating system is not about technology. It is about management.
The authors argue that many of the rhythms companies run on today, the quarterly business review, the monthly performance meeting, the chain of approvals, exist largely because gathering information and aligning on decisions used to take time. Remove that constraint and the rhythms stop making sense. Leaders can manage by intervention instead of by calendar, stepping in when a signal crosses a threshold rather than when a meeting comes around. Decisions can move closer to customers and operations. Many layers of the organization become unnecessary, and the report imagines managers whose teams grow from ten or twelve people to somewhere between twenty and forty.
Then the report asks the question that decides whether any of this happens. How does a business build enough trust in the AI operating system that the organization does not drift back to rebuilding layers of approval?
That question is the right one, and most organizations will answer it badly. They will treat trust as a cultural problem, something to be solved with change management and executive sponsorship. Culture matters. But trust in a system that makes and executes decisions is mostly an engineering problem, and it has an engineering answer.
Approval layers are governance implemented in people and calendars. They can only be removed safely when the same functions, checking decisions against rules, catching exceptions, recording who did what, and escalating what matters, are built into the operating system itself. You cannot delayer what you cannot govern.
The premise worth questioning
The premise in most conversations about AI and organization design is that better information makes hierarchy unnecessary. Give everyone the same live view of the business, and the layers that existed to move information up and down will fade away on their own.
Before arguing with it, it is worth looking at why those layers exist, because the people who built them were solving real problems.
The case for the layers
Approval layers do more than move information. They create accountability. When a pricing change or a coverage decision goes wrong, someone signed off on it, and that person can explain why. Regulators, auditors, and boards depend on that chain.
Layers also catch things. An experienced manager reviewing a decision notices the customer relationship that a model would miss, the regulatory nuance that is not in any written rule, the operational constraint that only shows up on the floor. Much of the judgment McKinsey wants executives to spend more time on currently lives in those reviews.
Layers develop people. Middle managers learn by reviewing and approving work, and future executives learn by being middle managers. Remove the layers and you remove part of the path that produces leaders.
And delayering has a history. The reengineering wave of the 1990s removed layers in many companies, and some of them spent the next decade quietly rebuilding them after the institutional knowledge walked out the door with the managers.
These are serious objections. Anyone proposing a flatter, faster organization should be able to answer them.
What approval layers actually do
The answer starts with being precise about the functions layers perform. Strip away the org chart and an approval layer does four things.
It checks decisions against rules: policies, limits, regulatory requirements, and commitments the business has made. It catches exceptions: the cases the rules did not anticipate. It records accountability: who decided, on what basis, and when. And it escalates: it decides what deserves attention further up.
Humans perform all four today, but they perform them in samples and on a schedule. A manager reviews some of the work, at the time set by the approval cycle, using the information available that day. Everything between reviews runs on trust.
An AI operating system can perform the first, third, and fourth functions continuously and completely. It can check every action against every applicable rule at the moment the action happens. It can record every decision with its inputs and its reasoning. It can apply consistent thresholds to decide what gets escalated and to whom. What it cannot do well, and should not be asked to do, is the second function: handling the genuinely novel case that no rule anticipated.
That division is the whole point. McKinsey’s argument that executives should spend less time moving information and more time exercising judgment, resolving exceptions, and coaching people only works if the system takes over the parts of governance that are rule-based. When it does, the human role is not eliminated. It is concentrated on the work only humans do well.
Guardrails are decisions, not documents
McKinsey’s opening scenario shows what this looks like in practice. An insurer facing new margin regulations models its options, and leadership agrees on a plan: protect key distribution partnerships, and no product withdrawals without CEO approval. The system records those decisions as guardrails. From then on, agents generate product redesigns and test each one against the codified rules and governance policies, compliance reviews the options, line leaders decide, and the system tracks each product after launch and alerts its owner before it drifts toward breach.
Notice what happened to the CEO’s instruction. In most companies, “no withdrawals without my approval” would be an email, a slide in a steering committee deck, or a line in a policy document. Its enforcement would depend on everyone remembering it. In the AI operating system, it became a rule the system enforces at the point of action, for every agent and every person, without anyone having to remember.
That is the difference between governance as documentation and governance as infrastructure.
A guardrail that works as infrastructure has three properties.
It is enforced at the point of action, not reviewed after the fact. It is scoped to identity, so what an agent can see and do never exceeds what the person it acts for is allowed to see and do. And it is observable, so anyone accountable can see what was done, by which person or agent, under which rule.
Governance with those properties does not slow the organization down. It is what lets the organization move fast without rebuilding the layers.
Why bolted-on governance creates shadow systems
McKinsey asks another pointed question: what incentives and controls will keep important decisions inside the AI operating system rather than in shadow systems that grow up around it?
Shadow systems are not a discipline problem. They are a design problem. People route around governance when the governed path is slower than the ungoverned one. If using the official system means waiting for access approvals, filing requests, and working in a tool nobody likes, people will paste data into a personal AI assistant, build a spreadsheet on the side, and make the decision there. Every one of those workarounds is a decision the organization cannot see, audit, or learn from.
This is why governance bolted onto an AI operating system after the fact tends to fail. It adds friction to the governed path while doing nothing about the ungoverned one. Governance built into the architecture works the other way. When access checks, policy enforcement, and logging happen automatically inside the tools people already prefer, the governed path becomes the easy path, and shadow systems lose their reason to exist.
Designing decision rights
McKinsey’s recommended first action on management is to redesign decision rights: identify which decisions AI agents can make or execute, which require human judgment, and when issues should escalate to senior leadership. In practice, that produces three tiers.
Agents execute within guardrails. Routine, rule-based decisions with clear limits. In a regional freight carrier, an agent might adjust rates on a lane within an approved band when margin drifts, logging each change and the rule it applied.
Agents recommend, people decide. Decisions that need judgment or carry relationship risk. When a key account’s lanes fall below threshold, the agent assembles the analysis and options, and the pricing director chooses.
Signals trigger leadership intervention. Thresholds that indicate something structural. When margin erosion spreads across a region or a customer segment, the system routes it to the executive team, which is what replaces the monthly review that would have caught it weeks later.
The tiers are not fixed. As the organization sees how agents perform within guardrails, decisions move down a tier. That progression, earned with evidence rather than granted on faith, is how trust in the system is built. It is also the only honest answer to the report’s question about why organizations drift back to approval layers: they drift back when they delegated decisions they had no way to observe.
The mid-enterprise advantage, and its limit
Mid-enterprise companies are in an interesting position here. Many of them are already closer to McKinsey’s target than large enterprises are. Spans of control are wider, layers are fewer, and leaders already know the people several levels down. The organizational change the report describes is smaller for a $600 million company than for a $60 billion one.
The limit is tolerance for failure. A large enterprise can absorb a governance mistake with a large compliance team and a long balance sheet. A mid-enterprise company usually has a small compliance function and less room for error. For these companies, governance cannot be a program staffed by specialists. It has to come with the system.
What this requires architecturally
At Datafi, governance is built into the architecture rather than added afterward, because we have seen that it is the precondition for deploying anything autonomous at all.
Control Tower governs every connection between AI and business data. No AI tool reaches data directly. Every request is checked against the person’s own access, down to the row, so an agent acting for someone never sees more than that person can. Policy, access control, and audit are part of the platform rather than separate products to integrate.
Everything is observable. Every question and answer in Converse, and every step an agent or app takes in Activate, is logged in Control Tower. That record is what makes delegation safe: when a decision moves from a person to an agent, the organization can see exactly what the agent did and why, and can show it to an auditor or a board.
Runtime coordinates multi-step work across systems so that agents act within the same governed environment from start to finish, and Studio lets teams build those agents without creating a new, separately governed stack for each use case. Cyber addresses the new security risks autonomous agents introduce. And because Datafi works inside the AI tools people already use, the governed path is also the convenient one.
Trust is also built in stages. Organizations can start read-only, with one team on one dataset, see how the system behaves, and expand from there. That is the same evidence-based progression of decision rights McKinsey recommends, applied to the platform itself.
The question that has to change
Most discussions of AI and organization design ask how many layers can be removed. That is the wrong first question, and asking it first is how companies end up rebuilding the layers a few years later.
The better question is which decisions the organization can prove are safe to delegate. Proof means the rules are encoded, the actions are enforced at the point of action, and the outcomes are observable. Where that proof exists, layers can come out and management can shift from calendar to intervention. Where it does not, no amount of executive enthusiasm will hold the new structure in place.
McKinsey calls the AI operating system a second brain for the enterprise. This series has argued that the second brain needs three things to deliver on that promise: business context that turns data into meaning, ownership of that context independent of any vendor or model, and governance strong enough that people trust it to act. The first creates the value. The second protects it. The third is what lets the organization actually change how it runs.
This is the final post in this series. If your organization is working through which decisions to delegate first, or how to evaluate AI operating system options against the ownership tests in Post 2, we would be glad to compare notes.
Datafi is the operating system for business AI. We help mid-enterprise organizations unify their data, deploy governed AI agents, and deliver measurable outcomes in weeks rather than years, without migrating off the systems that already run the business.
The Second Brain: Bringing the AI Operating System to the Mid-Enterprise
Part 1: Why AI Adoption Isn’t Becoming AI Value
Part 2: Own the Context, Rent the Stack
Part 3: You Can’t Delayer What You Can’t Govern
Written by Vaughan Emery, Co-Founder & Chief Product Officer at Datafi
Source: “The AI operating system: A new way for CEOs to run the enterprise,” QuantumBlack, AI by McKinsey, October 2026.
