A Weekly Retro Agent: What Happened, What Changed, What Broke

Every team runs some version of the same Monday ritual. Someone opens six tabs, scrolls through a week of Slack, skims the merged pull requests, glances at a dashboard, and tries to reconstruct what actually happened over the last seven days. The output is usually a half-remembered summary delivered from memory in a standup, and the things that fell between tools, the ticket that quietly stalled, the metric that dipped on Thursday, the incident that got fixed but never written up, stay invisible.

A weekly retro agent replaces that reconstruction with a document. Once a week, on a schedule, an autonomous agent reads across your tools, compares this week against last week, and writes a single narrative report: what shipped, what moved, what broke. This article walks through how that agent works mechanically, how to write instructions that produce a useful retro instead of a bland activity dump, and where the honest limits are.

The examples here use Skopx, where you build agents by describing them in chat at Create Agent, but the structure applies to any platform that supports scheduled agents with cross-tool access and persistent memory.

Why a weekly retro is an agent-shaped problem

Not every recurring task deserves an agent. Plenty of weekly summaries are better served by a fixed pipeline: pull the same three numbers, drop them in a Slack message, done. If your retro is genuinely that rigid, a deterministic workflow is cheaper and more predictable, and the tradeoffs are covered in detail in AI agents vs workflow automation.

A retro earns an agent when three things are true, and for most teams all three are:

The sources are heterogeneous. Shipped work lives in GitHub or Linear. Discussion lives in Slack. Customer signals live in HubSpot or a support tool. Metrics live in Postgres. No fixed template joins those cleanly, because the interesting part of a week is different every week. One week the story is a launch; another week it is an outage; another week it is a deal that closed.

The output is judgment, not aggregation. "14 PRs merged" is aggregation. "The billing refactor landed, which unblocks the two invoicing tickets that have been stalled since July" is judgment. It requires reading the PR titles, connecting them to open tickets, and deciding what matters. That connective reasoning is exactly what a language model does that a dashboard cannot.

Change matters more than state. A retro is inherently a delta document. You do not want to know that MRR is at some number; you want to know it moved, by how much, and whether that is unusual. Deltas require memory of last week, which is a native agent capability and an awkward bolt-on for anything else.

The anatomy of a retro agent

On Skopx, an agent is a small set of parts you can inspect and edit: plain-language instructions, a trigger, per-integration grants, budgets, success criteria, and memory. Here is what each looks like for a weekly retro.

Trigger: a schedule. "Every Monday at 6:00 UTC" is typical, early enough that the report is waiting before the first standup in any Western timezone. Scheduled triggers are the natural fit for retros; the general options are covered in scheduled AI agents.

Grants: read-heavy, write-light. The retro agent needs read access to several toolkits: GitHub or Linear for shipped work, Slack for discussion and incident channels, a connected database for metrics, maybe HubSpot for pipeline movement. It needs at most one write-shaped action: posting the finished report to a Slack channel or creating a Notion page. On Skopx, grants are set per toolkit with tiers. Set every read toolkit to run automatically, and set the single publishing action to whatever comfort level you have. Reads flow without approval even under approval_required, so a read-heavy agent like this runs to completion without waiting on you.

Budgets: a ceiling on drift. A retro that reads a week of Slack across many channels can burn tokens fast. Skopx budgets cap tokens per run, tokens per day, maximum steps, and minutes per run, and an agent that fails its budget three times auto-pauses rather than silently retrying forever. For a retro, a generous step cap with a firm token cap is the right shape: the agent needs many small reads, not a few enormous ones.

Memory: the delta engine. This is the part that makes the second run better than the first. The agent persists cursors and baselines between runs: the last PR it saw, last week's metric values, the open items it flagged. Run two produces a delta report and is typically cheaper, because the agent skips everything it already processed. How this works in general is covered in AI agent memory explained.

Success criteria: what a good retro contains. You state, in plain language, what the run report is evaluated against: "The report contains a shipped-work section with linked items, a metrics section with week-over-week deltas, an incidents section even if empty, and one prioritized open question." The run report is then checked against those criteria, so a run that produced a thin or malformed retro is visibly a failure rather than a quiet disappointment.

Writing the instructions: narrative, not inventory

