In the last post I made the case that your AI pilots aren’t failing: they’re measuring you. Every pilot works because somebody builds it in a protected world; and every pilot dies in production because your real conditions live there. The gap between the two is your readiness gap, quantified. Which raises the obvious question: readiness for what, exactly?
Most of the industry answers with a maturity model. Five levels, a spider chart, an eighteen-month program to get to Level 3, and a comfortable consulting engagement measured in workshops. I want to offer something more useful: four conditions. Not levels, actual conditions. Either they exist where you’re trying to run AI, or they don’t. All four are testable, and you can test them this week.
The organizing idea behind all four: you can’t automate a tangle, only a clean boundary. Everything below is a different way of drawing a boundary.
Condition One: Encapsulated Technology
AI needs a bounded space to work in. That means capabilities with real edges: code that belongs to somebody, interfaces that hide what’s behind them, dependencies managed at the boundary instead of leaking through everything. The absence looks like the enterprise I described in the last post: shared codebases nobody owns, branches that live for months, eighteen teams required to touch anything. Dependencies don’t show up in the org chart; they show up in the code, and AI lands right where they show up.
The Test: can one team change one capability without asking permission of another? If the answer is no, an agent can’t either. It will just generate the merge conflicts faster.
Condition Two: Clean Data at the Source
Not clean data in aggregate. Clean data at the source: validated, owned, and documented where the team creates it. The industry has spent two decades building compensating controls for bad data practice: warehouses, lakes, lakehouses. Push everything into one place and make it one central team’s job to understand every business rule in the company. No team can. There is no easy button here, and pointing AI at the swamp doesn’t drain it: garbage behind an abstraction layer is still garbage.
Data work still matters, arguably more. This is an argument about where it happens. The pattern is a data mesh: data owned, validated, and served where it is created, by the team that owns the capability. Build it the way you build everything else in this series: inside the boundary you are about to automate, one slice at a time. Let the rest of the swamp wait its turn.
The Test: pick a critical data element. Do you know where it is born, and is it valid there, or does somebody fix it downstream? If it’s fixed downstream, AI is consuming the unfixed version everywhere else.
Condition Three: An Organization Designed Around Ownership
Teams aligned to business capabilities: domains, not components. The absence is familiar: a QA team, a front-end team, a back-end team, and a piece of work that touches all of them, coordinated by meetings. In that design nobody owns an outcome, so there is nothing an agent can be accountable to. AI doesn’t fix an ownership vacuum; it floods it with output nobody is responsible for. And scale doesn’t break the rule: a capability too big for one team decomposes into subdomains that aren’t. Ownership holds at every level.
The Test: for any business capability that matters, can you name the one team that owns it? One team. If the answer is a list, the condition doesn’t exist.
Condition Four: Intent Governed at the Top
This is the big one, the one condition that the twenty-pilot story violated most visibly. Energy without direction: boards demanding results, engineers experimenting, and no mechanism between them, no place where an AI hypothesis goes to get funded, measured, scaled, or killed. Governance here does not mean bureaucracy. It means somebody can say what we are trying to learn, what we are trying to earn, what we are going to stop doing, and what number tells us the truth. Directed R&D instead of undirected. Harmonized instead of standardized.
The Test: when a pilot succeeds, is there a system that moves it into production, and when a pilot fails, is there a system that kills it? If pilots accumulate, intent isn’t governed, it’s ambient.
Here’s the Part That Should Change Your Plan
You do not need all four conditions everywhere. That is the trap: hearing “conditions” and scheduling a three-year enterprise readiness program, which is just the maturity model wearing a new hat. Remember what we proved in the pilot. We can create these conditions. Your innovation colony created all four in a small, artificial space. That’s also the difference between a pilot and what comes next: a pilot simulates the conditions; a slice creates them for real, with production inside the boundary. A slice is not a bigger pilot. The work is to create the conditions somewhere real: one boundary, one capability, one portfolio, one slice of the enterprise where all four conditions genuinely hold. In the agile world, we called these expeditions. That’s the difference between transforming the company and transforming a slice of the company that pays for and builds momentum for the next slice.
Which slice? That’s the next post: why the application is no longer the unit of decision, and how to find the seams worth cutting.
Until then, run the four tests. They take a week, they cost nothing, and unlike your pilots, they measure the thing you can actually fix.
This is Part 3 of a seven-part series. Start with Part 1 here.
