Your team runs retros every other Friday. You talk about what went well, what did not, and what to improve, you leave with action items, and then nothing happens. Months later you are re-discovering the same problems. "We should do more async standups" (you said that 3 sprints ago). "We need better code review discipline" (same issue, second time). The retro notes sit in a doc nobody reads. The Retrospective Synthesis agent runs every Friday at 5 PM and turns those notes into actual learning.
How it works
The agent applies four passes. Retro parsing reads the raw notes (what went well, what did not, action items) and structures them into specific problems, proposed solutions, owners, and severity. Pattern detection compares this retro against 8-plus previous ones: is this recurring, first-time, or something you said you would fix last sprint and did not? Playbook updates extract any agreed process change and write it into the team playbook, so "we agreed to async standups" actually lands somewhere durable. Pattern flagging raises anything that appears 3-plus times: "we have complained about slow deploys 5 times, we keep saying we will fix it and we do not, let's actually prioritize it."
The output is a retro summary of what changed and what to track, an updated playbook, and a list of flagged high-priority patterns.
Why pattern detection is the whole point
Manual review means opening 8-plus documents and building a pattern map in your head. The agent does that in minutes and surfaces patterns you would miss because they span long time periods. The slow-deploys example is the shape of it: a complaint that recurs 5 times across 5 sprints without resolution is not another action item, it is a signal the fix is either under-resourced or unclear. Tracking action-item follow-through does the same thing for accountability. Seeing "we committed to this three times and never followed through" makes the invisible visible and forces a real decision.
What it changes
The team gets memory. Recurring problems get tracked instead of re-discovered every three months, and you can finally see which improvements you committed to and never did. The playbook evolves from what actually happened, not from theory, and each retro builds on the ones before it instead of sitting in isolation. Velocity improves because you fix the recurring bottleneck. Morale improves because action items get done. The team solves problems instead of re-finding them.
To run it, store retro notes in Notion or Google Docs, feed it sprint metrics for context, give it your current playbook and at least 8 to 10 historical retros, and connect action-item tracking. Schedule it for Friday at 5 PM, right after the retro, and point it at this week's session to start.