A retrospective is only useful if the action items get done. The standard failure: insights live in a Notion page, decisions in a Confluence doc, the work in Linear, with no link between them. Dock runs the retro as a row-shaped workflow. An agent reads sprint data and raw retro inputs, drafts themes and candidate actions, and the team lead assigns owners. This is one workflow in the Dock for project management pillar.
Linear, Notion, and Confluence stay the system of record for the raw data. Dock is the system of record for what the agent interprets. Each Dock row carries a pointer back to the platform record, agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data via fresh API reads when it needs current state.
The Retro Actions table
One Dock table per sprint. Rows are candidate actions, not raw observations.
| Theme | Evidence | Proposed action | Owner | Linear issue | Status |
|---|---|---|---|---|---|
| Review queue stalls mid-sprint | 3 PRs >48h idle in sprint 47 | Add a daily review SLA reminder | @priya | ENG-2104 | accepted |
| Spec gaps on payments work | 2 mid-sprint scope changes, retro quotes from @sam, @lee | Require API contract section in spec template | @notion-agent | ENG-2105 | accepted |
| Standup running long | Notion notes show 22-min avg over 10 days | Move status to async thread | unassigned | none yet | drafted |
Theme and Proposed action are agent-drafted. Evidence is a list of pointers, not a paraphrase. Owner is human-assigned. Status moves through drafted, accepted, rejected, done.
The workflow
The retro-agent runs the night before the meeting. It pulls closed and re-opened issues from Linear, fetches the retro doc from Confluence, and reads the Notion notes channel the team uses for in-flight observations. It clusters observations into three to six themes, drafts one candidate action per theme, and writes a row for each. Each row stores the issue IDs, doc URL, and Notion block IDs it cited.
In the retro itself, the lead reviews drafted rows live, edits the proposed action, accepts or rejects, and assigns owners. Assignment is the load-bearing step. The owner can be a person or another Dock agent, but never blank on an accepted row. When she assigns ENG-2105 to the Notion-agent, that agent inherits the row and updates the spec template. The principle is in agent identity: the agent has its own login, scopes, and audit trail.
Why this matters
Scrum.org defines the Sprint Retrospective's purpose as "to plan ways to increase quality and effectiveness" (Scrum Guide). Atlassian is more specific: "assign owners and deadlines to kickstart progress" and enter actions "directly into your sprint planning or project management system" (Atlassian Team Playbook). The gap is between the retro doc and the issue tracker. A row-shaped Dock table closes it because the action is the row, and the row is the link.
It is auditable two sprints later. Open the row, see which issues drove the theme, who accepted it, who did the work, and when it shipped. Handoff mechanics are in the agent collaboration primer, and the product-team shift is in Cloud 2.0 for product. Owner accounts are provisioned like human accounts, per the agent identity lifecycle, and cross-team handoff rules apply as in the collaboration primer.
Try Dock for your next retro and see the action rows the agent drafts.
FAQ
Does the agent decide the retro themes? It drafts themes from sprint data. The lead accepts, edits, or rejects each one live.
What if an action needs work in Linear, not Dock? The row links to a Linear issue. Linear stays the system of record for the engineering work. Dock records the decision and the owner.
Can a Dock agent own a retro action? Yes. The owner field accepts a person or an agent. The agent gets its own row history and audit trail.
How is this different from a Notion retro template with checkboxes? A checkbox does not carry attribution. A Dock row carries the source pointers, the drafting agent, the accepting human, the owner, and the timestamp.