The difference between a useful retro and a wall of bullet points is almost entirely in the instructions. Here is a condensed example of the shape that works, framed explicitly as a hypothetical you would adapt:

Every Monday, produce a weekly retro for the product team covering the previous Monday through Sunday.

Shipped: list merged PRs and completed Linear issues. Group them by theme, not chronology. If a shipped item closes something that had been open more than two weeks, say so.

Metrics: query the analytics database for signups, activation rate, and weekly active users. Report each as a week-over-week delta. Flag any move larger than 10 percent and look for a plausible cause in the week's shipped work or incidents before speculating.

Broke: scan #incidents and #eng-alerts for anything reported this week. For each, note whether it was resolved and whether a follow-up ticket exists. If an incident has no follow-up ticket, list it under Open Questions.

Tone: write it as a narrative a teammate would read, not a log. Lead with the single most important thing that happened. Keep it under 800 words. If a section is empty, say "Nothing this week" rather than omitting it.

Three principles are doing the work here. First, force connections: "look for a plausible cause" and "if a shipped item closes something old, say so" push the agent from listing to reasoning. Second, define materiality: the 10 percent threshold stops the report from crying wolf over noise. Third, require the empty sections: "Nothing broke this week" is real information, and its absence would make you wonder whether the agent looked. A fuller treatment of instruction-writing is in the AI agent instructions guide.

Instructions on Skopx are editable and versioned, which matters more for a retro agent than most. You will tune this prompt for a month: adding a section, tightening a threshold, banning a phrasing tic. Versioning means you can see what changed when the reports changed.

What a run actually looks like

It is worth being concrete about the mechanics, because "an agent reads your tools" can sound like magic and it is not. A Monday run of this agent, on Skopx, is a step timeline you can open and inspect:

1. The schedule fires. The agent loads its memory: last week's metric baselines and the cursor marking the last processed PR.
2. It lists merged PRs since the cursor, reads titles and descriptions, and cross-references completed Linear issues.
3. It queries the connected Postgres database, read-only with bound parameters, for the three metrics, and computes deltas against the remembered baselines.
4. It reads the incident channels in Slack for the week's messages.
5. It reasons over all of it and writes the report.
6. It posts the report to #weekly-retro. If you set that grant to "asks first", this step parks as a pending approval showing the exact call and arguments, the full message text and target channel, and executes only when you approve it. Approval-gated publishing is covered in AI agents with human approval.
7. It updates memory: new baselines, new cursor, this week's open questions carried forward.

Every step in that timeline has a humanized label and an expandable raw result, the run has a duration and a token count, and the whole thing ends in a markdown report rendered as a document. When the retro says something surprising, you can click into the exact query or the exact Slack read that produced it. Run history is append-only, so the retro archive doubles as a record of what the agent saw each week.

Retro agent vs. the alternatives

The honest reading of that table: the agent does not dominate everything. A dashboard is still better for real-time monitoring, and a human still writes a better retro for a week they lived through intensely. The agent wins on consistency and coverage. It reads all of it, every week, including the weeks when everyone was too busy to write anything down, which are exactly the weeks a retro matters most.

Where this goes wrong, and how to contain it

Candor section. Four failure modes show up in practice with retro agents, and each has a containment.

Confident wrong causality. The agent sees signups dip and a deploy on the same day and writes "signups dipped following Thursday's deploy" as if it were established. Contain it in instructions: require hedged language for inferred causes ("possibly related to") and require the evidence to be named. Because every claim in a Skopx report traces to a step in the timeline, you can check the inference in one click, but it is better to make the report honest in the first place.

Slack noise poisoning the incident section. Someone jokes "everything is on fire" in a channel the agent reads, and it lands in the report. Contain it by scoping: point the agent at dedicated incident channels, not general chat, and instruct it to report only messages with concrete symptoms or acknowledgments. Treat channel scoping as part of the agent's guardrails, alongside grants and budgets; the broader discipline is covered in AI agent guardrails.

The report bloats. Left alone, weekly reports drift longer as the agent tries to be thorough. The 800-word cap in the instructions is not decoration; it forces prioritization, which is the entire value of a retro. When something must be cut, the agent should cut the inventory, not the judgment.

