Six weeks after a successful AI launch I sat down with the head of operations and looked at the usage dashboard. The numbers were sobering. Of the five custom skills we'd shipped, two were used daily by a small group, two had been used twice ever, and one hadn't been touched. Nothing had broken. The agents worked. The team had been trained. The launch email had gone out. And nobody was using most of what we'd built.
That moment is more common than the case studies suggest. Shipping is not adoption. Shipping is the easiest part of the rollout, and treating it as the finish line is how most AI deployments quietly die.
What actually happens after launch
Three things, in roughly this order. First, the people who asked for the tool start using it. They've been waiting; they're motivated; the agent saves them time on day one. This is the cohort everyone celebrates in the launch retrospective. They are not the test.
Second, everyone else doesn't. They're busy, the tool is new, the workflow they were doing manually is still working, and there's no immediate cost to ignoring the agent. This is the cohort that decides whether the rollout actually succeeded.
Third, edge cases start surfacing. The agent does something subtly wrong on a low-frequency workflow. Trust degrades faster than it builds. One bad output erases ten good ones. Without active intervention, the second cohort never gets there — they hear the negative anecdote and write the agent off.
"Adoption is not a launch event. It's a daily operation that runs for ninety days, then fades into the background — if you're lucky."
The metric that matters
It's not aggregate usage. It's not tokens processed. It's not the gross number of "AI interactions per week." Those are vanity metrics that look good in a board pack and tell you nothing about whether the rollout is working.
The real metric is per-person, per-skill. Across the five custom skills we shipped on the most recent rollout, that breakdown told us in week three exactly which skills had organic adoption, which needed intervention, and which were probably wrong about the workflow they were targeting.
Two skills had power users who'd built the tool into their daily flow. Those needed nothing from us. Two skills had two or three people each, no organic spread. Those needed a champion. One skill had no users, which meant either we'd targeted the wrong workflow or the trigger to use it was unclear. Different signals, different responses. You can't see any of this in aggregate.
The thirty-day adoption playbook
Week one: identify the early adopters. Find the three people across the org who used each skill most in the first five days. They are the people who will spread the tool, write the internal example, and answer the questions you can't be in the room for. Compensate them — not financially, just with attention. Their feedback shapes week two.
Week two: produce one example per skill. A short doc, written by an early adopter, showing exactly what they used the agent for, what input they gave it, and what they got back. Real examples kill abstraction. The launch email said "this skill helps with weekly reporting." The week-two doc says "I used this skill on Tuesday to draft the leadership update; here's what I gave it; here's what came back; I edited two paragraphs and sent it." Most adoption is unlocked by that single shift.
Week three: pair the holdouts. Look at the per-person dashboard. Identify the people who haven't used a skill that would obviously help them. Pair them with the early adopter for thirty minutes. Not training; not a presentation; a working session on a real task. The holdouts who get over the first-use hump in this session will use the agent again. The ones who don't, won't — and you've learned something useful about that skill.
By week four, every shipped skill should have a clear answer: used by most of the target audience, used by some, or used by none. If a skill is at "none," do not double down. Either redesign it, retire it, or replace it. Sunk cost is the enemy of adoption — the agents you keep alive past their expiry date make the live ones look worse.
Why internal champions matter more than training
Formal AI training doesn't drive adoption. It checks a box. The thing that drives adoption is somebody on the team — not from IT, not from the rollout team — saying "I used the agent yesterday and it saved me forty minutes; here's exactly what I did." That's the message that converts. It's local, specific, recent, and unglamorous.
The job in the first thirty days is to manufacture and amplify those moments. Surface real wins in the channels people already read. Tag the early adopter so they're known as the person to ask. Build a small library of real examples. Adoption compounds when the social proof is internal and immediate. It stalls when the only voice talking about the tool is the rollout team's.
What success actually looks like
Three months in, the agents that are still running share four properties. They have at least one named champion per team. They've been used by more than half the target audience at least three times. They've absorbed at least one workflow change since launch — because someone surfaced a friction point and we fixed it. And nobody talks about them anymore. They're invisible. They're how the work gets done.
Shipping is the easy part. The hard part is the sixty days after launch, and most rollouts don't budget for them. If you don't plan the adoption phase before you ship, you're not shipping an agent. You're shipping a future ghost in your tool registry.
Most rollouts treat launch as the finish line. The teams that get adoption treat it as the starting line. We can help you sequence what happens next.
Start the conversation →