What the agent does
No git repository is involved. The org admin connects Notion once (OAuth to the Notion MCP at https://mcp.notion.com/mcp), and the request names that connection. The agent searches the workspace for pages under a Meetings parent (or database) whose last_edited_time falls in the last 7 days, then reads each page's blocks: headings, bullets, to-do items and mentions.
Meeting pages that are templates, empty shells or titled only with a date and no body are skipped after a glance at their block count. Recurring series pages that accumulate many weeks of notes are filtered by the last-edited window so only the recent section's action items are considered, and the agent prefers explicit to-do blocks over inferring tasks from every sentence in the narrative.
From that text it extracts candidate action items: unchecked to-do blocks, lines that start with "Action:" / "TODO" / "Follow up", and sentences that assign work to a person ("@Alex to send…", "Sam will draft by Friday"). For each item it records the task text, the owner when a person mention or name is present, a due date when the notes state one, and a link back to the meeting page. Items that already appear in the Tasks database (same task text and owner, or an explicit link property pointing at the meeting block) are skipped.
New items are appended as rows in the existing Tasks database using the connection's write tools: task title, owner (people or text property, whichever the database already uses), due date when present, and a URL or relation back to the meeting page. The agent does not add properties/columns to Tasks, does not rename databases, and does not edit the meeting notes themselves.
When it finishes it can also write a short actions.md artifact listing what was added and what was skipped as duplicates, so a standup can scan the session without opening Notion. If Meetings or Tasks cannot be found, it stops with that error in the session result rather than creating new databases.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the Notion connection to read meeting notes under `Meetings` from the last 7 days. For each action item, add a row to the `Tasks` database with the task, owner, due date if stated and a link to the meeting page, skipping items already in `Tasks`. Do not add columns or edit the notes.",
"connections": [
"notion"
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is new rows in your Notion Tasks database, plus an optional actions.md artifact summarizing additions and skips. The session transcript shows each page read and each row created.
A reviewer opens Tasks filtered to today, spot-checks owners and due dates against the meeting page link, and deletes any false positive. Meeting notes remain unchanged.
If the Notion connection lacks write access to Tasks, the session ends with that error and no partial rows. Fix the connection's permissions and send a follow-up on the same session, or start a new run once the database is shared with the integration.
Run it on every end of each meeting day
A weekday evening cron sends this request with the Notion connection. Each run covers the trailing 7 days, so a late-edited note from yesterday is still picked up without double-creating rows already added.
On run.completed, if actions.md lists new rows, post that summary to the team channel so owners see assignments without opening every meeting page.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
Copying action items from Notion meeting pages into a task database by hand is where commitments disappear. The agent reads the week's notes through the connection and writes only the missing rows, with every read and write kept in the transcript.
It runs in an isolated sandbox using your Notion connection, not a shared integration token on someone's laptop. Several workspaces or teams can be processed in parallel with separate connections.
Frequently asked questions
Will it edit the meeting notes?
No. The prompt forbids editing the notes and forbids adding columns. It only creates rows in the existing Tasks database.
What if my folders have different names?
Say the real names in the prompt (Meeting Notes instead of Meetings, Engineering Tasks instead of Tasks). The sample uses the names from a seeded workspace.
How does it avoid duplicates?
It reads existing Tasks rows before inserting and skips items that already match on task text and owner, or that already link to the same meeting page. Re-running the job the next day should add only new commitments.
Does it create the Tasks database?
No. If Tasks is missing it fails closed and says so. Create the database (with the properties you want) once in Notion, then run this job against it.
Can it put items in different databases by meeting type?
One run targets one Tasks database as named in the prompt. For a second database, send another request with that name, or say in the prompt how to choose (for example engineering meetings go to Eng Tasks).