Coaching Agents Isn't Coaching People
A Field Guide entry in “AI-Native Ways of Working.”
A new model landed a while back and I handed it the work I was most stuck on and watched. It was good. The plans came back cleaner, the work needed less from me, and for a day or two it felt like the tooling had gotten out in front of me.
Then I turned it on my own setup and had it audit everything the other agents run on: the prompts, the instruction files, what context loads and when, how the projects are laid out. It rewrote a good part of it. Within a week my older models, the ones I'd been writing off, were doing better work too. Nothing about those models had changed; what changed was everything around them. The improvement I'd credited to the new model was better prompting, better context handling and cleaner structure, and every agent I run got the benefit.
I've never thought an agent needed praise; when something lands well I'll talk to it like a person I'm pleased with, but that's me enjoying the moment. What I got wrong was the accounting: I gave the agent credit that belonged to the system around it, and that error runs through everything I've been calling coaching.
Start with the part I'm most sure of: the moves are real. I spent years running them with teams: set expectations up front, respond to what someone produced instead of dictating how they produce it, widen their autonomy as they earn it. I'm using coaching broadly here, and some of what I did was really mentoring — the ICF and Lyssa Adkins' agile-coaching canon draw hard lines between teaching, mentoring, facilitating and coaching, and judging output sits on the mentoring side. They still carry over. I dispatch a new agent with tight expectations and me watching closely, and as it turns in good work I get out of the way. On my side of the loop, the skill is the same skill.
The trouble is on the other side. When I coach a person, the work lands on the person; they carry it into next week and keep changing when I'm not in the room. An agent keeps none of that. It takes the feedback instantly, with no ego and no history to work through, and then the session ends and it forgets I was ever there. Whatever I thought I was teaching it, I taught to a context window that got thrown away.
So the feedback has to land where it persists, because the agent won't. That's the setup: the instructions, the role, the project's memory, the checks. The version I hit most is git. Uncommitted changes in a worktree I'd stopped watching, a stale branch, a merge I found out about days later. It happens enough that I've stopped asking why the agent did it and started asking why the system let it. Then the fix is a rule, a hook, a line in an instruction file — something that makes the outcome I want the default, and it holds next session because it lives outside the agent. The thing I'm developing is the setup. The agent sits inside it and stays what it was when I found it.
Memory is the part of that setup I've put the most work into and understand the least. The agent retains nothing, so the role files and project memory I maintain do the job a person's growth would otherwise do: they're where last month's lesson lives if it lives at all. Keeping them honest is its own job and I'm not good at it yet. They go stale, they contradict each other, they accumulate until a cleanup removes something I wanted kept, and they grow until the context window can't hold them. The mechanics are a separate practice area. The growth I used to expect from a person, I now have to build by hand.
More of my old reflexes survived the move than I expected. Agile and lean transferred nearly intact, and so did DevOps, test-driven development and pipeline thinking. Intent-based leadership holds up: give an agent the outcome I want rather than the steps, and the work comes back better. Blameless postmortems hold up too — that git reflex is one. Psychological safety is the odd case: strictly speaking it doesn't apply, since nothing in there feels anything one way or the other. But everything it exists to produce is already there. Failure surfaces early because nothing has a reason to hide it, and nobody in the exchange is afraid of catching the blame. I don't have to build the conditions; I get them for free and have to remember they cost a person real work. Scrum did not work at all; sprints and ceremonies assume a team that persists from one to the next, and mine doesn't exist between sessions. I keep pulling things off that shelf to see which ones hold.
The anti-patterns
The failure modes here are all versions of forgetting which side of the loop actually changes.
- Coaching the model instead of the setup. Correcting the agent in the chat when the fix belongs in its instructions. It behaves for the rest of the session and reverts the next time, because the lesson went into a memory that gets wiped.
- Projected growth. Reading a better result as the agent maturing, when the only thing that moved was the guidance you handed it. You feel like a good coach; you were a good editor of your own instructions.
- The one-sided relationship. Trusting an agent more on the strength of history it doesn't share. You remember the last twenty sessions; it walks in a stranger every time, exactly as capable and exactly as unaware as the first.
- Encouraging the indifferent. Spending the warmth that actually moves people on a system that has no state for it to change. Mostly harmless, except that it's the tell you've slipped back into thinking there's someone in there.
Where improvement actually comes from
Nothing grows in an agent's gaps, so improvement only exists where I build it in. Three places, and I'll be straight about each.
The setup is the one I'm best at: repeated mistakes get fixed in instructions and checks rather than one more careful explanation. The harder skill is knowing when to stop talking. Writing is my clearest case — when the first passes don't sound like me, more notes in the same chat almost never get there. What works is closing it, distilling what I want into fresh instructions, and starting a new agent. It feels like quitting on someone, except there's no one to quit on.
The second place is me. Often I'm the part of this system that needs adjusting — how much I'm holding and at what pace, which is most of what the second essay was about — and I'm a harder client than any agent, because I'm the one with ego and history to work through.
The third is the working relationship itself, and here I'll correct something I'd have told you a month ago. There's no formal retrospective on my setup — nothing on a calendar. But something real happens continuously. I spend a lot of time working out with my agents why I heard about a thing and why I didn't, why the system let work drop, whether I'm too far inside the loop — the loop as a whole, not just the narrow rung I gave that name in the first essay — and what would make it easier on the human in it. It's all aimed at making the thing work better for whoever sits where I'm sitting, and I still don't have a good name for that seat. What I don't have is the deliberate version: time set aside to look backward and forward at the arrangement itself, not at whatever broke this week.
The instinct that cost me most is believing that a system with a feedback mechanism in it will improve itself. With people that's nearly true: give a team a retrospective and somewhere to write things down and improvement compounds without you. I built the agent version of that. Agents were supposed to write what they learned into a shared place and the next one to read it first. Some never wrote to it. Some didn't know it existed. Some read it and never updated it, so they inherited context that had stopped being true. The engagement journal is hit and miss, and the documentation drifts unless I maintain it. Several places where I wanted the thing to be self-learning and self-improving, and I couldn't quite pull it off. All of it still runs on me noticing.
One boundary: where senior judgment comes from, once agents do the formative work people used to learn on, is a real question and not this one. What I believe is that expertise moves to the front — experts put their judgment into designing and validating the system, so the work needs far less of it in the moment.
For leaders
This isn't a plan for rolling AI across a company, though the line isn't clean and some of it probably applies there. What matters is which conversation it belongs to. It isn't “we want to start using AI.” It's “we want to operationalize and govern AI the way we've operationalized everything else.” If that's your conversation, the question for whoever runs your agents isn't whether the agents are getting good — the agents aren't the part that improves. The setup and the person running it are. Ask what they've changed in their setup lately — which instructions they rewrote, which check they added — and what they've changed about how they work. Then ask whether anyone has looked at the whole arrangement, not just the last thing an agent produced. Someone whose only answer is that the agent seems smarter has credited the tool for their own editing, and that improvement stops the moment they stop making it. There are still people in this and they still need coaching through the change; what's different is where the rest of the coaching points.
I've wondered aloud whether coaching is really what's happening here, or whether I'd reached for a familiar word because the job is unfamiliar. It still fits, but it points at the setup and at my own habits now, the parts of this that can hold a lesson. The agent is the one part of the arrangement I've stopped expecting to grow. The old frame still tugs at me every time a run goes well, but the only notes that survive the night are the ones I wrote into the setup.
This is one pattern from a set I'm working through on human-agent teams. It comes out of my own hands-on R&D, not a production deployment.