The report exists. The room doesn't.

Recently, an AI agent filed six items on our own retro board.

The first one read: “Start verifying before acting — agent execution error is 38% of friction (2× the next cause); the recurring cost is asserting a cause, pushing, or retargeting before checking live code, data, or branch state.” Behind it sat the pattern evidence: git/branch-state errors under concurrent-agent work across eight sessions and two repos; partial pre-push checks that broke CI in four sessions, twice in one repo on the same day; a test-mocking gap that a session had flagged the day before, with the note that the fix doc was never written.

Two things about that board are worth staring at. First, no single work session would have ranked any of this as its top problem: each instance was a shrug, a few lost minutes, an annoyance someone worked around. The ranking only exists in aggregate, across sessions and people. Second, and more uncomfortable: the most damning items weren’t about the agent or the code at all. They were about us — fixes we’d agreed to and not adopted, the same stall recurring with “no standing fix shipped between them.”

An automated report can tell you all of this. What it can’t do is get the people who own the process, the docs, the tooling budget, and the priorities to sit down and decide what to do about it. The report exists. The room doesn’t. This paper is about the room.

Everyone built the loop

By mid-2026, “capture what went wrong in AI-assisted work and feed it back” is consensus practice. It exists under at least six names, and they’re all good. Rahul Garg’s Feedback Flywheel harvests session friction into priming docs and guardrails. Every’s Compound Engineering makes each unit of work teach the next. Thoughtworks instruments agents with sensors; Addy Osmani calls the discipline Loop Engineering. The platform vendors close the loop at fleet scale: OpenAI’s memory “dreaming”, Anthropic’s context curation, Factory Signals auto-filing tickets. GitHub’s open-source gh-aw, a framework for agentic workflows written in natural-language markdown, goes furthest toward our subject: its session-insights workflows already generate automated session-analysis reports. One public example, a single day’s automated analysis of 50 sessions, flags a 24% skip rate and a 33% executor-success rate as “Failure Signals.”

If you use any of these: keep using them. This paper proposes replacing none of them. But sort the loops by the level they run at and read the pattern:

One practitioner’s playbook. One session’s config. One platform’s memory. One observability stack. One vendor’s fleet.

Nearly every loop in the field is a solo cycle: a person and their agent, or a vendor and its fleet. Garg’s flywheel is the one design that reaches for shared team artifacts, and his cadence list includes a line almost nobody has operationalized: “At the retrospective: an agenda item in the existing sprint retrospective: what worked with AI this sprint?” He names the venue and moves on. GitHub’s dogfooding, meanwhile, produces exactly the friction report a team ceremony would want as its input, and positions it as engineering observability, full stop.

The nearest thing to an exception comes from Scrum.org, whose hybrid-team series includes How to Run the Sprint Retrospective When Half of Your Team is AI Agents. It’s worth reading, because it takes the venue question seriously and answers it differently than we do: their retro becomes a data-driven debugging session over agent metrics (prompt-rewrite frequency, deviation rates, token burn). That’s a useful lens, and a team could run both. But it reviews the agents; the loop this paper is about reviews the collaboration: causes rather than symptoms, fixes routed to whatever level they belong (the brief, the docs, the process, the material), with the agents contributing their own account of the work rather than appearing as a dashboard.

The gap isn’t technology. Every piece (capture, aggregation, reporting) ships today. The gap is a practice: almost nobody has said what the team does, together, when the report arrives.

What actually needs a room

The instinct here is to automate harder: better clustering, auto-filed fixes, a dashboard. For a large class of findings that’s correct, and the pipelines above do it well. But list the decisions the report actually raises and notice their shape:

• Keep or kill. Which recurring friction is waste, and which is deliberate control? The review gate that slows the agent down might be the leash someone chose (a recap of Armin Ronacher’s AIE Europe talk: “friction is what’s necessary… to steer”); Thoughtworks’ Radar now warns about the cognitive debt of removing too much. Deleting a control point changes everyone’s risk. That’s a team decision by definition.
• Where the fix lands. A recurring friction pattern gets fixed at some altitude: a personal note, a prompt or skill, environment config, the docs, the work material itself, the process, or upstream with a vendor. Those artifacts have owners, and the owners are different people.
• Priority under aggregation. Five shrugged-off minutes per person per session is invisible to each person and a top team cost in the sum. Acting on it (rewrite the shared template, change the intake process, escalate to the vendor) takes a decision ceiling no individual has.
• The adoption check. Did last cycle’s fix actually get adopted, and did the friction stop? Our own board’s most valuable line was exactly this: flagged yesterday, never written. A loop without this check is a flywheel spinning in the air.

None of these is a computation. All of them are negotiations between people who own different pieces of how the team works. Solo practitioners legitimately fold these calls in by feel; fleet pipelines legitimately make the machine-legible subset at machine speed. The team-scale versions need people in a room with shared vocabulary and the authority to reallocate attention. That’s not a pipeline. That’s a ceremony.

Why the retro — or your ceremony of equivalent shape

Full disclosure before the argument: we sell retrospective software. That’s precisely why this section argues from properties rather than from the brand: discount our conclusion accordingly and check the properties yourself.

The properties the decision set needs: a venue that is recurring (chronic minor friction never triggers an episodic meeting), blameless by norm, cross-owner (the people who own process, docs, tooling, and priorities are present), and evidence-fed. For most teams, the sprint retrospective is where those four properties already live: no new meeting to defend in a calendar war, and a blameless convention that matters more than it looks, because the tempting failure mode here is the agent-blame postmortem, and the harness-engineering school explicitly rejects that default: the engineer blames the model and files it under “wait for the next version”; fix the harness instead (Osmani, Agent Harness Engineering).

