What the agent does
Your backend starts one run when a user signs up, with their name, email and company domain after the prompt. There is no repository: the run uses its browser to read the company's website, and the Resend connection to send the email. Resend's MCP server, connected once with OAuth, gives the agent the account's emails, domains, contacts, templates and logs.
The agent reads the signup's company site first: the home page, the product or about page, and anything that says what the company does and who it sells to. It picks one specific, true detail to mention, such as the product they sell or the stack they build on, and one next step in your product that fits what it read. If the site does not load or says too little, it writes a plain welcome without a company detail rather than inventing one.
Before it sends, it reads the Resend account to send the way you already do. It lists the account's domains and uses a verified one for the from address, so the email does not fail on an unverified sender. It reads the recent sent emails in the logs to match the length, greeting and sign-off your team already uses, and keeps the body under 100 words as the prompt asks.
Then it sends one email through Resend to the signup's address and returns what it sent: the subject, the body and the Resend email id. It sends to that address only, sends once, and adds nothing to an audience or broadcast.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A user signed up; their name, email and company domain follow this prompt. Read the company's website with the browser, then send one welcome email under 100 words through Resend, from a verified domain on the account, that mentions one true and relevant thing about their company and one next step in the product. Match the tone of recent sent emails in the Resend logs. If the website says too little, write a plain welcome with no company detail. Send to that address only, once. Return JSON with subject, body and the Resend email id."
}- 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 agent's final answer, a JSON object with subject, body and the Resend email id, and the email itself in the signup's inbox. Your backend receives the object as data.result in the run.completed webhook and can store it on the user's record, so support can see what the new user was sent.
The Resend email id ties the run to Resend's own record of the delivery, so a bounce or a complaint on that message can be traced back to the run that sent it. Before turning this on for every signup, read a sample of results against the company sites they cite and check the detail is accurate and the next step makes sense.
The session keeps every page the browser opened and every Resend call the agent made, so for any email you can see what the agent read before it wrote. A run that failed to send ends run.failed, and your webhook hears that too.
Run it on every new signup
Your signup handler calls POST /o/{org}/sessions once per new user, with their name, email and company domain added to input. Send the user's id as the Idempotency-Key, so a retried signup event returns the run already started instead of sending a second welcome.
Set a webhook on the API key and your backend receives each result when its run finishes, with no polling. A key runs at most max_concurrent sessions at a time, 4 by default, and starting one more answers 429, so queue signups in your backend and start the next run when one finishes.
The use case this job follows, with its automation and trigger: Run an agent per customer task.
Why run it on Rush?
A personal welcome needs someone to read each new user's company site and write two lines about it, which stops happening once signups pass a handful a day. A Rush run does both for every signup in its own sandbox with a browser, and sends through the Resend account and domain you already use.
Each email comes with its record: the pages read, the Resend calls made and the email id. That is what makes it safe to automate a message that goes to a real person under your name, because any email can be checked against what the agent saw.
Frequently asked questions
How does the run get access to Resend?
Connect Resend's MCP server once with POST /me/connections, "type": "mcp", the server URL and "auth": {"mode": "oauth"}, then open the authorize_url while signed in to the console. A key run gets only the connections it names, so name it in connections on the run, or save an agent that names it and run that agent.
Could it email someone other than the new user?
The prompt limits it to one email to the signup's address. The session records every Resend call, so you can check that each run sent exactly one email to the right person.
What if the company website is empty or blocks the browser?
The prompt tells the agent to send a plain welcome with no company detail, so it does not make one up. The session shows which pages it tried to open and what they returned.
Does this need a repository or GitHub?
No. A run with no repository in resources needs no GitHub App. The run uses its browser and the Resend connection only.
Can I review emails before they go out?
Yes. Change the prompt to return the subject and body without sending, review them in your backend, and send the approved ones as a follow-up message to the same session asking it to send.