What this agent does

A Notion daily rollup agent reads activity across a fixed set of databases and produces one dated summary page. It is the moral equivalent of the standup notes a team writes at the start of every day, except the team does not have to write them. The agent reads the source of truth (the databases the team is already updating) and surfaces what changed.

The output is opinionated. It is not a dump of every edit. It is grouped by status transition: new this window, finished this window, blocked or stuck this window. Items that only had a title typo fixed are mentioned in a single line, not enumerated.

For a related pattern in a different surface, see AI agent for Slack triage. For meeting-specific rollups, see AI agent for meeting follow-ups. For the cluster context, see what an AI agent can actually do.

Notion integration permissions

Notion's API uses an internal integration model where each integration is granted access to specific pages. There are no workspace-wide scopes. This is a feature, not a limitation, and the agent should respect it.

The integration the agent uses needs three connections, no more.

The Notion API rate limit is approximately 3 requests per second per integration, per Notion's published documentation. A rollup agent stays well under this with one query per source database, one page-create per day, and a few block-append calls. There is no need to batch unless the workspace has hundreds of source databases, in which case the agent should run them in serial with short pauses.

Rollup window and query

The rollup window is 24 hours, ending at the team's local end-of-day. For a team in Asia/Calcutta, that is 23:59 IST; for a team in America/Los_Angeles, that is 23:59 PT. The agent runs at the start of the next day and queries each database with a filter.

The filter uses Notion's last_edited_time property with an on_or_after condition set to the start of the window. This returns every row that had any change during the window, including property edits, content edits, and status changes.

The agent then groups the returned rows three ways:

The transition logic is the hardest part. Notion's API does not natively expose property-change history; the agent has to maintain its own snapshot of each row's status from the prior run. The snapshot is a small JSON blob stored on the Rollups parent page as a hidden child block.

Output format

One rollup page per day, named with the ISO date (2026-05-12). Under it, four headings:

  1. Shipped today. A bullet list of rows that moved into a terminal state (Done, Shipped, Closed) during the window. Each bullet is the title, linked to the source row, followed by the database name in parentheses.
  2. Started today. Rows that were newly created during the window. Same format.
  3. Blocked or at risk. Rows that moved into Blocked, Stuck, or At Risk. Same format. If empty, the heading is omitted.
  4. Minor edits. A one-line summary per database: "Tasks: 14 edits, no status changes." A reader who wants detail can open the database directly.

Three constraints on the output. No emoji. No promotional language ("amazing day!"). No interpretation ("the team is on track"). The agent reports what changed. The team interprets.

Deduplication across runs

An agent that runs once a day is rarely robust to operational reality: outages, manual re-runs, time-zone clock changes, daylight-saving transitions. The dedup logic has to handle all four without creating duplicate pages.

Fingerprint. The agent identifies each rollup page by ISO date plus the hash of the source database IDs. If a re-run finds an existing page with the same fingerprint, it updates that page rather than creating a new one. The update is a destructive replace of the rollup blocks, not an append.

Backfill. If the agent missed days (outage during a weekend, for example), the operator can pass a date range and the agent runs once per missed day. Each backfill run uses the same fingerprint logic, so re-running a backfill is safe.

Catch-up safety. A re-run during the day (operator wants a fresh summary mid-day) updates the page with the partial window. The page header is annotated "Updated 2026-05-12 14:30 IST" so the team knows it is not final.

Guardrails

Five guardrails keep the agent out of the workspace's hair.

Common mistakes

Posting to every database's parent page. A rollup belongs in one place. Posting an updated summary into each source database creates noise and breaks the source-of-truth pattern.

Using created_time when you wanted last_edited_time. A row created two weeks ago and updated today shows up under last_edited_time but not under created_time. The rollup wants both, querying on edited time and bucketing on created time for "new today."

Enumerating minor edits. A bullet per edit produces a 200-line page no one reads. Collapse to "N edits in this database" and link to the database. Detail is one click away.

Letting the agent interpret. "The team had a productive day" is interpretation. The agent does not have the data to make that claim. Restrict the agent to reporting.

Forgetting time zones. A team in Bangalore that uses a UTC rollup window sees their morning's work in the next day's rollup. Set the window to the team's local time zone, configured once.

Frequently asked questions

What does a Notion daily rollup agent actually do?

It queries a fixed set of Notion databases (tasks, projects, meetings, journal) for changes in the last 24 hours, summarises the changes into a single dated rollup page, and links back to the source rows. It does not modify the source databases. It does not generate new pages outside the rollup tree. The output is one new child page per day under a Rollups parent.

Which Notion API capabilities does the agent need?

It needs an internal integration with read access to the source databases and write access only to the Rollups parent page. Notion's permission model is per-page, so the integration is added to the source databases as a reader and to the Rollups page as an editor. No workspace-wide admin access is required.

How does the agent know what counts as a meaningful change?

The agent queries each database with a last_edited_time filter set to the rollup window (the last 24 hours), then groups rows by status transition. New, in-progress to done, and blocked are reported. Title-only edits and minor property changes are summarised in a single 'minor edits' line rather than enumerated.

Does the agent write back to source rows?

Not by default. The agent is a one-way consumer for the first 30 days. After calibration, an opt-in mode allows the agent to set a 'Last summarised' timestamp on rows it has covered, which prevents the same change from being summarised twice across overlapping windows. Status edits or content edits to source rows are out of scope.

How does the agent avoid spamming the workspace with rollup pages?

It writes to a single parent page called Rollups and creates exactly one child per day, named with the ISO date. If the agent runs more than once in a day (catch-up after an outage, manual re-run), it updates the existing child page rather than creating a new one. The fingerprint that prevents duplicate pages is the ISO date plus the database set.

Three takeaways before you close this tab

Sources

The same shape, applied to other tools and surfaces: