A Standup Summary Agent for Teams That Hate Standups

The daily standup has a strange property: everyone agrees the information matters, and almost nobody enjoys producing it. Fifteen minutes of "still working on the same thing" and "no blockers" costs a team of eight two hours of collective attention every day, and most of what gets said is already written down somewhere. It lives in Jira tickets that moved columns, GitHub commits that landed overnight, Linear issues that got reassigned, pull requests that have been sitting in review since Tuesday.

An AI standup summary agent inverts the ritual. Instead of asking humans to recite what the tools already know, the agent reads the tools each morning and posts a short summary to Slack before anyone logs on. The humans keep the part of standup that is actually human, the discussion of blockers and decisions, and drop the part that is recitation.

This article walks through how to build one, what a good summary includes, what it should deliberately leave out, and where the honest limits are. The examples use Skopx, where you describe the agent in chat and it assembles itself with no code and no canvas, but the design principles apply to any implementation.

What a standup summary agent actually does

Strip away the framing and the job is simple: every weekday morning, on a schedule, read a defined set of sources, compare them against yesterday's state, and post a structured digest to a channel.

The sources are usually some combination of:

• The project board. Jira, Linear, Trello, Asana, or ClickUp. What moved between columns, what was created, what was closed, what changed assignee.
• The repository. GitHub commits and pull requests. What merged, what is open and waiting for review, what has been waiting longest.
• The calendar, optionally. Google Calendar for anything that will interrupt the day: releases, demos, on-call handoffs.

The output is a markdown message posted to Slack (or Discord, or wherever your team lives). Not a wall of activity. A digest with an opinion about what matters.

The critical mechanical detail is the comparison. A useful standup summary is a delta report: what changed since yesterday, not a full inventory of the board. This is where agent memory earns its place. In Skopx, an agent's memory persists between runs, so the agent can store cursors and baselines, yesterday's board snapshot, the set of PRs it already reported, the last commit it saw. On the second run and every run after, it reports only the difference. We cover the mechanics of this in more depth in how agent memory works between runs, but the short version is: without memory you get a daily inventory, with memory you get a daily changelog, and only the changelog is worth reading.

What to include: the four sections that earn their place

After you strip out everything a human would skim past, four sections remain.

1. Shipped. What merged, closed, or moved to Done since the last run. Keep each item to one line with a link. This is the morale section and the accountability section at once, and it should come first because it is the only part people reliably enjoy.

2. Stalled. Items that have not moved in N days. A PR open for four days with no review. A ticket that has been In Progress for a week. This is the section a human standup is worst at producing, because nobody volunteers "my thing is stuck and has been for a while." The agent has no ego. It just reads timestamps. Set the threshold in the instructions: "flag any pull request with no review activity for 3 or more days, and any board item In Progress for more than 5 working days."

3. Needs a decision. Items blocked on a person: an unanswered review request, a ticket tagged blocked, a question in a comment thread with no reply. Name the person if your team culture supports it, or name the item and let people self-identify if it does not. Decide this explicitly when you write the instructions, because the agent will follow whichever convention you give it every single day.

4. Today's landscape. Anything scheduled that changes the shape of the day: a release window, a demo, an unusually loaded calendar. Keep it to two or three lines. This section is optional and many teams skip it.

That is the whole report. If your draft summary has seven sections, you are rebuilding the wall of noise the agent was supposed to replace.

What to skip, and why skipping is the hard part

The failure mode of every automated digest is completeness. The tools produce a lot of events, and an agent that reports all of them produces a message nobody reads by day three. The skip list matters more than the include list:

• Individual commits. Report merged pull requests, not the twelve commits inside them. Commit-level detail is for the PR page.
• Ticket edits that are not state changes. Description tweaks, label changes, and estimate updates are noise. Column moves, assignee changes, and status changes are signal.
• Anything that already generated its own notification. If CI failure alerts already land in a channel, the standup summary should not repeat them.
• Per-person activity rollups. "Alice made 9 commits, Bob made 2" is surveillance dressed as reporting. It poisons the team's relationship with the agent and measures nothing that matters. Report work items, not people-productivity counts.
• Editorializing about pace. The agent should say "this PR has waited 4 days," which is a fact, not "the team is falling behind on reviews," which is a judgment call that belongs to a human.

Write the skip list directly into the agent's instructions. In Skopx, instructions are plain language, editable, and versioned, so "never report individual commits; never count activity per person" is a durable rule the agent carries into every run, and you can see exactly when a rule was added or changed. There is a fuller treatment of writing instructions that hold up over months in our guide to agent instructions.

