AI won't transform a company you refuse to rebuild.

Look at your company's AI initiatives and ask one question: which of them changes what the business can actually do?

For most enterprises the honest answer is none. People search faster, summarize faster, draft faster. But the workflows they run are the ones you had in 2022. Same handoffs, same five teams touching one request, same person copying data between systems by hand.

The caution behind that is fair, because you can't take an enterprise offline. Customers need serving, revenue needs closing, and auditors need answering.

But somewhere along the way, "we can't stop the company" turned into "so we'll only bolt things on top." Those are two different things: the first is a real constraint, and the second is a choice to stay the same company with faster typing.

There's a harder and more valuable option: rebuild the company while it runs, in production, piece by piece, with customers on the line the whole time. Most enterprises aren't close, and the numbers show it.

Most enterprise AI transformation is too small to matter

McKinsey's 2025 survey found that 88% of organizations now use AI in at least one function. Only about 6%, the ones McKinsey calls AI high performers, report real EBIT impact, and those are disproportionately the ones that redesigned workflows around it.

A survey can't prove which way the causality runs. My bet is the obvious way: nobody gets EBIT impact from a tool they rebuilt nothing around. Everyone else plastered AI on top of the org chart they already had.

So ask the question most AI roadmaps never do: what company would you build if today's AI had always existed?

You'd start with what the customer needs and work backwards. What problem should they never hit? What could happen instantly instead of over days? Where does value leak between teams and systems?

Some of the handoffs you have exist for real reasons, controls a regulator or an auditor demands, and you'd keep those. Most exist because that's how the org grew, and you'd never rebuild them on purpose.

That company looks very little like the one you run today. Getting there means AI has to do more than help people think.

AI has to take action, not just help people think

The first wave of enterprise AI waits to be asked. Find this document. Summarize this meeting. Draft this email. Suggest what I should do next.

The next phase is different. AI starts to do the work:

• Read what's happening across systems
• Decide what should happen next
• Take the approved action, and coordinate it across teams
• Pull in a human when judgment actually matters
• Verify the result, and escalate when something breaks

Picture a customer reporting a critical service failure. Today someone opens a ticket, someone else checks the account, operations investigates, finance decides whether a credit applies, a field team schedules the work, and the account manager chases everyone for updates.

Most of the company's effort goes into moving information and responsibility around the org, not into solving the problem.

Now picture AI doing that assembly: identifying the customer and affected services, pulling the history, investigating the cause, coordinating the approved response, calculating the credit, keeping the customer informed. A person stays in the loop wherever the call is high-stakes or the relationship matters.

Your people stop being the connective tissue between systems. That's a different operating model, and it's the leap most enterprises haven't made.

Customer value is the outcome. AI usage isn't.

Once AI is doing that work, the question becomes how you measure it. Most companies count the wrong things: seats, prompts, hours saved, licenses activated. Those tell you a tool is being used, not that the company got more valuable. Use the enterprise AI pilot scorecard to measure accepted results and the effort needed to reach them.

"Hours saved" is the weakest of the lot. Take three hours off someone's week and you still don't know what happened next. Maybe they solved a harder problem, maybe they made new revenue, maybe they just sat in another meeting.

The measures that matter are simpler:

• Customer problems actually resolved
• Revenue generated or recovered
• Cost taken out
• Time to resolution, and time to market
• Retention and customer trust
• People moved onto harder, more valuable work

The point is to strip away the low-value coordination around people's work and aim their judgment at bigger problems. That beats saving someone ten minutes on an email.

That's the upside. The part nobody puts on a slide is uglier: for a lot of people, coordinating between systems is the job, and coordination is the first thing AI absorbs. Some of those roles won't survive the rebuild.

The people in them usually understand the business better than anyone, and the ones who embrace the new tools won't get left behind. They move into the higher-value work the rebuild opens up, roles that didn't exist before.

Run consequential pilots, not AI theater

Pilots matter, but most companies run them wrong. They pick something small, contained, and unlikely to cause trouble: a pilot built to get signed off, not to actually change anything.

A team trials enterprise search. Someone builds an internal chatbot. A group shows AI can summarize documents on sanitized data.

The company gets to say it's "doing AI," but nothing consequential has happened.

The caution is rational. An AI that acts can fail in ways a chatbot can't.

