The Tabs Drew the Org Chart

The buzzphrase of May 2026 is designing an AI operating model. IBM put it on a stage at Think 2026 on May 5 and gave it a four pillar blueprint: agents, data, automation, hybrid. Microsoft followed three days later with the general availability of Agent 365, a unified control plane priced at fifteen dollars per user per month inside the new E7 SKU. Accenture and ServiceNow rolled out a Forward Deployed Engineering program for agentic AI. Every Big Four firm and every hyperscaler now has a slide deck explaining how to design the operating model that will run a Fortune 500 on AI.

The decks share one problem. The operating model already exists. It was drawn months ago. It runs every day. It just is not on any org chart in any large company.

Salesforce's 2026 Workforce AI Survey put the gap in two numbers. Sixty-seven percent of employees use AI tools at work. Eighteen percent of companies have a formal AI security policy. The middle is crowded. Browser tabs open to Claude and ChatGPT, Cursor windows with company code pasted into the wrong account, voice transcripts run through personal Whisper installs, agents acting under personal API keys against company SaaS. That is the operating model. The Futurum group summary of Microsoft's Agent 365 launch said the quiet part out loud: the product "turns shadow AI into a governed asset class." Governed asset class is the giveaway. You do not govern something you designed. You govern something you found.

The Blueprint and the Build

The IBM blueprint is the architect's drawing. The Agent 365 control plane is the survey crew sent in afterward. Both are real. They are doing different jobs.

IBM's four pillars are organized around parts of a system the CIO can buy: watsonx Orchestrate for multi agent flow, Confluent for data movement, Concert for operations, Sovereign Core for jurisdictional control. Wiring them together produces a top down operating model. It is the model on the slide. Microsoft's product, in contrast, is built for discovery. The May 8 release notes describe shadow AI visibility in the Microsoft 365 admin center and Intune policies that block specific local agents, with initial coverage targeting OpenClaw and planned expansion to GitHub Copilot CLI and Claude Code. A Defender context map, scheduled for June, will draw connections between agents, devices, MCP servers, identities, and the cloud resources each reaches. That product roadmap is an admission. The shadow operating model is large enough to need its own cartography.

Two operating systems are now running in the same building. The one the board approves and the one the work uses. Strategy lives in the gap between them, or it dies there.

Designing an AI Operating Model Starts with the Existing One

Designing an AI operating model is being sold as architecture. The discipline closer to the truth is archeology. Before you can decide what the company should run on, you have to know what it already runs on. The dig is unglamorous and produces no slides. It is also the only step that gives a designer any data to work with.

The questions the dig answers are concrete and rarely written down. Which model does each function open first? Where do prompts get saved, and which prompts have become canon? Whose laptop has the agent that closes the books each month? When does a person hand off a draft to a tool, and when does a tool hand back to a person? Where in a workflow does someone copy a Claude response into Salesforce or NetSuite and trust the system of record to forget that a model touched it? Each of these is a real edge in the operating graph the company depends on. None of them sit in the org chart on the wall.

Without that survey, the blueprint that gets purchased is a fantasy of the company as it appears on a slide, not the company as it actually performs work. The MIT NANDA report from August 2025, the one everyone is still citing in 2026, sized the cost of that fantasy. Ninety-five percent of enterprise AI pilots reach no measurable ROI. MIT calls the cause a learning gap. The learning gap is the operating gap. The model leadership designs and the one the work runs on never come into contact.

The Five Layers Hidden Under the Floorboards

A real operating model already decides at least five things every hour, even when nobody has written the rules down.

Tool choice. The intelligence analyst opens Claude for long context. The marketer opens ChatGPT for image attached prompts. The engineer opens Cursor because the file context is automatic. None of those choices were made by a CTO. They were made by the worker, in the first ten seconds of each session, and they have hardened into reflex. Switching them now will cost productivity, and executives who try will find that out after they have already signed a single vendor contract.

Escalation. Every employee using an agent has invented their own rule for when the agent stops and asks. Some stop the moment the cost is above ten dollars. Some let the agent push every decision until a customer complaint pulls it back. A few have wired Slack notifications into a personal automation that gives them an approve or deny button on a phone. Those private escalation paths are now the company's actual incident protocol for any AI mediated decision.

Memory. The agent that drafts your sales emails knows things about your top accounts that no CRM field records. The retrieval pipeline running on one account executive's laptop has become a system of record. When that person leaves, the institutional memory leaves with them. The retention package the company writes for that role is now a memory retention package, whether HR labels it that way or not.

Sign off. Someone is on the hook when the model is wrong. In most companies, the person on the hook is the human who pressed send. That is the implicit accountability rule the company has chosen. It is the wrong rule for any task where the human cannot meaningfully audit the output, and right now finance, legal, and customer support are all running on tasks where the human cannot meaningfully audit the output. The rule will fail in court the first time it is tested.

