AI Adoption Was the Easy Part

Published August 13, 2026

A Field Guide entry in “AI-Native Ways of Working.”

I'm not trying to convince anyone to use AI. That isn't the right conversation, and I'm assuming it's a done deal.

In most organizations I talk to, adoption already happened and nobody ran it. People started using these tools before anyone sanctioned them, plenty of them were excited to, and it spread on its own. I've spent eighteen years helping organizations through changes they resisted — agile inside a regulated brokerage, DevOps across a compliance and legal portfolio, a tooling migration across a 500-engineer product org. All of it took months of pushing. This one pulls, and I've never run a change I didn't have to sell first.

So adoption was the easy part. Adopting AI sits about where automated testing sits in DevOps: a real step, and a small one, several levels below the organization that trusts its pipeline enough to deploy unattended. But the pull has a consequence I don't see anyone planning for: the risk stops sitting where you were trained to look for it. It moves from the people who won't start to the people who won't wait, and a communication plan has no purchase on them.

The discipline that does the governing is the one we already have — Kotter's eight steps for driving change from the top, Jason Little's Lean Change for running it as small experiments, none of it expired. The root I carry forward is the DevOps one: the question isn't why a person did something, it's why the system allowed it and how we improve the system. We used to say manage the system, not the people. What I'd say now is manage the system to manage the agents.

Nobody manages a fleet of agents directly. You manage the system they run inside — and that system is the only thing in the building running at the speed of the people out in front, which is why the governing has to happen there and not in a deck.

The risk moved to the other tail

Every change playbook I have ever used is engineered to move the resistant tail. Rogers' diffusion curve sorts people by how long they take to come around. ADKAR walks an individual from unaware to able. Kotter's coalition exists to overcome the organization's inertia. It's the same shape of problem every time: the change is worth making, some people won't move, and the job is to move them.

This is the first change I've run where the people who worry me are my best people. I've started calling them the sprinters. They're doing real work, faster than anyone can review it, sometimes in places nobody has decided are safe. Some of them need watching, some need slowing down, and a few are heading into trouble they can't see yet — not because they're careless, but because no review loop is running at their pace. Nothing in the change literature I've carried for most of my career has a chapter about them. All of it points at the other end of the curve.

Leave the sprinters alone and you get the outcome I'd put in front of an executive: in a large organization you can't let a few people leave everyone else behind, because past a certain point you're running two companies inside one org. One works at agent speed, with its own tools and its own definition of done. One works at the old cadence with the old one. Neither can review the other's output. And the fast company is generating the artifacts the slow one will inherit and maintain.

You don't have to hunt for them. I wrote a while back that shadow AI is a leadership signal and not a violation; what I'd add now is that shadow usage is the sprinter map. Every person using an unsanctioned tool is telling you where your fast tail actually sits. They already raised their hands — just not through your intake process.

A communication plan cannot touch that. Communication plans exist to move belief, and the sprinters already believe.

The number nobody could verify

In July of last year, Commonwealth Bank of Australia made 45 customer-service roles redundant, on the grounds that a new generative-AI voice bot had cut call volumes by around two thousand calls a week. The Finance Sector Union said volumes were actually rising and remaining staff were covering overtime, and took it to the Fair Work Commission. Before the hearing the bank rescinded the redundancies and put its reasoning in writing: its assessment “did not adequately consider all relevant business considerations.”

That case gets told as a candor failure. It's a visibility failure. An organization made an irreversible decision about 45 people's jobs on a number about its own AI that it could not verify — and the people who could contradict the number were the ones doing the work. When you can't see what your AI is actually producing, the number that fills the gap is the one somebody wanted to be true. What the reversal couldn't undo is what everyone still working there learned about how the AI numbers get used.

Forty-five roles is a small case, and one bank might not prove much. Klarna is the bigger one. It claimed its AI assistant was doing the work of seven hundred customer-service agents; within about a year it was hiring humans again, and its CEO admitted publicly that the cost-cutting had produced lower-quality service. The number Klarna acted on had the same problem the bank's number had: nobody had checked it against the work.

The substrate is where the practice lives

You can't build on the model. Models change, get deprecated, and shift what they're good at, so anything attached directly to one is provisional. That gets filed as tool churn and left there as an overhead complaint. It's actually the argument for the substrate: because the thing underneath keeps moving, the durable layer has to be the one you own around it.

That layer is where the practice goes, and the clearest instance of it is the agents.md file — the instruction file an agent loads before it does anything. Your working practice either lives in files like that one, in a form an agent reads on every run, or it lives in what people are asked to remember. Only one of those runs at the speed of the fast tail, because only one of them is what the fast tail runs on.

When the practice lives in memory instead, here's what it costs. Expensive models do work a cheap one would have done, and it presents as a spending problem, so the fix gets aimed at people — a memo about being mindful. Nothing in the system encodes which class of work draws which model, so every request takes the biggest one available. You can't memo your way out of that. It's a missing line in a file.

A generic change consultant will help you write a communication plan. They will not open an agents.md file, and that file is where your working practice now lives.

What argues against this

The strongest case against all of it: for most organizations, resistance is still where the money bleeds. Plenty of places have a few enthusiasts and a large middle that has never opened the tool, and there the fast tail is a rounding error. And the people who say governance belongs in policy rather than in config have a real argument — policy is durable and auditable, and it doesn't rot the way a set of files rots when nobody tends it. A lot of organizations have governed their AI risk through policy and procurement alone and haven't been burned yet.

I still hold the thesis. “Not burned yet” is a claim about elapsed time, not about controls, and policy governs what people are permitted to do while a growing share of the work is now done by agents at a rate no policy review reads at. I'd rather have both. If I could only put the practice in one place, I'd put it where the work runs.

For leaders

Three questions will tell you where you stand.

What breaks if your primary model disappears tomorrow? If the answer is everything, you bought a subscription instead of building a system.

Where is the unsanctioned use in your organization, and who's doing it? If nobody can answer, you don't have a picture of your adoption. You have a picture of your procurement, and you don't know where your fast tail is.

Then the uncomfortable one: show me what our agents did last week, and what they'll do differently next week. The first half tests whether anyone can see the work; the second tests whether an improvement loop exists. Plenty of organizations can answer the first with a dashboard. The second is where the theater runs out, because somebody has to have looked at last week's output and changed something.

Adoption took care of itself in most places. What comes after it has to be led, and the place I'd start is finding out what our people are already doing without us.

This is one pattern from a set I'm working through on human-agent teams. It draws on my own hands-on R&D rather than a production deployment, and on eighteen years of leading organizational change before that.

Back to Field Notes