A serious enterprise runs many consequential experiments at once. They can be narrow, scoped to a single business unit, a set of controlled permissions, and one real operational problem so the work stays focused. But narrow can't mean irrelevant.

Every serious pilot needs a few things nailed down:

• A link to a real strategic bet
• Measurable customer or economic value
• Someone's name on it
• Access to the real systems and data
• A clear definition of success, and a deadline to decide
• An agreed plan for what happens if it works

If nothing strategic depends on it and nobody's name is on it, it isn't a pilot. It's a demo with a budget.

A pilot exists to produce a decision. One that proves you shouldn't pursue an idea is a success, because it prevented a bigger mistake.

What can't happen is a pilot drifting for months without a decision.

It also has to touch reality to prove anything. Enterprises love to make pilots safe by stripping out everything that would prove they matter: fake data, no real actions, contained away from production.

Starting in a sandbox or shadow mode is fine, and the controls should match the consequence of the work. But those are stages toward real operation, not the destination.

Eventually the pilot has to run on live data, take approved actions, and show it can be trusted before you scale it. Skip that, and you haven't proven anything you can put into production.

Governance should create speed, not queues

The people closest to customers and operations see problems no central AI strategy will ever find. They know where customers wait, which handoffs fail, and which approval actually protects the business versus which one just survived because nobody questioned it in a decade.

So let business units own the problems, the experiments, and the outcomes. The CIO doesn't need to own every pilot, and if every experiment enters a bespoke approval queue run by one central team, the business moves too slowly to matter.

Central teams (security, data, AI) should build the fast, known routes everyone else runs on:

• Approved tools and environments
• Clear data classifications and permissioning
• Monitoring and audit trails
• Where a human has to review, and where write-access is gated
• Recovery standards

McKinsey's org research shows the same split: risk and governance tend to be centralized while adoption is distributed. The central team's job is to make experiments easy to run safely. It shouldn't run them all.

The Head of AI should act more like a CEO than a model curator. Their job is to make the business move faster, not to be yet another layer of approval to work through.

Then move fast on the gates themselves. If an experiment creates no value, kill it. If it creates value but can't yet be trusted, fix what's missing. If it creates value and can be trusted, scale it.

The bar is trustworthy, not flawless. On anything with real consequence, that's the line that matters.

The economics of that scale-it decision also improve over time. Stanford's 2025 AI Index found the inference cost of GPT-3.5-level performance fell more than 280-fold in about two years.

Costs at the frontier don't fall that fast, but the direction is clear: what already creates value tends to get cheaper to run, not more expensive.

Nobody can design the AI-native company in advance

Picturing the company you'd build if today's AI had always existed gives you a direction, not a blueprint. No executive team can design the AI-native company up front. You don't yet know what the technology will make possible, what your people will find when they use it for real, or which org boundaries will stop making sense.

The architecture emerges through the work. One workflow that reaches production exposes three more opportunities. A pile of disconnected pilots rebuilds nothing, so they have to connect into one continuous rebuild. You start with the conviction that the company has to change, run experiments where you see real customer value, and let the destination show up through the pilots.

The hard part is infrastructure

Everything above runs into the same wall: an AI that's supposed to take action across the business has to reach the systems, understand what they can do, and act under real governance. That's the gap a lot of pilots stall in.

It's the reason we're building Monarch. It doesn't try to rewire the whole company at once.

You point it at one acute, multi-system job, the kind where your people are the connective tissue today. It discovers what those applications can do and connects them into a Product Graph. Then it runs the workflow as governed, auditable code, with a human in the loop where it matters.

Discovery shows you what a system can do, not what a field means, which copy is authoritative, or why a control exists. That's the judgment your people supply. The enterprise ontology guide explains how discovery and business definitions fit together.

That doesn't contradict running many experiments at once. Each one still has to start narrow. Monarch is how one of them gets to production.

Prove that one while the others run. Then expand it, make it real, and let it compound, the same way the rest of this works.

Rebuild the enterprise while it runs

None of this happens on a pause. The company keeps serving customers the whole way through, and you rebuild it in production, one workflow at a time.

A year in, it isn't a slightly better version of the old business. The systems work together. The company moves faster. Its people work on real problems instead of shuffling data between systems. And it's still improving.

That's what enterprise AI transformation should look like: a fundamentally different company.

Every quarter you spend making the old company a little faster is a quarter you're not building the new one. That's the real cost of the incremental path.