But the honest form of the claim prices the rivals rather than declaring a winner:

• Sprint planning has the most authority in the room, but its agenda is forward-looking and chronically full; retrospective triage in a planning slot reliably starves. Planning is where accepted actions get scheduled, not where patterns get read.
• The blameless postmortem has exactly the right norms and the wrong trigger: it convenes for the big episodic failure, never for the five-minutes-eight-people-every-sprint pattern, which is precisely the pattern only aggregation can see.
• Async — a report plus a tracker is the cheapest venue and, for the routine majority of items, enough. What it can’t do is the judgment set: keep-or-kill is a negotiation, altitude disputes cross ownership lines, and reprioritizing needs the owners in the same conversation.
• The null alternative — just talk about AI in the retro, no records, no labels is free, fits today, and for a small team with light agent use may genuinely be enough. Start there. What it can’t produce is comparability across sessions, trends, or the adoption check: a conversation that starts from zero every time. The practice below is what you add when that conversation keeps repeating itself.

So the claim, honestly sized: the retro — or your existing ceremony of equivalent shape. A media team’s monthly campaign review and a support team’s triage review are the same ceremony wearing different names, and nothing in this practice assumes code: the friction log of a tangled ads account or an inconsistent template library reads exactly like the friction log of a legacy repo.

The agent in the room — participant, never facilitator

If the evidence comes from agents, should the agent run the item? No, and not primarily for the reason you’d guess.

The reason that decays: today’s models are unreliable at exactly this kind of judgment: LLM verdicts flip on identical inputs ~13.6% of the time, and in one eight-week production study ~70% of silent agent failures were first caught by a person, not by tests or monitoring. True today; models improve.

The reason that doesn’t decay: facilitation and adjudication allocate a team’s attention and change artifacts the team owns and answers for. That authority doesn’t transfer to the most capable model in the room, any more than it transfers to the most capable engineer in the room. It’s an organizational fact, not a capability gap.

So the agent participates the way the best-informed contributor does. It brings evidence: its session records, labeled and cost-noted. It answers questions: “what did you actually try before the workaround?” has a transcript-backed answer. It drafts, never decides: proposed fixes arrive with suggested altitudes; the room amends, reprioritizes, or kills them. And it takes accepted actions back (the doc edit, the config change), executing them after the ceremony under ordinary review. Research practice has a name for this division: in the ACE framework the agent is the Reflector and a Curator consolidates what enters the playbook. We make one deliberate adaptation: in ACE the curator is a deterministic component; here the curators are the team.

One asymmetry is load-bearing. Everything the agent brings into the room should be ungated — an agent that needs permission to report friction under-reports. Everything that leaves the room into what agents later rely on (memory, context files, config) goes through ordinary review, because that write-path is a recognized poisoning-and-drift surface (OWASP Agentic Top 10, ASI06). The ceremony sits exactly at that boundary: ungated evidence in, gated writes out.

The fifteen minutes

What we’re actually proposing a team try, this sprint, with every loop it already runs intact:

1. Per session, the agent writes a short retrospective entry of its own work: what went well, each friction item with a root-cause label and what it cost, a proposed ticket-sized fix and the altitude it targets. Committed with the work, ungated.
2. Before the retro, the entries since last time are synthesized into a one-page brief: recurring themes with prevalence, which root-cause group dominates, whether past fixes were adopted, top-3 recommended actions. The brief feeds the conversation; it doesn’t replace it.
3. In the retro (an agenda item, not a new meeting): fifteen minutes on “what worked with AI this cycle, and what kept hurting?” The humans triage: keep or kill, confirm or re-route the altitudes, assign owners to the top three.
4. Next cycle, the brief’s adoption check reports whether the friction actually dropped. That check is what turns the report into a loop — it’s also where our own board caught us.

Failure modes, named so you can defend against them: retro theatre (the ceremony you run for the audience: brief read, heads nod, nothing decided; the top-3-with-owners rule exists for this); agent-blame (treating “the agent erred” as the explanation rather than the residual; most failures trace to the harness and the inputs, not model reasoning); wishlist sprawl (twenty actions, no owners); and the loop never closing (the follow-through void: fixes land, nobody checks the trend). We’ve written a whole field guide to how ceremonies fail; every mode in it applies here too.

What we’re not claiming

Not a replacement for any vendor loop: their outputs are this ceremony’s inputs. Not a new meeting. Not an AI-run ceremony; from a company whose product is retrospectives, the guardrail is deliberate. Not necessary for a solo practitioner, whose loops close fine by feel. And not friction-zero as the goal: some friction is the control surface, and the agenda item exists to choose, not to eliminate on sight.

What would change our minds

This is a discussion paper, so here is the falsifiable part. If the vendor loops grow genuine cross-tool, cross-person judgment, not just fleet-wide memory writes, the room shrinks to an audit function. If teams that run the brief-only async version show the same friction-reduction trend as teams that run the agenda item, the fifteen minutes is theatre and we’ll say so. And our own labeled-vocabulary claim rests on an inter-rater reliability experiment we are currently running on real entries rather than asserting in advance. We’d rather publish the numbers than the confidence.

If your team runs any version of this (the agenda item, the async brief, or a ceremony we haven’t thought of), we want to hear what happened: ai-discussion@teamretro.com.

---

Next chapter: Running the AI collaboration retro — the facilitator’s guide to the fifteen minutes: the template, the entry format, and the prompt cards. Part of the AI agent retrospectives guide.