A source silently changes. The team renames a channel or migrates a project, and one section of the retro goes quietly empty. This is why success criteria require every section to exist explicitly: "Nothing this week" in a section that is normally busy is a prompt for you to check the plumbing, and a run that cannot produce a required section at all fails visibly against its criteria instead of shipping a hole.

One more limit worth stating plainly: the agent can only retro what its tools can see. Decisions made in a hallway, context that never hit Slack, a customer call that was never logged, none of that appears. A retro agent raises the floor of your team's memory; it does not replace writing things down.

Rolling it out without drama

A sensible first month looks like this:

Week one: draft mode. Build the agent in chat, describing the sections and sources. Set the publishing grant so the report comes to you rather than the team channel, or use drafts-only mode on the messaging toolkit. Run it manually once ("runs when you ask") before trusting the schedule, and read the step timeline end to end. First runs are the most expensive because there is no memory to delta against; that is expected.

Week two: calibrate. The first real report will over-include somewhere and under-include somewhere else. Edit the instructions, which are versioned, so you can correlate prompt changes with report changes. Tighten the materiality thresholds. This is also when you pick the model; Skopx lets you choose per agent among Claude, GPT, Gemini, Kimi and others, and a retro is a good place to try a stronger model, since it runs once a week and quality is the whole point.

Week three: publish with approval. Point the publishing step at the team channel but keep it on "asks first every time". You review the exact message before it posts. Approving executes exactly that parked call once; rejecting executes nothing.

Week four onward: decide your steady state. Some teams graduate the publish step to fully automatic; others keep the approval forever because a 30-second review of a weekly report is cheap insurance. Both are legitimate. Pausing the agent remains a kill switch for queued runs at any time, and you can stop any run mid-flight.

If the retro proves useful, the same pattern extends naturally: a daily variant becomes a morning brief agent, and a metrics-only variant becomes a KPI digest. Resist merging them all into one mega-agent; one agent per document with its own memory and success criteria stays debuggable.

FAQ

How is this different from just asking a chatbot "summarize my week" every Monday?

Three ways. First, the retro agent runs unattended on a schedule and touches live tools with scoped grants; a chat session requires you to show up and feed it context. Second, it has memory: baselines and cursors persist between runs, so it computes real week-over-week deltas instead of summarizing whatever you pasted. Third, every run leaves an inspectable step timeline and an append-only history, so claims are traceable to sources. A chatbot answers; an agent operates. The distinction is unpacked in the sibling piece on agents versus chatbots.

What does a weekly retro run cost?

It depends on your model choice, how many channels and repos the agent reads, and whether memory lets it skip already-processed items, so we will not quote figures. Structurally, second and later runs are typically cheaper than the first because delta reads are smaller than full reads, and the token-per-run budget puts a hard ceiling on any single run regardless. On Skopx you can bring your own key across 8 providers with zero markup, or use the $16 per seat Team plan with included tokens; either way, the run report shows the exact token count for every run, so cost is measurable rather than estimated.

Can the agent write to my tools, like filing follow-up tickets for incidents without them?

It can if you grant it, but start by not doing that. The retro's core value is read-and-report, and the safest version has exactly one write action: publishing the document. If you later want it to file follow-up tickets, add that toolkit with the grant set to "asks first every time", so every proposed ticket parks as a pending approval showing the exact call and arguments before anything is created. Escalate the grant tier only after weeks of approving proposals you agree with.

What happens when a run fails, or the report is wrong?

Failures are visible, not silent. A run that exceeds its budget or cannot meet its success criteria shows up as a failed run in the append-only history, and three budget failures auto-pause the agent entirely rather than letting it flail weekly. When a report is wrong rather than missing, open the run's step timeline: each step's raw result is expandable, so you can find whether the agent misread a source or the source itself was misleading, then fix the instructions accordingly. The debugging workflow is the same one described in our guide to debugging agent runs.

Should each team have its own retro agent, or one agent for the whole company?

Separate agents per audience. A product team retro and a sales retro read different tools, apply different materiality thresholds, and serve different readers; one agent trying to do both produces a report that is half-irrelevant to everyone. Separate agents also keep memory clean, keep grants minimal per agent, and let each team tune its own instructions. A company-wide summary, if you want one, is better written by a human who reads the team retros, or eventually by a third agent whose only sources are the published team reports.