In April I wrote about what it means to be a coach in an organization actively adopting AI. I talked about shallow coaching becoming obsolete. I named three competencies I thought coaches would need to thrive: systems thinking, data literacy, and AI fluency. I meant it all. I still do.
What I got wrong was the timeline. I was writing as though we had years. We have months.
Watching the pace of change up close will do that to your assumptions.
The thing that shifted
When I wrote the April post, I was thinking about AI augmented tools that coaches adopt as part of their practice. Tools that handle the administrative layer, surface data faster, draft the summaries nobody wants to write. Augmentation. The coach stays largely intact, just better equipped.
What I didn’t fully reckon with is the speed in which agentic AI is moving. The monitoring and facilitation layer is not adjacent to coaching. It is a core part of how coaching has always been delivered. I knew that. What I underestimated is how quickly that layer is moving into the agentic stack and how little runway that leaves for coaches who haven’t started adapting.
Velocity as a metric is already losing its relevance. The ceremonies that exist largely to create visibility and surface impediments start to look like redundant infrastructure when an automated pipeline is already tracking the same signals in real time. The daily standup, the burndown review, the manual impediment log. These aren’t going away because people stopped caring about them. They’re going away because something else is doing that job continuously and without the overhead.
The moment it clicked
A product owner came to me with a question I hadn’t heard before. He wanted to know whether his engineers were writing acceptance criteria that reflected product thinking or purely technical thinking. Outcome-driven inputs versus spec-and-contract-driven inputs. He could feel that something was off but couldn’t point to where.
That question stopped me cold. Not because it was hard to answer, but because of what answering it would require.
The agentic answer was to define what good looks like, encode that definition into something that could watch continuously, and surface the signal before it became a delivery problem. Not after the sprint. Not in the retrospective. Before a single line of code was written. And here’s what struck me about that: in solving the PO’s question, I wasn’t just coaching. I was building. Adding another instrument to the detection layer that the enablement role owns and maintains.
Here’s what that means for coaches. The value I brought to that conversation wasn’t my availability. It was my accumulated pattern recognition. Thirteen years of watching what happens when acceptance criteria skews too far toward technical contracts and not far enough toward user outcomes. I knew what the failure mode looked like. I knew what the early signals were. The question in front of me wasn’t how do I coach my coaches through the problem. It was how do we encode what we know so that the problem gets caught before it becomes one.
That sits outside the traditional wheelhouse of what coaches have ever been asked to do.
What this means for the role
I want to be careful here because I’m not arguing that coaches are obsolete. I’m arguing the opposite, with a significant caveat.
There will always be people. And wherever there are people, there will be relationships, conflict, misalignment, the need for someone who can sit in the tension of a hard conversation and know when to push and when to hold the space. No amount of agentic execution touches that. The irreducibly human layer of this work isn’t going anywhere.
But the competency stack is changing in ways that most coaches aren’t prepared for. The monitoring work is automating. The facilitation scaffolding is thinning. What’s left, and what’s becoming more important not less, is the ability to design the systems that do the monitoring, to encode your knowledge into detection logic, and to maintain and refine that logic as the organization evolves.
Some models being pitched right now suggest the answer is to replace coaches with middle management. More coordination overhead, more process governance. I think that gets it exactly backwards, and I’ve seen the evidence firsthand. When technical depth migrates out of delivery teams and into management layers, the input quality at the top of the agentic stack degrades. Go look at your PR comments. If you’re seeing feedback that should have surfaced in refinement, you don’t have a code quality problem. You have an input quality problem. And no amount of management overhead fixes that.
The coaches who will remain valuable in this environment are the ones who evolve into something closer to flow enablers. People who develop the dual fluency across teams, outcome thinking and technical constraint thinking, who maintain the detection logic that catches problems upstream, and who do the human coordination work that keeps smaller, faster teams functioning without the scaffolding that used to hold everything together.
That’s a more sophisticated role than what most of us signed up for. It’s also a more durable one.
What’s coming
I have a lot more to say about each of these threads, and I’m going to work through them deliberately over the coming weeks.
The input quality problem and why refinement is now the highest leverage point in the entire delivery system. What the right team composition looks like when the execution layer is automated. What the coach to flow enabler evolution actually requires in practice. How you encode practitioner knowledge into a system that can act on it. And the organizational change question of how you bring leadership along through all of it, which is its own challenge entirely.
These aren’t separate topics. They’re connected pieces of the same shift, and I think they’re worth working through carefully rather than collapsing into a single take.
More soon. If any of this is resonating with what you’re seeing in your own organization, I’d genuinely like to hear it
