Run a weekly review with an AI agent in 30 minutes: the agent drafts, you correct, the team reads
A Friday loop: an AI agent drafts the weekly status from closed issues, stale items and goal check-ins; a human spends 30 minutes correcting it. Steps and template.
On this page
A weekly review with an AI agent works like this: on Friday the agent pulls what closed, what went stale and how each goal moved, drafts a status in a fixed template, and you spend thirty minutes correcting it before the team reads it. The agent does the gathering, which is the part people skip; you do the judgment, which is the part the agent gets wrong. The result is a status update that is on time, specific and still honest.
This is the loop we run at Atrix every Friday at 15:00. Below is the template, the steps, what the agent reads, what it reliably gets wrong, and how to do it whether or not your tools have an agent.
Why the human correction pass is the whole point
Automated status reports have existed for years. Most of them are ignored because they are accurate and meaningless: "14 issues closed, 3 opened, velocity stable". A status update is useful when it says what those numbers mean for the plan, and that requires someone who knows the plan.
The idea of a short, fixed correction pass rather than a from-scratch write-up has been circulating in founder communities such as Indie Hackers for a while: let the tooling assemble the facts, then spend a bounded block of time (thirty minutes is the common figure) turning them into a message. We treat that as a sensible community practice, not a proven method; what we can say is that our own updates went from "sometimes, late, vague" to "every Friday, specific" once the gathering stopped being manual.
The draft is the agent's. The judgment is yours. Do not let that split blur.
The weekly status template
The template is fixed so the agent fills it the same way every week and readers know where to look:
| Section | What goes in it | Who supplies it |
|---|---|---|
| Headline | One sentence: on track, at risk, or behind, and why | Human |
| Shipped | Issues closed this week, grouped by product, with links | Agent |
| Slipped | Issues due this week that did not close, with the new date | Agent drafts, human confirms the date |
| Stale | Issues untouched for 14+ days that are still open | Agent |
| Goals | Each goal's key results, with this week's check-in | Agent drafts from check-ins, human adds the sentence |
| Next week | The three things that matter most | Human |
| Asks | Decisions or help needed from someone specific | Human |
Three human sections, four agent sections. If the agent ends up writing "Next week" and "Asks", the review has stopped being a review.
Step by step: the Friday loop
- Block 30 minutes on Friday afternoon, every week, in the calendar. The block is the ritual. Without it the review happens on Monday morning, which is too late to change the week.
- Give the agent a fixed brief. Inputs: issues closed in the last 7 days, issues due in the last 7 days still open, open issues untouched for 14 days, the goals and their latest check-ins. Output: the template above with the agent's four sections filled and the human sections left as placeholders. Constraints: read only; no status changes; no invented reasons for slips.
- Read the Shipped list first and correct the grouping. The agent groups by product; sometimes the interesting grouping is by customer or by theme. Fix it.
- Confirm every slipped date. The agent reports the new due date from the issue. If nobody set one, it says so, and you set it now or decide the issue does not matter.
- Decide what to do with each stale item. Close, reassign, or leave with a reason. Stale items that survive three reviews are not stale, they are not work; delete them.
- Write the headline last. After reading everything, one sentence. If you cannot write it, you do not know whether the week was good, and that is the finding.
- Add Next week and Asks by hand. Three items, not seven. Asks name a person.
- Post it where the team reads. A feed post or a pinned message, not a document nobody opens.
Thirty minutes is enough once the brief is stable. The first two weeks take longer because you are fixing the brief, not the report.
What the agent reads, and what it gets wrong
The agent needs read access to issues, goals and the team feed; nothing else. In Atrix, through the MCP server or the agent chat, that is the work.read, goals.read and feed.read scopes, and the tools it uses are work_list_issues with a date filter, project_status per product, goals_list and pulse_report_latest, which already summarises the week's activity per product. Posting the final update uses feed_post_update, which notifies people's phones, so we keep that scope off the agent and post by hand after the correction pass.
Reliable failures we see every few weeks:
- Reasons for slips. The agent infers a reason from comments ("blocked on design") when the real reason was that the assignee was on leave. Never let it write the why; it writes the what.
- Goal progress read as linear. A key result at 40% with two weeks left is not "on track" because 40 is more than 0. The check-in sentence is yours.
- Counting the same issue twice when it was closed, reopened and closed again. Minor, but it inflates "Shipped".
- Over-politeness. Left to itself the draft says "good progress across the board". Delete those sentences; the headline is where the judgment goes, and it should sometimes say "behind".
Doing it without an agent
If your tools have no agent, the loop still works with saved filters. In any tracker, save four views: closed last 7 days, due last 7 days and open, untouched 14 days, and goals. Open them in order on Friday, paste into the template, and do the same correction pass. It takes forty-five minutes instead of thirty, and the gathering is the part you will be tempted to skip, which is the argument for automating it.
Linear's insights, Jira's dashboards and Notion databases with date filters all serve as the four views. The difference an agent makes is the first draft of the prose for Shipped and Slipped, which saves perhaps ten minutes and, more importantly, removes the blank page.
A worked Friday
Last week's review, lightly redacted. Shipped: nine issues across Calendar and Pages, including the booking reminder emails. Slipped: two, both Pages, both re-dated to next Wednesday after a conversation with the assignee. Stale: four, of which two were closed as no longer relevant and one reassigned. Goals: the "self-serve activation" key result moved from 31% to 38%; the check-in sentence was "moving, but the biggest lever (trial emails) ships next week, so judge it then". Headline: "On track for the cycle; one goal will be decided by next week's trial emails." Next week: trial emails, Android build to testers, pricing page copy. Asks: one decision on whether the Android beta goes out before the pricing change.
Total time including posting: 28 minutes. The agent's draft had grouped the nine shipped issues by product, which was right, and had written "blocked on design feedback" for one slipped issue, which was wrong and got cut.
FAQ
What should a weekly status update include?
A one-line headline (on track, at risk, behind), what shipped, what slipped with new dates, what is stale, how each goal moved, the three priorities for next week, and specific asks with a named person. Keep it to one screen.
Can an AI agent write the weekly status on its own?
It can write the factual sections: shipped, slipped, stale and the goal numbers. It should not write the headline, the reasons for slips, next week's priorities or the asks. Those need someone who knows the plan, and that is the thirty-minute correction pass.
How long should a weekly review take?
Thirty minutes once the brief and the template are stable. The first two or three weeks take longer because you are fixing the brief. If it regularly takes over an hour, the template is too long or the tracker is out of date.
What data does the agent need access to?
Read access to issues (closed, due, last-touched dates), goals and their check-ins, and the team feed. It does not need customers, hiring, pay or the ability to change anything. Grant reads only; post the final update yourself.
Should the weekly review be posted to the whole team?
Yes, where the team already reads: a feed post or a pinned chat message. A document nobody opens is a private diary. Keep it to one screen so it is read on a phone.
How is this different from a sprint retrospective?
A weekly review is about status and the next week's priorities; it takes thirty minutes and produces a message. A retrospective is about how the team worked over a cycle; it takes an hour and produces changes to process. Do both; do not merge them.
Next step
Set up the four views (closed, slipped, stale, goals) in whatever tracker you use and block Friday at 15:00. If your work lives in Atrix, project management already has cycles, labels and goal check-ins the agent reads from, and the founders page shows how a small team runs this loop end to end.