Running the AI collaboration retro

At TeamRetro we’re interested in every continuous-improvement cycle a team runs. AI-assisted work is a new area we’ve been thinking through via our retrospective lens; this guide shares where we’ve landed so far. Take it, adapt it, run it in whatever tool or ceremony you already have.

Part 1 — the guide

Why this belongs in a team ceremony

Somewhere on your team this month, an AI assistant spent forty minutes auditing a “broken” ad campaign that had been deliberately paused, because the brief didn’t say so. The person running the session corrected it, shrugged, and moved on. If four colleagues hit versions of the same gap, that’s hours of silent waste per month — and nobody knows, because each person absorbed it alone.

That’s the pattern with AI-session friction: it’s chronic and minor, so it never triggers a postmortem, and it’s ephemeral, so it evaporates when the session ends. Most teams can already watch it (around 90% instrument their agent traces), but far fewer turn it into fixes: only about 37–52% systematically evaluate what they capture (LangChain, Jun 2026).

The improvement loops that do exist are good, and this practice builds on all of them: AGENTS.md and context-file updates, memory systems, vendor self-improvement pipelines, error analysis on traces (Husain & Shankar, evals FAQ). 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). But nearly all of these loops are solo: one person and their agent, or one platform and its fleet. What the team layer adds is aggregation: friction that’s five shrugged-off minutes per person becomes a top team cost only in the aggregate view — and acting on it (rewrite the shared template, change the intake process, buy the tool) needs a decision ceiling no individual has. Rahul Garg’s Feedback Flywheel names the venue, “an agenda item in the existing sprint retrospective: what worked with AI this sprint?” (martinfowler.com), and this guide is one way to run it.

One honest concession up front: what this needs is a recurring, blameless, evidence-fed ceremony with the fix-owners in the room. For most teams that’s the retro, but a sprint planning slot, a monthly ops review, or a media team’s account review can host it just as well. The retro, or your existing ceremony of equivalent shape.

Worth knowing as a facilitator: Scrum.org approaches the same territory from the metrics side; their guide to running the sprint retrospective when half your team is AI agents reframes the event as a data-driven review of agent performance (prompt rewrites, deviation rates, token burn). This guide takes the complementary path: root causes and fixes across the whole collaboration, with the agents contributing their own account of the work, filed via the TeamRetro MCP server if you use TeamRetro. Teams with heavy agent fleets may want elements of both.

How the practice works, end to end

1. Capture, per session. At the end of each substantial AI-assisted session, the agent writes a short structured entry: what went well, what dragged (each item labeled with a root cause and a proposed fix), what it guessed, and the single highest-leverage fix. One file per entry, in a shared log.
2. Synthesize, after ~5 entries. Before the ceremony, the agent condenses the log into a one-page brief: recurring themes ranked by frequency × cost, a root-cause distribution, a check on whether past fixes were adopted, and the top three recommended actions.
3. Decide, in 15 minutes. The brief is one agenda item in your existing retro, not a new meeting. The team triages: keep or kill each friction, confirm where each fix should land, assign owners to the top actions. Next cycle’s brief reports whether the friction actually dropped.

The capture and synthesis steps are implemented as open-source agent skills in our teamretro-skills repo if you want a running start.

The agent reports ungated: an agent that needs permission to record friction under-reports, and human corrections after the fact are additive signal, not a checkpoint the loop waits on. Judgment stays with the team, and not as a courtesy: the fixes land in budgets, documents, processes, and tools that people own and answer for. The agent brings evidence and drafts; the room decides.

What a good entry looks like

Here’s a real-shaped example, deliberately not a coding session:

# 2026-07-16 — Monthly ads account review

**Session size:** ~25 turns, 1 deliverable
**Outcome:** shipped

## Went well
- Exec summary shipped in one pass; the account structure doc from last month held up

## Friction
- **[missing-context]** The brief didn't say the French campaigns were deliberately
  paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
  → Fix (altitude: process): add campaign-status flags to the monthly brief template

## Guesses made
- Assumed the target CPA unchanged from June — unverified

## Do this first
Campaign-status flags in the brief template — kills the largest single time sink this month.

Notice the discipline. Every friction item cites a moment and a cost (soft estimates marked (est.)), carries exactly one root-cause label from a small fixed vocabulary (labels like ambiguous-instruction, missing-context, missing-documentation, missing-access-or-tool, agent-error, or work-material-friction, where the material itself was the drag: a tangled campaign structure, a legacy spreadsheet, a module nobody wants to touch — always with the concrete material named), and ends with a ticket-sized fix that names its altitude: does this fix belong in a private memory note, a procedure, the environment, the docs, the work material itself, the process, or upstream with a vendor? Fixed labels are what make entries comparable across people and sessions; “the docs were confusing” can’t be aggregated, but eight missing-documentation entries can. Vague is the failure mode; “nothing notable” is a valid entry.

