AI agents joined your team. Your improvement loop hasn't noticed.
AI agents create friction your retrospectives never see. This guide wires agent evidence into the improvement loop your team already runs.
This guide is about applying something teams already know, the continuous-improvement cycle, to something new: the work your team now does with AI agents. We build retrospective software, so this lens is the one we know best; the loop it describes works in whatever tools and ceremonies you already have.
Want the 10-minute version first? Start with the quick-start post, gather feedback from AI agents, then come back here for the full picture.
The oldest trick in teamwork
Every method your team uses to get better is a version of one loop: do the work, look at how it went, change something, check that the change helped. Deming taught it to manufacturing as Plan–Do–Check–Act; Toyota made it a culture and called it kaizen; software made it a ceremony. Norm Kerth’s Project Retrospectives (2001) popularized the retrospective for software teams, and the Agile Manifesto pinned it as a principle: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly” (principle 12). Blameless postmortems run the same loop for incidents; a media team’s campaign wash-up and a support team’s triage review run it without ever using the word “agile.”
The loop works because of one premise: work generates evidence about how work should change. Teams that harvest that evidence compound: each cycle makes the next one better. Teams that don’t, repeat themselves.
For seventy years, the evidence came from people. People noticed the friction, complained at lunch, raised it in the retro. The loop’s sensors were human.
A new kind of worker
Sometime in the last two years, your team started delegating real work to a new kind of worker. AI agents now write and review code, audit ad accounts, draft support replies, build reports, migrate content. And this worker has a strange profile: tireless, fast, capable — and context-starved. Rahul Garg’s framing has become the field’s shorthand: “AI assistants are like junior developers with infinite energy but zero context,” which is why “the time saved by AI-generated code is often consumed by the effort required to correct it” (Patterns for Reducing Friction in AI-Assisted Development).
That correction cost is friction, and agent work generates it constantly: the ambiguous brief that forced a guess, the doc that didn’t exist, the account structure that fights every session, the tool that timed out, the requirement that changed mid-task. Nothing about this is new — human work generates the same list. Two things about it are new.
The new worker doesn’t complain at lunch. An agent hits a wall, works around it, and moves on. It doesn’t get frustrated enough to raise the problem in Friday’s retro. The signal your improvement loop has always relied on (a person minding the friction until a ceremony collects it) doesn’t fire.
And the evidence evaporates. When the session ends, the friction’s context dies with it. Next session (next person, same agent) hits the same wall fresh. You can’t improve on evidence you never captured; the loop starves quietly while the work looks fine.
So here’s the situation, stated plainly: a growing share of your team’s work now produces improvement evidence that your improvement loop was never wired to collect.
The field noticed — and rebuilt the loop solo
The people closest to agent work saw this early, and by mid-2026 “capture agent friction and feed it back” is consensus practice under at least half a dozen names: Garg’s Feedback Flywheel, Every’s Compound Engineering, Osmani’s Loop Engineering, Thoughtworks’ sensor-instrumented harness engineering, the platform vendors’ fleet-scale memory loops (OpenAI’s “dreaming”, Factory Signals), and GitHub’s gh-aw, whose session-insights workflows already generate automated session-analysis reports. Even the vendors reach for the retro word: OpenAI’s Codex guidance reads “when Codex makes the same mistake twice, ask it for a retrospective and update AGENTS.md” (best practices).
These loops are good. If your team runs any of them, keep it; everything in this guide builds on them rather than replacing them. But notice two gaps.
First, the practice gap: watching isn’t improving. Around 90% of teams instrument their agent traces; only about 37–52% systematically evaluate what they capture (LangChain, Jun 2026). Most teams have the dashboard. Far fewer have the loop.
Second, the shape gap: nearly every loop in the field is solo. One practitioner tuning their personal playbook, one platform curating its fleet’s memory, one observability stack clustering its own traces. Seventy years of continuous improvement says the compounding happens at the team — where the aggregate view lives, where priorities get reweighted, where process and docs and budgets have owners. That layer is exactly the piece nobody has rebuilt. The reports exist; the room hasn’t been booked.
The anatomy of the loop
When your team decides to wire this up, the loop has more moving parts than it first appears. The journey a single piece of friction has to survive:
| Stage | The question |
|---|---|
| Hosting | Where does the agent run — and what does that make observable? |
| Detection | How is friction noticed? (Self-notice, a reviewing agent, telemetry, and human correction, which is still the dominant sensor: ~70% of silent failures are first caught by a person) |
| Instrumentation | What makes the agent record it? (Nobody logs friction they weren’t told to look for) |
| Recording | What does a useful record contain, and where does it live? |
| Harvesting | How do records from many sessions and many people come together? |
| Synthesis | Which patterns matter, and at what level does each fix belong? |
| Close the loop | Did the fix actually reduce the friction — or was it theatre? |
Three disciplines make the difference between a loop and a diary, and each gets its own chapter in this guide:
- Records, not vibes. A useful entry cites the moment, names one root cause from a small fixed vocabulary, and proposes a ticket-sized fix. Fixed labels are what let entries aggregate: “the docs were confusing” can’t be counted; eight
missing-documentationentries can. (Chapter: What a good friction record looks like) - The altitude question. Every recurring pattern gets fixed at some level: a memory note, a prompt, config, the docs, the work material itself, the process, or upstream with a vendor. Route the fix too low and it recurs for everyone else; too high and you bloat an artifact nobody reads. (Chapter: Where should the fix land?)
- Judgment in a room. Some friction is deliberate: the review gate someone chose as a control point (a recap of Ronacher’s AIE Europe talk: “friction is what’s necessary… to steer”; Thoughtworks now warns of the cognitive debt of over-frictionless agent work). Keep-or-kill, priorities, and cross-owner fixes are negotiations, not computations — they need the fix-owners in one conversation. (Chapter: The report exists. The room doesn’t.)
Where the story goes
Garg’s cadence list for the flywheel includes a line that is almost a dare: “an agenda item in the existing sprint retrospective: what worked with AI this sprint?” (martinfowler.com). That’s the thread this guide pulls. Not a new ceremony, not an AI-run one — the improvement loop your team already trusts, extended to cover the newest worker on it, with the agent as a participant: it brings the evidence, drafts the fixes, answers questions; the team keeps the judgment, because the fixes land in processes, documents, and budgets that people own and answer for.
And an honest floor to start from: if your team just adds the agenda item and talks (no log, no labels), that’s already better than silence, and for light agent use it may be enough. The rest of this guide is what you add when that conversation keeps repeating itself.
The chapters
- This page: why AI-assisted work needs the loop your team already runs.
- The map: agent feedback loops, tools, and approaches: the reference framework covering the friction lifecycle, the named loops the field has built, and the classification schemes in use. Start here if you think top-down.
- What a good friction record looks like: capture in the moment, the root-cause labels, the never-log rules.
- Where should the fix land? The altitude problem, and the routing table.
- The report exists. The room doesn’t. Why synthesis is a team ceremony, priced against its rivals.
- Running the AI collaboration retro: the facilitator’s guide, with the 15-minute agenda item, the template, and the prompt cards.
- Get started in ten minutes:
ai-session-retroandai-retro-brief, the capture and synthesis ends of the loop, ready to install.
Prefer the short form? Two companion posts on the blog: the quick start, gather feedback from AI agents, and the story of the first time we ran it ourselves, our AI teammates joined our retro.
We’d rather be argued with than agreed with politely — every chapter ends with what would change our minds.
The reference map for agent feedback loops: the seven-stage friction lifecycle, the field's named loops by level, and the classification schemes in use.
What a useful AI friction record contains (evidence, one root-cause label, a ticket-sized fix) so entries aggregate into fixes your team can act on.
Label each piece of agent friction with its root cause and it points at the altitude (memory, docs, process, or upstream) where the durable fix belongs.
AI agents now write their own friction reports. What's missing is the room: a recurring team ceremony that turns aggregated reports into owned fixes.
A facilitator's guide: agents capture session friction, a one-page brief aggregates it, and 15 retro minutes turn it into owned, routed fixes.
Install the free ai-session-retro and ai-retro-brief skills, make the trigger deterministic, and take your first AI retro brief to the team.