Building it in Skopx: a concrete walkthrough

Here is what setting this up looks like in practice, as a worked example.

You open Create Agent and describe the agent in chat:

"Every weekday at 8:00 UTC, read our Linear board and our GitHub repos. Post a summary to #standup in Slack with four sections: Shipped (merged PRs and closed issues since the last run), Stalled (PRs with no review for 3+ days, issues In Progress for 5+ days), Needs a Decision (anything tagged blocked or with an unanswered review request), and Today (releases or demos from the team calendar). Keep the whole message under 30 lines. Never report individual commits or per-person activity counts."

The chat assembles the agent from that description. What comes out has distinct, inspectable parts:

• A trigger. A schedule: every weekday at 8:00 UTC. Skopx also supports manual triggers ("runs when you ask") and webhooks, but a standup agent is the canonical scheduled agent. If you want the summary to also fire on demand before an ad hoc sync, that is a separate consideration covered in the triggers guide.
• Grants. Per-integration permissions with tiers. The sensible configuration here: Linear and GitHub reads run automatically, and the Slack post either runs automatically or, while you are still tuning, uses drafts-only mode so you see the message before anyone else does. Under Skopx's approval model, reads flow without approval even when an agent is set to approval_required; it is the write-shaped action, posting to Slack, that can be parked for a human.
• Budgets. A token cap per run, a daily cap, a max step count, and a minute cap. A standup agent is small and predictable, so tight budgets are cheap insurance. If the agent fails its budget three times, Skopx auto-pauses it rather than letting it burn quietly.
• Success criteria. Something like: "a message was posted to #standup containing all four sections, under 30 lines, with links on every item." Every run ends in a report that is evaluated against these criteria, so you can see at a glance whether this morning's run actually did the job.
• Memory. The cursor state: last commit seen, last run timestamp, the set of items already reported. First run is a full read and costs the most; subsequent runs are deltas and are typically cheaper.

Every run leaves a step timeline with humanized labels and expandable raw results, plus duration, token count, and the final markdown report. When Thursday's summary looks wrong, you open Thursday's run and see exactly which API call returned what. That inspectability is not a luxury; it is the difference between an agent you trust and an agent you quietly stop reading.

Standup agent vs. standup bot vs. the meeting

It is worth being precise about what this replaces and what it does not, because "standup bot" already means something in most teams' vocabulary.

The honest reading of that table: the agent is strictly better at recitation and strictly worse at everything that requires knowing what is in someone's head. The developer who spent yesterday debugging something gnarly that never became a ticket is invisible to the agent. So is "I am blocked but have not written it down anywhere" and every form of morale signal.

The teams that get the most from this do not delete standup. They shrink it. The summary posts at 8:00, everyone reads it in two minutes, and the synchronous meeting either disappears on quiet days or collapses to five minutes of discussing the Stalled and Needs a Decision sections. The agent handles state; the humans handle judgment. This division of labor, agents for recitation and monitoring, humans for decisions, shows up across use cases; the morning brief agent is the same pattern applied to an individual instead of a team.

Tuning it so people keep reading it

The first version of any digest agent is too long. Expect to spend the first two weeks editing instructions, and treat that as the normal path rather than a failure. Some concrete tuning moves:

Run it in drafts-only mode for the first week. With the Slack grant set to drafts-only, the agent prepares the message but does not send it; you review each draft and post it yourself. When five consecutive drafts would have been fine to send as-is, flip the grant to run automatically. This is the general pattern for testing agents safely: let the agent do everything except the irreversible part until it has earned the irreversible part.

Cap the length in the instructions, hard. "Under 30 lines" beats "be concise." Models comply with numbers more reliably than with adjectives.

Tune the stall thresholds to your team's actual rhythm. A 3-day PR threshold is right for a team that reviews daily and insulting for a team that batches reviews weekly. If the Stalled section is always empty, tighten it; if it always has eight items, loosen it or fix your review process, and be honest with yourself about which of those is the real problem.

Add a suppression rule when a category proves noisy. "Ignore draft PRs" and "ignore issues in the Icebox column" are the kinds of one-line instruction edits that make week three's summary sharper than week one's. Because instructions are versioned, you can also see which edit made things worse and roll your thinking back.

Watch the run reports, not just the Slack messages. If a run's report says it could not reach GitHub and fell back to board data only, that context lives in the run history even if the Slack message looks superficially normal. When something is off, reading the run beats guessing.

Where this goes wrong: the failure modes to expect

Candor section. These are the ways standup summary agents fail, and you should expect at least two of them.

The board is fiction. The agent reports the tools, and if the team updates Jira twice a week, the summary is confidently two days stale. An agent makes existing hygiene visible; it does not create hygiene. Some teams find the daily summary itself becomes the pressure that fixes board discipline, because a wrong summary in front of everyone is embarrassing in a way a stale board is not. Some teams just get a daily wrong summary. Know which team you have before you ship this.

Silent scope drift. Someone adds a repo, spins up a second board, or moves a project to a new Linear team, and the agent keeps faithfully summarizing the old scope. Nothing errors; the summary is just quietly incomplete. Put a recurring reminder in your own calendar to re-check the agent's source list monthly, because the agent cannot know about sources nobody told it to read.

It becomes furniture. Any daily message trends toward being scrolled past. The countermeasures are ruthless brevity, an empty-state rule ("if nothing shipped and nothing is stalled, post two lines saying so"), and resisting every temptation to add sections. A digest that is occasionally short is trusted; a digest that is always long is ignored.

People start performing for it. If the summary ever reads as a leaderboard, some people will optimize for appearing in Shipped, which means slicing work thinner rather than working better. This is why the per-person rollup ban belongs in the instructions and not just in your intentions.

Model output varies. Two runs over similar data can phrase things differently or make different judgment calls about borderline stalled items. Tight instructions, explicit thresholds, and success criteria narrow the variance; they do not eliminate it. If your team needs byte-identical deterministic output, this is a job for a workflow, not an agent, at the cost of the judgment the agent applies about what matters.

None of these are reasons not to build it. They are reasons to build it with drafts-only mode, tight budgets, versioned instructions, and a habit of reading the run reports for the first few weeks.

FAQ

How is this different from Jira or GitHub notification digests?

Native digests report one tool's events with no judgment and no memory. The standup agent reads across tools, GitHub and the board and the calendar together, applies your rules about what counts as stalled or blocked, remembers what it already reported so you get a delta instead of an inventory, and produces one message instead of three. The judgment layer, "flag this, skip that, keep it under 30 lines," is exactly what a notification digest cannot do.

Can it handle multiple teams or channels?

Yes, and the cleaner pattern is one agent per team rather than one mega-agent with routing logic. Each agent gets its own sources, thresholds, memory, and channel, and each stays simple enough to debug in one screen. In Skopx, the Create Agent workspace shows every agent in a rail beside the open one, so five small standup agents are as manageable as one. The tradeoff between one large agent and several focused ones is a general question; the short answer for standups is: several.

Does the agent post automatically or does someone approve each message?

Your choice, per grant. Set the Slack grant to run automatically and the message posts unattended each morning. Set it to ask first every time and the post parks as a pending approval showing the exact call and arguments; approving executes exactly that parked message once, rejecting executes nothing, and an ignored approval can expire. Drafts-only mode is the middle path while tuning. Most teams start with approval or drafts and move to automatic within a couple of weeks.

What does it cost to run daily?

The main variable is how much the agent reads each run. Because memory turns runs after the first into delta reads, a tuned standup agent is one of the cheaper agent patterns: small scope, one write, tight step count. In Skopx you cap it explicitly with per-run and per-day token budgets, and pick the model per agent, from Claude, GPT, Gemini, Kimi and others, either on your own API keys with zero markup or on the $16/seat Team plan with included tokens. A smaller model is usually fine for summarization work of this shape.

What if a run fails at 8:00 and nobody notices?

Every run lands in append-only run history with its report and its success-criteria evaluation, so a failed or budget-stopped run is visible the moment anyone looks. Three budget failures auto-pause the agent rather than letting it fail silently forever. The practical habit: if the summary is not in Slack by 8:05, the run page tells you why in one click, and pausing the agent is always available as a kill switch for anything queued.

The real payoff

The point of a standup summary agent is not saving fifteen minutes, although it does. The point is that the fifteen minutes that remain change character. When the state of the world is already posted before the meeting starts, the meeting can only be about the things the tools cannot see: the tricky decision, the blocked person, the thing someone is worried about but has not written down. That is the meeting standup was always supposed to be.

Start small: one board, one repo, one channel, drafts-only, 30-line cap. Read the drafts for a week, edit the instructions twice, then let it post on its own. If you want to see what else the same anatomy of triggers, grants, budgets, and memory can do, the agents overview is the place to look, and the morning brief and weekly retro patterns are the natural next agents once the standup one has earned its place.