Auto-post your weekly sprint status with a scheduled Notion Custom Agent

Notion Custom Agents (available on Business/Enterprise since February 2026) can run on a weekly schedule to query your Sprint Tasks database, tally status buckets, surface blockers, and write the report to a Notion page or Slack — no human in the loop. This tip covers the 5-step setup, a copy-paste instruction block, minimum-permission configuration, and the key gotcha around schedule vs. database-event triggers.

リサーチノート

Your sprint database already has everything — status, owner, due date, blockers. The problem is that surfacing it still takes a human: someone filters the view, copies the highlights, pastes them into Slack or a standup page, and ships it before Monday's planning call. With Notion Custom Agents (generally available since February 2026), you can hand that loop to an agent that runs on a schedule and writes the report for you. 1

What the agent does

Once configured, every Monday at 8:55 AM the agent:
  1. Queries your Sprint Tasks database — filters for the current sprint, groups by status (In Progress, Blocked, Done)
  2. Counts items in each bucket and surfaces any row where the Blocked checkbox is checked or the status is At Risk
  3. Writes a formatted status update to a designated Notion page (or sends it to a Slack channel via the Slack integration)
  4. Marks a Last Reported date property on each row it processed
The whole run takes under two minutes and costs roughly 5–15 Notion Credits depending on database size. 1

Prerequisites

RequirementDetail
Notion planBusiness or Enterprise — Custom Agents are not available on Plus or Free 1
Notion CreditsFrom $10 / 1,000 credits (as of May 4, 2026); workspace-level pool, resets monthly
Sprint Tasks databaseMust have Status, Sprint (relation or select), Owner (person), and optionally a Blocked checkbox property
Slack integrationOnly if you want the report posted to Slack; optional

Setup: 5 steps

Step 1 — Create the agent
Open the left sidebar → click Agents+ → choose Start from scratch. Give it a descriptive name: Weekly Sprint Reporter.
Step 2 — Write precise instructions
Vague instructions are the single biggest cause of poor agent output. Use @mentions inside the instruction text to reference your actual database by name — the agent will request read access when you save. A working instruction block:
Every Monday before standup, query @Sprint Tasks. Filter for rows where Sprint = "Current Sprint".
Group results by Status property. Count rows in each status.
List all rows where Blocked = checked or Status = "At Risk", including the Owner and Due Date.
Write a summary to @Weekly Status Updates (page). Format:
- Sprint: [sprint name]
- Done: [N]
- In Progress: [N]
- Blocked: [N] — list each blocked item with owner and due date
- At Risk: [N] — list each item with owner and due date
After writing, update the Last Reported property on each processed row to today's date.
Step 3 — Add the schedule trigger
Click Add trigger → select On a schedule → set to Every week → Monday at 8:55 AM in your workspace timezone. Save.
Step 4 — Grant minimum permissions
By default the agent has zero workspace access. After saving, Notion will prompt you to grant access to any @mentioned page or database. Give:
  • @Sprint TasksCan edit content (the agent needs to write back the Last Reported date)
  • @Weekly Status UpdatesCan edit content
Do not grant workspace-wide access. Limit to these two objects only.
Step 5 — Test before Monday
Click Run agent in the agent editor. Watch the step log in the chat pane. On first run it will ask a clarifying question if your sprint name filter is ambiguous — answer once and it will remember. Check Recent Activity to verify the output page was updated correctly.

The gotcha: pre-created meeting/sprint pages

If you create sprint pages before the sprint begins (common for planning), the "page added to database" trigger fires at creation time — before any tasks exist. The schedule trigger avoids this problem entirely: it fires when you tell it to, independent of when pages were created. This is why a schedule trigger is the right choice for reporting, not a database event trigger. 1

Credit cost management

Each Custom Agent run consumes credits based on the number of database rows scanned, tools invoked, and steps executed — not a flat fee. 1 Two ways to keep costs down:
  • Scope the filter tightly. Sprint = "Current Sprint" returns 20-40 rows, not your entire backlog of 400.
  • One agent, one task. Splitting a "report + triage" mega-agent into a Reporter and a separate Blocker Triager is cheaper per run because each agent handles fewer steps and makes fewer AI model calls.

What to build next

Once the reporter runs reliably for two sprints, layer on a second agent triggered by a database property change: when any row's Status flips to Blocked, fire immediately — query the row, draft a Slack message to the owner with the blocker context, and write a summary comment on the page. The two agents chain without calling each other directly: Agent A writes to the database → Agent B watches the database. 1
That's the pattern Notion Custom Agents are designed for: discrete, single-purpose tasks that hand off through shared data, not through direct agent-to-agent calls.
リンクプレビューを読み込んでいます…

このコンテンツについて、さらに観点や背景を補足しましょう。

  • ログインするとコメントできます。