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.

shrug shrug shrug shrug team board #1 a top team cost one shrug each; a top cost together
Solo, each friction note is too small to be worth fixing. Aggregated on the team’s board, the same notes stack into one of its largest costs: the reweighting only the team layer can see.

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:

StageThe question
HostingWhere does the agent run — and what does that make observable?
DetectionHow 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)
InstrumentationWhat makes the agent record it? (Nobody logs friction they weren’t told to look for)
RecordingWhat does a useful record contain, and where does it live?
HarvestingHow do records from many sessions and many people come together?
SynthesisWhich patterns matter, and at what level does each fix belong?
Close the loopDid 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-documentation entries 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

  1. This page: why AI-assisted work needs the loop your team already runs.
  2. 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.
  3. What a good friction record looks like: capture in the moment, the root-cause labels, the never-log rules.
  4. Where should the fix land? The altitude problem, and the routing table.
  5. The report exists. The room doesn’t. Why synthesis is a team ceremony, priced against its rivals.
  6. Running the AI collaboration retro: the facilitator’s guide, with the 15-minute agenda item, the template, and the prompt cards.
  7. Get started in ten minutes: ai-session-retro and ai-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.