Most honest accounts of agentic AI transformation come after the fact, once the outcome is known. This one is a dispatch from the middle. A large enterprise, hundreds of people, moving its engineering organization to an agentic way of working in waves: a first cohort, then a wider one, then everyone. It is not finished, and I am not going to pretend it is. But it is already far enough along to have taught me things a pilot never could, including where my own approach breaks.The odds are not flattering. Gartner expects more than 40% of agentic AI projects to be scrapped by 2027. Read the post-mortems and it is the same story every time: the models worked, the pilot demoed well, and the initiative still died. Not on the technology. On everything around it.Here is what holds up, and what surprised me.
Access is not capability
The first rollout is the easy 20%. Hand a team a coding agent and a set of prompts and you get activity: logins, a few assisted pull requests, a good demo. You do not get a team that ships differently by default. Those are separate outcomes, and only one of them survives a real quarter. McKinsey's 2025 State of AI has the macro version of the same gap: around 88% of enterprises use AI in at least one function, and close to two-thirds have not scaled past that first one.The measure that matters is not seat utilization. It is whether the team's delivery changes shape after the help leaves. If the only evidence is a usage dashboard, you bought licenses. Nobody changed how they work.
The transformation finds the teams that were already healthy
This is the finding I did not expect to be so stark. The strongest predictor of whether a team took to the agentic way of working was not seniority, or stack, or how loud they were in the kickoff. It was how self-sufficient the team already was before we arrived.Teams that already owned their backlog, made their own calls, and shipped without waiting to be told absorbed the new workflow fast and made it theirs. Teams used to being handed tasks struggled to even see the value. Agentic ways of working amplify a team's existing operating maturity. They do not manufacture it. The tooling made each team more of what it already was.That is a comfortable thing to learn about your best teams and an uncomfortable thing to learn about the rest.
The team that missed the train
At scale, teams do not move at the same speed, and "behind" does not stay put. It compounds.One team fell off the pace early. While the others were building, they were still catching up on the basics, and because everyone around them kept moving, the gap widened instead of closing. By the time we saw how far back they were, the problem had changed. It was no longer a skills gap. They had stopped seeing the point. A team that cannot see the value disengages, and a disengaged team is much harder to recover than a slow one.This is the ceiling of any fixed program run across a real organization: a uniform six-week arc meets teams that are not uniform. The arc assumes a floor of team health it cannot itself create. The teams below that floor do not get carried up by it. They get left further behind unless you catch them early and treat it as a different problem, not a slower version of the same one. If I were starting again, I would spend more effort up front finding the teams at risk of missing the train, and less energy assuming the schedule would carry everyone.
Say why, early, and keep saying it
The technical part of this work is the easy part. What decides whether it lands is communication. And it is the thing most engineering leaders underinvest in, because it reads as overhead.When you do not explain, early and more often than feels necessary, why the change is happening, what it means for a team, and what is expected of them, the silence fills with something worse. People assume the agents are there to replace them, or that this is one more initiative to wait out. Every rollout where the narrative ran ahead of the tooling went better than the ones where it lagged. There is no version of this that succeeds quietly.
The model, in one paragraph
The approach underneath all of this is deliberately unglamorous. Teams learn on their real backlog, not a sandbox, with the security and quality gates left on. Ownership transfers on a schedule: we lead, then we pair, then the team leads, then we coach on demand, with the outside help tapering by design so no one becomes load-bearing. Each wave inherits the prompts, skills, and blueprints the last one built, so capability compounds instead of resetting. Coaches are grown from the teams that just finished rather than rented again for the next. And the preparation - access, backlog selection, calendars - is settled up front, because that is what keeps the weeks you are paying for from draining into IT tickets. None of it is clever; it works because it is repeatable.
The point
Every hard problem in this program has been organizational, not technical. Which teams were ready. Who got left behind. Whether anyone said why. The models are already good enough for most of what an enterprise wants done. What decides the outcome is an operating model that fits the teams you have, moves ownership on purpose, and communicates faster than fear does.Run agentic adoption as a technology program and you land in the 40%. What survives the rollout is the version that treats it as organizational design, unevenness and all.I am still in the middle of this one. Ask me in a year how the team that missed the train ended up. That is what I care about most, and it is the thing no dashboard will answer.