Audit. The company assumes that everything material went through a system that produces a record. Half of the AI mediated work does not. The reconstruction problem after an incident, the one regulators love to ask about, is solvable for the work that ran through the official tools and unsolvable for the shadow work. The audit boundary is now a chart of the company's actual exposure, and it does not match the chart the CISO drew.

Each of these five layers has been answered, by default, by the people doing the work. The designer who shows up with a blueprint and ignores those answers will produce a deck. The designer who maps the answers first will produce a system.

What MIT Measured Was the Distance Between Two Maps

Re-read the NANDA report with this lens and the failure rate stops being mysterious. The five percent of pilots that delivered measurable ROI share one trait that MIT identifies and most coverage skims past. The successful pilots were retrofits onto something already running. Someone had already been using an AI tool to do the work informally. The pilot replaced the personal account with a sanctioned account, formalized the prompt, captured the audit trail, and put the cost on a department budget. The pilot worked because the operating model was already there and the project was only the formalization step.

The ninety-five percent that failed were the inverse. A vendor was bought, a workflow was designed, a training session was held, and then the tool sat in a tab that nobody opened because the work was already being done somewhere else, in some other tool, by some other route. The fantasy operating model never met the real one.

This is the rule the May 2026 launches do not say out loud. A formal operating model that ignores the shadow one fails. A formal operating model derived from the shadow one usually works.

The Five Forks

Once the map exists, the design work begins. For every workflow the archeology surfaces, the choice is a fork, not a build. Formalize, fork, retire, fence, or accept. Each fork has a cost. Each is a sentence long, and a real person has to sign it.

Formalize. Take the shadow workflow and put it on a sanctioned tenant. The account executive's personal Claude project becomes a managed agent in the Claude Enterprise plan, running on the sandbox that Anthropic shipped on May 28 alongside Opus 4.8, connected to a private MCP server inside the company perimeter. The work is the same. The audit trail is now intact. The cost moves from a personal credit card to a department line.

Fork. Two functions are using the same workflow in opposite ways. The legal team prompts the model to flag risk in every contract clause. The sales team prompts the model to soften risk language in every contract clause. The same model serves opposing purposes inside the same company. The design choice is to keep both branches and make the difference legible to anyone who looks at the system, rather than picking a winner from a podium.

Retire. A workflow that survived because the tool was free no longer makes sense at audited scale. The marketer running ten thousand images a month through a personal API key is one Microsoft license away from being on the company's books. If the work is not worth the budget line, the work was never worth doing.

Fence. Some shadow workflows do not belong on the sanctioned side and should not be killed. The engineer using a personal Claude account to think through architecture is doing something that has no path on the official tenant and is creating no risk the company should bear. Fence it. Write a rule that this kind of work can be done in personal time, on personal accounts, on non-confidential material, and put the boundary down so the engineer is not exposed.

Accept. Some shadow work is so embedded that the cost of formalization exceeds the cost of the residual risk. Write the risk on the register. Accept the exposure. Tell the auditor the truth.

These five forks are the operating model design. They are decisions, each one a sentence, each one signed by a named person. Most consulting decks skip past them because the decisions are uncomfortable and they do not look like deliverables.

Architecture Work, Not Procurement

The IBM blueprint and the Microsoft control plane are both useful. Neither is a strategy. They are inputs to a strategy that has to be drawn by someone who has done the archeology first and made the forks second.

That work is closer to systems engineering than to HR. It demands a person who can read a Slack channel and a network diagram with the same eye, who can sit with a salesperson and watch them work for an hour and then sit with a security architect and explain what they saw in policy terms. It is slow and unglamorous, and it is the only kind of work that closes the gap MIT measured.

It is also not the kind of work the vendor selling the blueprint can do for you. The vendor's product is calibrated to the blueprint and does not benefit from the archeology. The Microsoft product helpfully discovers the shadow operating model and helpfully wants every part of it to move onto Microsoft tenancy. The IBM product helpfully assumes that the four pillars are the right four pillars for your company. Both views are partial. The architect's job is to hold the partial vendor views together against the ground truth of how the company actually performs work.

A company that does this has an AI investment that compounds. A company that buys the blueprint and skips the dig will, sometime in the next twelve months, sit in a conference room and ask why the second pilot has rolled out and the second pilot is producing the same flat ROI numbers as the first one. The reason will be the one MIT already gave them. The fix will be the one no vendor sells.

At Agor AI Advisory, the work we do for clients starts with the dig. We map the operating model your company is already running before we propose a single change to it. We sit with the analyst, the engineer, the account executive, and the controller, and we trace what they actually do on Tuesday at three in the afternoon. The blueprint comes after. The procurement comes after that.

If the gap between the operating model you have designed and the operating model your company is running has begun to show, it is not too late, but it is no longer cheap. The longer it runs, the more the shadow side hardens. Schedule a strategic consultation with us today.