What this agent does

A Linear sprint summary agent runs at the end of a cycle and produces a written record of what shipped, what slid, what the team added mid-cycle, and what got cut. It replaces the manual end-of-cycle write-up that engineering leads usually do on Friday afternoon or skip altogether.

The agent is a reporter, not a coach. It does not score the team, rank engineers, or recommend changes. It surfaces facts the team can discuss in the retro. The team draws conclusions.

For a related daily-cadence pattern, see AI agent for Notion daily rollup. For task-management automation more broadly, see AI agent for Asana inbox zero. For cluster context, see what an AI agent can actually do.

Linear GraphQL access

Linear exposes a single GraphQL endpoint. The agent uses three queries.

The token Linear issues is a personal API key. There is no OAuth flow for internal tools, which simplifies setup but means the token belongs to a human. Treat it as a secret, store it in a secrets manager, and rotate it on the workspace owner's calendar (every 90 days at minimum).

Linear's published rate limit is approximately 1,500 requests per hour per token. A summary run for a team with 200 cycle issues uses fewer than 10 queries with paging. The agent stays well under the limit, even for organisations with dozens of teams running in parallel.

Cycle-start snapshot

The summary's whole value comes from comparing the current cycle state against the cycle's state when it began. Without a snapshot, the agent can only describe the cycle's end state, not how it got there.

On cycle-start day, a small agent task runs once and stores the snapshot: for each issue in the cycle at start, it records the issue ID, title, estimate, assignee, and labels. The snapshot lives as a JSON blob attached to the cycle's Linear document, or in the agent's own database if the operator prefers external storage.

The snapshot is read-only after creation. If the operator manually edits cycle membership mid-cycle (legitimate use case: pulling forward a P0 hotfix), the change is recorded as a normal "added late" entry in the diff. The snapshot stays the same.

At cycle end, the agent reads the snapshot, reads the current cycle, and produces the diff. The diff is the source of truth for the summary.

The four summary sections

Every cycle summary has the same four sections. Consistency is the feature.

  1. Shipped. Issues that were in the cycle at start and are now in a terminal state (Done, Released, Closed). Listed with title, assignee, and estimate. If estimate-summing is enabled in the workspace, the total of completed estimates is shown.
  2. Carried over. Issues that were in the cycle at start but are not in a terminal state. The agent groups these by assignee and by reason if the reason field is populated (we recommend a "Carry-over reason" property on the cycle, populated by the assignee within 24 hours of cycle end).
  3. Descoped. Issues that were in the cycle at start but are no longer in the cycle and not in a terminal state. Listed with the timestamp of removal and, if available, the actor who removed them.
  4. Added late. Issues that were not in the cycle at start but are in the cycle now (or moved out before completion). Listed with timestamp added and current state.

Each section is a flat list. No ranking. No "spotlight on the team's biggest win." No motivational copy.

Where the summary goes

One destination, configured per team.

Linear document (default). The summary becomes a new document under the team's Docs section, named "Cycle <number> summary." Linear's document blocks support headings, lists, and inline issue links, so the summary renders cleanly with one-click drill-through to source issues.

Slack channel (opt-in). A formatted message in the team's engineering channel. Slack mrkdwn lets the summary stay readable, but long carry-over sections are collapsed into a single "see full document" link rather than rendered inline. Slack threads quickly become illegible at length.

The agent never DMs the team. It never posts to a public company-wide channel. It never tags individuals. The summary is a team document, addressed to the team.

Guardrails

Five guardrails keep the agent honest.

Common mistakes

Generating sprint summary without a cycle-start snapshot. Without the snapshot, the agent cannot tell what was added late versus carried over from the start. It will report an inflated "shipped" because it counts late additions as planned work. Start the snapshot job first.

Ranking engineers. Tempting and wrong. A summary that lists "Top contributor" or "Most carried-over" creates incentives the team will optimise against, usually by inflating estimates or grabbing small issues. Surface assignments without ranking.

Posting at the moment cycle ends. Posting at midnight or whenever the cycle technically closes misses the team's reality: people are still pushing final PRs after the official end. Run the agent the next business morning instead, so the cycle has actually settled.

Letting the agent comment on issues. An agent that posts "this issue was carried over from cycle 23" as a comment on the issue clutters the issue history forever. Keep all output in the summary document.

Treating cycle as project. Linear's cycle is a time-boxed sprint. Linear's project is a longer-lived initiative. The agent summarises cycles. A project summary is a different agent with a different cadence, usually monthly.

Frequently asked questions

What does a Linear sprint summary agent actually do?

It queries Linear's GraphQL API at cycle end, summarises the closed cycle into four sections (shipped, carried over, descoped, added late), and posts the summary to a Linear document or a Slack channel. It does not move issues, change estimates, or close issues itself. The cycle's state at posting time is the source of truth.

Which Linear API token does the agent need?

A personal API key from the workspace owner with read access to issues, cycles, projects, and labels, plus write access only to documents in a designated team. Linear's GraphQL API is rate-limited, so the agent batches queries by team rather than making one query per issue.

How does the agent detect scope creep mid-cycle?

It diffs the cycle's issue list against the snapshot it took on cycle-start day. Issues added after start are flagged as 'added late.' Issues removed before completion are flagged as 'descoped.' Both categories appear in the summary so the team can discuss the cause at the retro: was the late add an emergency, or was the original plan too thin?

Does the agent assign blame for missed work?

No. The agent reports who was assigned to each carried-over issue but does not generate any interpretation, ranking, or comparison across people. Sprint retros are a team conversation, not a leaderboard, and an agent that surfaces individual misses creates a worse retro, not a better one.

Where does the summary get posted?

One configured surface: a Linear document, a Slack channel, or both. The default is a Linear document under the team's Docs section, named with the cycle number. Cross-posting to Slack is opt-in because Slack has its own noise budget. The agent never DMs individuals about cycle outcomes.

Three takeaways before you close this tab

Sources

The same shape, applied to other tools and surfaces: