What the agent does
The run starts from a public adopters list and needs no repository of yours. Argo CD keeps its list in USERS.md at the root of argoproj/argo-cd: one numbered Markdown line per organization, 1. [Name](https://site), about 450 of them in alphabetical order under the heading "Who uses Argo CD?". The file holds a name and a homepage and nothing else, so the reason to write to each organization has to be found somewhere else, and that research is what the agent does.
The agent clones the repository into its sandbox with its history and takes the first ten entries of USERS.md. For each one it runs git log -S on that line to find the commit that added the organization, which names the pull request and its author. The project's pull request template, .github/pull_request_template.md, has a checkbox reading "My organization is added to USERS.md", so a row often arrives inside a contribution, and that pull request is the most specific public evidence of how the organization runs Argo CD. Then it opens the organization's own site and searches in its browser for engineering blog posts, conference talks and public job descriptions that mention Argo CD, keeping the URL of every fact it uses.
Before writing anything it opens the Notion database you named through the Notion connection and reads its schema: which properties exist and what type each one is. It then adds one row per organization, filling only properties that already exist, typically the organization name, its site, a short research note, the source URLs and a two-sentence first message. The message opens with the cited fact, such as a talk on managing many clusters with ApplicationSets or a pull request that fixed a sync issue, and asks one question. It adds no property and changes no select option.
Last, it sends you a Slack message through your own sign-in listing the ten new rows and asking you to approve them. It sends no outreach. An organization with no public evidence beyond its line in USERS.md still gets a row, marked as such in the research note, so a person decides whether a generic message is worth sending at all.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Clone https://github.com/argoproj/argo-cd with its history and read USERS.md. For the first ten organizations listed, find the commit that added each line with git log -S and note its pull request, then research the organization's public use of Argo CD: its engineering blog, conference talks and job posts. Keep the URL of every fact. Read the schema of the Notion database named below, then add one row per organization with a short research note, the source URLs and a two-sentence first message that cites the most specific fact. Fill only existing properties; add or change no property or option. Send me a Slack message listing the rows to approve. Send no outreach yourself.\n\nNotion database: Argo CD adopters",
"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 ten new rows in your Notion database. Each holds the organization, a research note naming where its use of Argo CD is documented, the links behind every claim, and a draft message short enough to read on a phone. Your Slack direct messages have the list from the agent, sent as you. The session's result, also in data.result on the run.completed webhook, is the agent's summary: which rows it added and which organizations had no public evidence beyond USERS.md.
The transcript at GET /o/{org}/sessions/{id}/messages keeps every git log the agent ran, every page its browser opened and every Notion call with its arguments. That is how a reviewer confirms that each fact came from the URL beside it and that the run wrote only new rows.
Before anyone sends, a person checks three things per row: that the cited talk or post is recent enough to mention, that the draft describes what your product does without overclaiming, and that the contact you will write to is a real public role and not a name pulled from a commit. Edit the draft in Notion, then send it yourself.
Run it on every new line in USERS.md
Adopters lists grow one pull request at a time. A scheduled job on your side can fetch USERS.md each Monday, compare it with the organizations already in your database, and start one run per new name with POST /o/{org}/sessions, sending the organization name as the Idempotency-Key so a rerun does not research it twice.
A key runs at most its max_concurrent sessions at once, 4 by default, and answers 429 past that, so the job should queue the rest and retry. Set a webhook on the key and your job hears when each run finishes, with its summary in data.result.
The use case this job follows, with its automation and trigger: Draft outreach from your CRM.
Why run it on Rush?
The research is the slow part. Turning a bare name in an adopters file into a reason to write means reading git history, a company blog and conference schedules, and doing it ten times over. A Rush run does that in its own sandbox with a real browser and a full clone, and every fact it keeps has the link that proves it, written straight into the database your team already works from.
The run's reach is what the request names: the Notion connection and your Slack sign-in, with tokens kept outside the sandbox. The record of each git log -S and each page visit stays with the session, so when someone asks where a claim in a draft came from, the answer is a link, not a guess.
Frequently asked questions
Does it collect personal email addresses from commits?
The prompt asks for organizations and their public use of the project, not for people's addresses, and you should keep it that way. Commit metadata includes author emails, which were not published for outreach; write to a public role or a published contact instead.
Will it change my Notion database's properties?
No. It reads the schema first and fills only properties that already exist, and the prompt forbids adding or changing a property or option. The transcript keeps every Notion call, so you can check.
Can I use another project's adopters list?
Yes. Change the repository and the file name in the prompt. Some projects keep ADOPTERS.md as a table with a description of use, which gives the agent a better starting fact; others link to case studies the agent can read first.
Does it send the messages?
No. It drafts and asks you in Slack to approve. Sending stays with a person, which keeps a stale fact or a wrong name from reaching anyone.