I wrote these notes in July 2026, partway through an agentic AI rollout at a large enterprise. Hundreds of people were moving to a different way of working, in waves: a first cohort, then a wider one, with the rest of the engineering organization to follow. The program was still under way. I had already learned things that a pilot had not shown me, including where my own approach needed to change.
The wider evidence gives some context. In June 2025, Gartner forecast that more than 40% of agentic AI projects would be canceled by the end of 2027, citing rising costs, unclear business value and inadequate risk controls. That is a forecast, not a finding about this program. In our case, the difficulties that stayed with me were largely about how teams worked and how we supported them.
What access tells you
Giving a team a coding agent and a set of prompts produces activity fairly quickly: logins, assisted pull requests and something to demonstrate. It takes longer to find out whether that changes the team’s everyday delivery.
McKinsey’s 2025 State of AI survey describes a similar gap. Eighty-eight percent of respondents reported regular AI use in at least one business function, while roughly a third said their organization had begun scaling its AI programs. Use in a function and adoption across an enterprise are different measures.
For this rollout, I wanted to know whether teams kept using the new practices after the initial support tapered off. A usage dashboard could tell us whether people opened the tool. We also needed to look at how they planned, reviewed and delivered their work.
Teams started from different places
I had not expected a team’s existing independence to matter quite so much. In the teams I observed, it was a better guide to adoption than seniority or technology stack.
Teams that already owned their backlog and made their own delivery decisions tended to make the new workflow their own. Teams more accustomed to receiving individual tasks had a harder time finding a use for it. They needed help with how they organized work as well as with the agents.
It was encouraging to watch the first group progress. It was also uncomfortable to realize how much our approach assumed about the second.
The team that fell behind
One team lost pace early. While others were building, they were still catching up on the basics. The gap widened as the program continued. By the time we understood how far behind they were, they had also started to lose interest in the work.
That changed what they needed from us. More time with the same material would not necessarily restore their confidence or help them see the value. We needed to understand why the approach was not making sense for that team.
A fixed six-week program assumes a degree of readiness that teams do not all share. If I were starting again, I would spend more time identifying who might struggle before the first wave began. I would also make room to adapt the support when a team needed a different starting point. I put too much faith in the schedule carrying everyone along.
Explain the change before people have to interpret it
Communication needed more attention than the technical rollout. People wanted to know why we were doing this, what it would mean for their work and what we expected of them.
When those questions went unanswered, some assumed the agents were there to replace them. Others treated it as another initiative to wait out. I found that the work went better where we explained the change before introducing the tools and kept discussing it as people tried them.
That included listening to concerns after the kickoff. An explanation that made sense in a presentation did not necessarily answer the questions a team had once it started working differently.
How the program worked
Teams learned on their real backlog, with the usual security and quality checks in place. We prepared access, selected suitable work and booked the time before each wave started. Otherwise, the weeks intended for learning could disappear into setup and scheduling problems.
Responsibility moved gradually. We led first, then worked alongside the team, then let the team lead with coaching available when needed. The aim was for people to become comfortable with the work while support was still close enough to use.
Each wave inherited the prompts, skills and blueprints developed by earlier teams. People who had completed the program became coaches for those following them. That gave teams practical experience to draw on from colleagues who had recently faced similar questions.
What I would watch more closely
The organizational questions took much of my attention: whether a team was ready, who was falling behind and whether we had explained enough. The program worked better when the support reflected the teams we had, rather than the teams assumed by the schedule.
At the time of writing, I did not know how the team that fell behind would end up. I cared about that more than another successful demo. Their experience would tell me something important about where our approach needed to change.