Most AI transformation programs start by asking the wrong question. "What should we build?" is not the right first move. The right first move is an honest conversation about where you actually are, what's already running in your shadows, and what failed for the people who tried this before you.
That's the ADAPT phase. And it starts with one meeting.
What honest looks like#
The meeting is simple on paper. CIO chairs. CISO, CTO, and two or three business unit leaders in the room. No consultants. No slide deck. One agenda: where are we, really?
The evidence questions that drive it are not comfortable. How many agents are running in production that you know about? How many are running that you don't? Can you answer "what did agents touch last quarter" in a single query? When something goes sideways, do you have attribution back to the human originator, or do you have "service account 47"?
Most leadership teams have not had this conversation in a room together. Most have had individual conversations with their own teams and emerged with different answers. Getting those answers in the same room, at the same time, is the most valuable thing you'll do this quarter. Not because the answers are good. Because naming what's true is the only foundation anything else can build on.
Walk the graveyard out loud#
The second thing the meeting does is name the failure patterns the org has already lived through. The RPA initiative that went nowhere. The Cloud CoE that became the bottleneck. The earlier AI pilot that died on funding. Every organization has three of these if they're honest. Most pretend they don't.
Writing them down, in the executive's voice, in the program charter, is what prevents the next initiative from repeating them. Not a PowerPoint slide. The charter. The document that governs the program. Past failures are the most underused asset in the building.
The control tension#
There's one question the meeting has to surface and not resolve too quickly. Frank Brandes, who ran Unilever's enterprise integration program, gave me the sentence that names it: "If you have too much control, you kill innovation. If you don't have enough control, you don't get the reuse."
Where is your org on that line right now? Too much control looks like agents stalled in review queues, business units routing around IT to get things done, and shadow AI returning faster than you can govern it. Too little control looks like innovation chaotic, credentials proliferating without governance, and incidents you'll find out about at the breach.
Neither end is stable. The tension is permanent. The only thing in your control is how you manage it.
What the executive commits to#
ADAPT has four outputs. A written self-assessment against the five-rung maturity ladder. A list of three specific past failures the org commits not to repeat. A named executive sponsor (CIO by default; the function has to feel like enablement, not a security checkpoint, which is why CISO is the wrong chair). And kill criteria for the program itself: written conditions under which the methodology gets dissolved or restructured if it stops working.
That last one is what most programs skip. Writing kill criteria down is what prevents the program from getting killed. The executive who knows you'll dissolve the methodology when it stops enabling is the executive who keeps funding it when it does.
None of this requires a vendor decision. None of it requires new headcount. It requires one honest meeting and a charter that means something. Your existing people can do it in a week.
Part four of a series based on the Agentic Adaptation Playbook. Previously: most enterprises think they're on rung 3. Next: the producer/consumer flywheel — why your engineers are building the same thing twelve times, and how to stop it.
