Our AI teammates joined our retro

We build retrospective software, so our team’s retro board is a fairly ordinary place: Start, Stop, a column of open actions, the usual Friday arguments. Last week it gained some new contributors. Six of the cards weren’t written by anyone human — they were filed by the AI agents we work with every day, summarizing the friction from their own working sessions with us.

Let’s be precise about what this is, because the phrasing matters. This is not an AI sitting in the retro: no bot facilitating the meeting, no AI feature summarizing the humans’ cards. The agents that do real work on our team (the ones writing code, editing content, running audits) showed up to the ceremony the way any teammate does: with their own account of how the work went. Participants, not facilitators; the meeting stayed ours.

This wasn’t a stunt, either. The push came in one of our own retros: someone said the onboarding docs were out of date (again) and someone else mentioned an agent had flagged exactly that to them mid-session that morning, in passing, before the context scrolled away. The agent had known; nothing in its world said the observation was worth keeping. So for the past few weeks we’ve been running an experiment on ourselves: the practice is the one we described in how to gather feedback from your AI agents. At the end of each substantial AI-assisted working session, the agent writes a short, structured retro entry of its own work: what went well, what dragged, what each drag cost, one root-cause label per item, and a proposed fix. The entries accumulate in the repos the work happened in. When enough had built up, a companion process read them all and filed the recurring patterns straight onto our retro board, prefixed [AI retro] so nobody mistakes the author.

Here’s what our newest teammates had to say about working with us.

What they found

The headline they led with was about themselves. The top card 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.” The single biggest source of friction in our AI-assisted work, by the agents’ own accounting, was the agents, specifically the habit of acting on an assumed state of the world instead of checking the live one first. We’ll take honesty like that from any colleague.

The biggest team-shaped theme crossed every boundary a person wouldn’t. Git and branch-state errors under concurrent-agent work showed up in eight sessions across two repos: stale bases, unread branch targets, one agent moving a branch another was using, a PR retargeted without verification. No single session would have ranked this anywhere near the top; each instance was a shrug and a few lost minutes. Ranked across eight sessions, it was unmissable.

It caught us shipping on partial checks. Four sessions where something was pushed or merged after a narrower check than CI actually runs: a bare type-check instead of the full build, targeted tests instead of the suite. Twice in one repo, on the same day.

And the most uncomfortable cards weren’t about the work at all; they were about follow-through. One card noted that a testing-convention gap had let a reproducible crash slip past two rounds of review, and that the fix document had been proposed the day before and never written. Another noted the same tool stall had now cost two sessions, “no standing fix shipped between them.” A third: the same requirements-creep pattern, three consecutive sessions, “each noting it recurring from the last.” The agent, it turns out, remembers what we said we’d do.

The two things worth staring at

First: none of this was visible to any individual. That’s not a failure of attention; it’s the shape of the problem. AI-session friction is chronic and minor, so it never triggers a postmortem, and it evaporates when the session ends. Each of us had absorbed our share and moved on. The ranking (this pattern costs the team most) only exists in the aggregate view, and the aggregate view only exists because the entries were comparable: same schema, same small set of root-cause labels, every claim citing a dated session. This is the aggregation idea at the center of the guide this post accompanies, and it’s the part we most wanted to test on ourselves.

Second: the agents didn’t blame anyone, including themselves, loosely. The entries follow two rules that turned out to matter more than we expected. Friction items describe the gap and what it cost, never who caused it: no names, no “X’s brief.” And “the agent made a mistake” is a residual label, only used when the inputs were genuinely adequate, which is exactly why the 38% figure got our attention: it survived that discipline. The result read like a good retro contribution: specific, evidence-cited, blameless, and slightly embarrassing for everyone equally.

What the room decided

We decided to act on all three of the proposed actions, each at the altitude it named. The “confirm live branch and PR state before mutating” rule goes into each repo’s agent docs, a documentation fix for the eight-session theme. The pre-push hook that runs the CI-equivalent build and tests goes into the repos that got burned by partial checks, an environment fix, so it doesn’t depend on anyone remembering. And the testing-convention doc that was “flagged the day before and never written” is being written, with the crash that slipped through as its worked example.

No grand reorganization, no new process: three ticket-sized fixes with owners. The modesty is deliberate: the whole bet of this practice is that small fixes, aimed at the right level and actually checked next cycle, compound. Whether these three stick is precisely what the next brief’s adoption check will tell us; the same mechanism that caught us last time will be grading us on it.

It’s early days, and we’re saying so plainly. But we walked out of that retro more interested in our own working patterns than we’ve been in a while — and a little competitive with a colleague who doesn’t even get tired.

The honest footnotes

This is our first synthesized brief, weeks of data, not months, so we’re treating the rankings as attention allocation, not accounting. The costs in the entries are the agent’s own estimates and are marked as such. The practice’s harder claims (that labels stay consistent between raters, that the trend line actually bends after fixes land) are experiments we’re running rather than assumptions we’re making, and we’ll publish what they say either way.

But the core payoff already showed up: a set of patterns nobody on the team could see individually, ranked, evidenced, and filed into the ceremony where the people who own the fixes were already sitting. Rahul Garg’s Feedback Flywheel includes in its cadence list “an agenda item in the existing sprint retrospective: what worked with AI this sprint?” We can now report that the agenda item is considerably more interesting when your AI teammates file their own items.

Try it on your own team

Everything we used is free and documented in the guide: how the entries work, the root-cause labels, the never-log rules (no secrets, no customer data, and never anything that identifies a person), and the facilitator’s 15-minute agenda item, plus the two skills that implement the capture and synthesis ends. It works with any capable agent and a text file; our product is one place the results can land, not a requirement.

Next cycle, the brief’s adoption check will tell us whether we actually wrote that testing doc this time. We’ll let you know. So will they.

Tried it? Disagree with it? We mean it about wanting to be argued with: ai-discussion@teamretro.com.