A team automates document preparation. The drafting gets faster. The customer notices nothing, because the week-long approval queue sitting behind it never moved.
The pilot worked. Nothing downstream of it did.
That example belongs to Harry Narang, partner at Rockmere Partners and co-founder of the American School of AI, from a piece published this week in the Ritz Herald on what separates an AI-native organization from a company with an impressive demo. It is worth reading in full: The Leadership Blueprint for Building an AI-Native Organization.
His argument is uncomfortable for anyone sitting on a portfolio of pilots. The gap is not model quality or vendor choice. It comes down to a handful of leadership decisions that get made one at a time, months apart, by people who never compare notes. Made as a set, they produce a business that competes differently. Made separately, they produce an expensive collection of demonstrations.
We work mostly in regulated environments, where that distinction has teeth. Here is how his blueprint reads from the sponsor’s seat: five decisions that belong to leadership, and the three questions a program has to answer before it earns another dollar.
Decide what the speed is for
Narang wants one question answered before anyone talks to a vendor. If your competitors can buy the same capabilities, what will make customers choose you?
“Everyone wants to talk about tools, agents and automated workflows,” Narang says. “Those are the easy part. The hard part is deciding what all that speed is for.”
An AI-native company has speed in abundance. It can prototype in an afternoon and analyze in seconds. What it lacks is a destination, and speed without one arrives at the wrong place sooner than everybody else, using tools the competition bought the same quarter.
There are only a few honest answers. You serve a segment the industry wrote off as uneconomic. You deliver an experience that is materially better rather than marginally better. You change the economics of something you already sell. Whichever it is, that answer decides where the money goes, and it belongs in writing before procurement starts rather than reverse-engineered after the invoice lands.
Then make it concrete: a measurable outcome, a baseline you can defend, and a named business owner.
One more split that rarely gets made. Some of this work keeps you level with the market. Some of it could produce something a customer cannot get elsewhere. Both belong in the portfolio, just not in the same column competing for the same attention. The second kind is the only sort that moves your position, and it always looks riskier in the room.
Give the owner authority, not a budget
The test for whether your named owner is real is a simple one: can this person change a decision right?
Back to the approval queue. Automating document preparation while leaving a week of sign-offs untouched is the most common shape of failure, and it is not a technical failure. The team that got the project could change the drafting step. Nobody gave it standing to change the handoffs, the priority order, or who is allowed to approve what.
If the answer to that question is no, the project will optimize whatever sits inside its boundary and stop at the edge, which is usually where the delay lives.
In regulated work the objection comes fast: those sign-offs exist for a reason. Often true. But the reason is rarely that a human must read every one. It is that somebody is accountable when it goes wrong. Different problem, different fix, and telling the two apart is a leadership job. No delivery team can decide a second reviewer is no longer required on a low-value case.
Fund learning, not building
Give every pilot a decision date and scale-or-stop criteria agreed in advance, so money releases against evidence instead of against a roadmap milestone.
Narang reframes what the technology is actually good for. “Building a prototype faster is useful. Finding out sooner whether customers need it and will pay for it is worth a lot more.”
That makes AI the cheapest instrument a company has ever had for testing a strategic bet, and it changes how you fund one. Every pilot also needs an owner prepared to run the thing in daily operation if it works.
The discipline matters more than the tooling. Without a decision date, pilots do not fail. They persist, quietly consuming a little budget and a lot of your best people’s attention, and everyone stays too polite to kill them.
Evidence has to come from customers, too. AI-generated personas and market summaries are fine for producing hypotheses. They are not observation, and they have a habit of agreeing with whoever wrote the prompt.
Put the boundaries in permissions, not prompts
Access to information is not permission to act, so define which actions the system may take on its own, which need a human signature, and when it has to stop and escalate.
This is the part that should interest anyone in banking, insurance, healthcare or pharma.
A capable model on its own is not a system. It becomes one when it is wired to authoritative data and curated context: the policies, business definitions and workflow knowledge that make an answer right for your company rather than plausible in general. Someone has to own that material, keep it current, and decide which people and systems can reach it. Retrieve a superseded policy or an unexecuted agreement and you get a confident, well-written answer that is wrong in a way nobody catches until a regulator does it for you.
The blueprint is blunt about where the limits on what a system may do belong. They live in system permissions that can be enforced, not in a line of a prompt asking the model to behave.
Before authority expands, test against representative situations, including the awkward ones and the outright failures. Keep audit trails. Evaluate continuously rather than at go-live. Rehearse the fallback instead of documenting it. And staff the human review properly. As the piece puts it, a name on an approval screen is not oversight. A reviewer without the expertise, the time or the standing to say no is a control on paper.
Decide where the saved hours go, and agree how you will count them
“Time saved becomes valuable when leaders decide what it’s for.”
Freed capacity can go to more customers, to faster discovery, or to less overtime. It has to go somewhere on purpose. If spend holds flat and the business delivers nothing extra, saved hours stay saved hours.
Agree the verification method with finance before the work starts. Track incremental margin, avoided future spend and released capacity as three separate lines so nothing gets counted twice. Include the full cost: implementation, model usage, data maintenance, human review and exception handling. The last two get left out of the business case and then show up in the run rate.
There is a commercial trap here too. Under an hourly contract, faster delivery cuts your revenue. Lower cost to serve can make a segment you have always declined suddenly worth having. Efficiency does not stay with you by default. Pricing has to move alongside the workflow, or the benefit transfers to the customer and you have paid to give it away.
What a credible program can answer
Narang’s closing standard is a good one to hold your own portfolio against. A transformation worth continuing can say three things without hedging: which customer outcome will improve, who owns the change, and what evidence will justify the next dollar.
Most programs answer the first. Fewer answer the second. The third is where the room usually goes quiet.
If that sounds like your last steering committee, the fix starts with the leadership team rather than the platform. We run AI-Native as a private program for corporate groups, built around your own workflows, your own approval queues and your own numbers. Talk to a partner directly.
Harry Narang’s full blueprint: The Leadership Blueprint for Building an AI-Native Organization, Ritz Herald, September 2026.