What the agent does
Each run handles one prospect. Your request names the row (the company name or the row's link goes after the instructions in input) and two connections: the Notion MCP server, whose tools search, read and update pages and databases, and your own Slack sign-in. A key run reaches only the connections it names, so this run can read and write Notion and message you in Slack, and nothing else you have connected.
The agent opens the Prospects database through Notion, finds the row, and reads what is already there: the company's name and website, any notes a person left, and the schema itself, so it knows which columns exist and what their types are. Then it researches the company in its sandbox's browser: the company's own site (about page, product pages, careers page, recent posts) and public news. It picks three facts that bear on why your product matters to them now, a new product line, a hiring push in a specific team, a funding announcement, and keeps the URL each one came from.
It writes those three facts, each with its source link, into the row's Research column and a first message under 120 words into Draft. The message opens with the most specific fact, says in one sentence what you do that connects to it, and ends with one plain question. It fills only those two existing columns: it adds no column, changes no select option, and leaves Status, owner and every other field to you, because a CRM's schema is the team's agreement and an agent that edits it breaks every view and filter built on it.
Last, it sends you a Slack message with the row's link and the draft's first line, asking you to approve. The message goes out through your own Slack sign-in, as you, to you. The agent never sends the outreach email or LinkedIn message itself; a person reads the sources, edits the draft and sends it.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Read the CRM row named after this prompt in the Notion database `Prospects` through the Notion connection. Research the company on the web: its own site and recent public news. Fill the row's existing `Research` column with three facts relevant to a first sales conversation, each with its source URL, and the existing `Draft` column with a first message under 120 words that opens with the most specific fact and ends with one question. Do not add or change columns, select options or any other field. Then send me a Slack message with the row link asking me to approve. Do not send any outreach yourself.\n\nRow: {company}",
"connections": [
"notion",
"slack"
]
}- 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 the row itself, updated in Notion: Research holds three facts with links you can click to check, and Draft holds the message. The Slack message is in your direct messages with the row link. The session's result is the agent's final answer, a short summary of what it wrote and which row, and it arrives in data.result on the run.completed webhook if your key has one.
The transcript at GET /o/{org}/sessions/{id}/messages keeps every Notion call with its arguments, every page the browser opened and the Slack message it sent, so you can see where each fact came from and confirm that it touched only the row it was given.
Before sending, you check that each fact is current and matches its source, that the draft does not overclaim what your product does, and that the tone is yours. If a fact is wrong, delete it in Notion; if the draft is close, edit it in place. Marking the row as sent is your job, which keeps the CRM's status column a record of what people actually did.
Run it on every new row in the Prospects database
Notion's database automations can call a webhook when a page is added to a database. Point one at a small handler on your server that takes the new row's title and sends the request above with it, one run per row. Send the Notion page id as the Idempotency-Key header so a duplicate webhook does not research the same company twice.
If you would rather batch, a scheduled job each morning can query the database for rows with an empty Draft and start one run for each. A key runs at most max_concurrent sessions at once (4 by default) and answers 429 past that, so the job should queue and retry on 429.
The use case this job follows, with its automation and trigger: Draft outreach from your CRM.
Why run it on Rush?
Research and a first draft are the slow part of outbound for a small team: twenty minutes per company to read their site and find a reason to write. Running it as an agent on Rush means each prospect is its own run in its own sandbox with a real browser, started by an event in your CRM rather than by someone remembering to do it, and the result lands where your team already works.
The proof is the sources. Every fact in Research has a link, and the trajectory keeps the pages the agent read, so a claim in a draft can be checked before it reaches a prospect. The run's access is narrow and explicit: the two connections in the request, your Notion and your Slack, with tokens kept outside the sandbox.
Frequently asked questions
Will it change my Notion database's columns?
No. The prompt tells it to fill only Research and Draft and to add or change no column or option, and a reviewer can confirm this in the transcript, which keeps every Notion call. Name your own column names in the prompt if they differ; it reads the schema first and stops with a message if a named column does not exist.
Does it send the email for me?
No, by design. It drafts, and the Slack message asks you to approve. Sending stays with a person, which keeps a wrong fact or an awkward line from reaching a prospect, and keeps your sending reputation in your hands.
Who does the Slack message come from?
From you. Rush reaches Slack through your own sign-in, so the agent posts as you, to you; there is no separate bot user to install. Connect Slack once, then name it in connections on each run.
Can it use our sales playbook?
Yes. Put the playbook's rules in the prompt (who you sell to, which facts matter, what never to say), or save an agent with those instructions and both connections and send its id as agent. A saved agent keeps the brief in one place, so every run uses the same version of it.