A good brief is one page: themes with prevalence (“4 of 9 sessions”) and dated examples, a plain statement of which root-cause group dominates (briefing, documentation, work material, tooling, or agent; that’s where the team’s attention should go), the adoption check on past suggestions, and three owner-assignable actions. It feeds the conversation; it doesn’t replace it.

Scope: one log per review scope

Keep one log per review scope: the boundary where fixes would land. For dev work that’s usually the repo, because its docs, config, and conventions live there. For non-code work it’s the ads account, the support inbox, the client engagement; the log lives in that workspace’s document home. An entry filed outside its scope is one the eventual fix-owner never finds. The schema stays identical everywhere; the schema, not the storage, is what makes entries aggregate.

The never-log rules

Entries are committed, shared, and outlive their context, so some things never go in one: secrets, credentials, or keys in any form; customer data or personal information; unreleased business figures; and, most important for retro culture, names, roles, or anything that identifies a person. Describe the gap and what it cost, never who caused it: “the brief left the audience open,” not “X’s brief.” Friction items critique inputs and systems, not people. If a scope’s friction can’t be described without sensitive context, keep those entries private and share only the aggregated brief.

Part 2 — the “AI Collaboration Retro” template

A ready-to-use format: five prompts, grounded in the entry schema, runnable in TeamRetro or on any whiteboard:

Column	Prompt	One-liner
Went well	What did AI-assisted work make faster or better this cycle?	Evidence-cited wins only: what to protect and repeat, not praise-padding.
Friction, with the cause	Where did it drag, and which root cause was it?	Each card names the moment, the rough cost, and one label from the team’s fixed vocabulary.
Guesses we let stand	What did the agent (or we) assume without enough information?	Latent friction that hasn’t hurt yet; flag anything still unverified.
Keep or kill	Which of these frictions did we choose on purpose?	Review gates and approval steps can be deliberate control points (recap of Ronacher’s AIE Europe talk); removing one is a team decision.
Do this first	Of everything here, which one fix pays off most, and at what altitude?	Top three max, each with an owner and the level it lands at: docs, environment, process, material, or upstream.

Part 3 — facilitator prompt cards

Questions to ask when a team brings an AI-retro brief to the ceremony. One per card; use the ones the conversation needs.

1. “Which session is this from, and what did it cost?” Pattern claims need dated evidence; a card without a moment and a cost can’t be triaged.
2. “Is this friction a control point we chose?” Keep-or-kill first: some friction is the steering (recap of Ronacher’s AIE Europe talk), and frictionless isn’t free; Thoughtworks warns of the cognitive debt it accrues (announcement).
3. “We suggested this fix last time. What stopped it?” Unadopted repeat suggestions are the highest-signal item in any brief; without this question the flywheel is theatre.
4. “This cost each of you ten minutes — what does it cost the team per month?” Aggregation is the team layer’s whole edge; ask it whenever a card gets shrugged at.
5. “Does this fix belong in the docs, the environment, or how we brief the work?” The altitude question. Under-target and the friction recurs; over-target and you bloat the wrong artifact.
6. “Who owns the artifact this fix lands in?” An action without an owner is a wishlist item. If the owner isn’t in the room, that’s a finding too.
7. “Before we call this the agent’s error, were its inputs adequate?” agent-error is the residual label, not the default; the default worth rejecting is blaming the agent when the harness or the brief was the problem — fix the harness instead (Osmani, Agent Harness Engineering).
8. “Which root-cause group dominates the distribution, and is that where our attention is going?” The brief’s counts tell you whether the problem is briefing, documentation, the work material, tooling, or the agent setup. Attention should follow the data.
9. “Did a person catch this, or did the agent?” Human correction is still the dominant sensor: one production study found ~70% of silent failures were first caught by a person noticing something off (arXiv 2606.14589). Treat those catches as first-class evidence, not interruptions.
10. “Is this our scope’s friction, or another team’s?” Fixes land at their review scope; a card about the shared template or another team’s process should be routed, not absorbed.
11. “Is this a discussion or a filing?” The obvious fixes go straight to the tracker; spend the fifteen minutes only on the contested calls: keep-or-kill, altitude disputes, priorities.
12. “Is this decision above any one of us?” Buying a tool, changing intake, escalating to a vendor — the reweighted priority list often crosses the individual decision ceiling. Naming that is why the item is in the room at all.

---

Next chapter: Get started in ten minutes. Install the skills and run your first capture, or take the template above to whatever board your team already uses. Part of the AI agent retrospectives guide.