What the agent does
The changelog is attached to the run. POST /o/{org}/sessions takes input as a string or as blocks; the request below is the instruction string. In production you send a text block plus a document or file block, after uploading a private changelog with POST /o/{org}/files and PUT to its upload_url if it is not a public URL. The agent reads it from /workspace/.rush/attachments/
Resend is the MCP connection. The connector catalog lists an official server at https://mcp.resend.com/mcp, OAuth, covering emails, templates, contacts, broadcasts, automations, domains, segments, webhooks and logs. Resend's docs say the remote server is that same URL, and that a browser sign-in approves access. You create the connection with POST /me/connections and name it on the session. Resend's tool groups, as their docs describe them, include Broadcasts (create, send, list, get, update, remove) and Segments (create, list, get, remove). The prompt uses a segment named Customers, which is the audience the request means. The agent lists segments, finds the one named Customers, and does not create a segment if it is missing.
The email is a subject line and three to five short sections, each a change a user would notice, taken from the changelog and not from the rest of the product. The agent creates a broadcast draft aimed at that segment and does not call the send operation Resend documents on broadcasts. It writes the same subject and sections to product-update.md so the words are reviewable as a file. If the Customers segment is absent, it creates nothing in Resend, says so in the file, and lists the segment names it did see.
The return value the prompt asks for is the draft id from the create call. The agent also records the segment id it targeted. It does not schedule the broadcast, does not add contacts, and does not verify or edit the sending domain as a side effect of drafting.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Read the attached changelog. Write a product update email with a subject line and three to five short sections on the changes users will notice. List Resend segments, find the one named Customers, and create a broadcast draft to that segment. Do not send it, do not schedule it, and do not create a segment if Customers is missing. Return the draft id and the segment id. Also write the subject and sections to product-update.md. If Customers does not exist, write the segment names you found and create no broadcast.",
"connections": [
"resend"
]
}- 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
product-update.md comes back as an artifact, with the subject, the sections, the segment id, and either the draft id or the statement that Customers was not found. result on the session repeats the draft id so the webhook payload can carry it. result is omitted from the webhook once it passes 16 KiB; a short id will fit, and the file remains the full copy. The artifact url on api.prix.dev needs no key and lasts an hour.
A reviewer reads the sections against the changelog that was attached (the session's attachments list has its own url) and checks the transcript for a broadcast send. Resend's docs list send as a separate broadcast operation from create. The draft in the Resend dashboard should match product-update.md and should show the Customers segment, not a segment the agent created. No contacts were imported.
Sending stays in Resend, done by a person, or in a later message to this session that explicitly says to send that draft id. The sandbox parks for 7 idle days with the changelog still attached, so a wording change does not require a new upload unless the file itself changed.
Run it on every changelog entry marked ready
The job that publishes your changelog also starts this session, with the changelog file uploaded first and the changelog version as the Idempotency-Key. A repeated publish hook returns the run that already drafted that version. The next version uses a new key, because a completed run keeps the key it started with.
Give the API key a webhook_url. run.completed carries session_url and, when it fits, result with the draft id. Your handler verifies the signature, writes the id onto the changelog ticket, and links product-update.md. A missing Customers segment is still a completed run whose file lists the real segment names; it is not run.failed, and the handler should surface that sentence instead of retrying forever.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
A monthly product update is a changelog condensed into a broadcast, and the Resend screen that creates a broadcast is the same place that sends one. The prompt splits those: create a draft to the Customers segment, do not send. The changelog file and the Resend connection meet only inside the sandbox. The connection's token is not in the session response.
The draft id is the proof the object exists, and product-update.md is the proof of what the words were at draft time. If someone later edits the broadcast in the dashboard, the file is the version the agent proposed. You can draft more than one product's update at once, each its own session, until the key's max_concurrent (default 4) returns 429.
Frequently asked questions
Will it send the broadcast?
No. The prompt forbids send and schedule. Resend's documentation lists send as its own broadcast operation, so a reviewer can search the transcript for that call. The dashboard should show a draft. A person sends it after comparing the dashboard with product-update.md.
What is the Customers audience if Resend talks about segments?
The connector catalog and Resend's MCP docs describe segments, not a separate audience object, for this kind of grouping. The prompt's Customers audience is the segment whose name is Customers. The agent lists segments and uses that id. It does not create one, and it does not guess a similarly named segment without saying so.
The changelog is private. How does the agent see it?
POST /o/{org}/files returns an upload_url. You PUT the bytes with the file's Content-Type, then pass the file id as a file block in input. The agent sees it at /workspace/.rush/attachments/
Can it update an existing draft instead of creating another?
Not with this prompt, which says to create a draft. Resend's docs also list an update operation on broadcasts. A follow-up message can name the draft id and ask for an update, which is how you avoid a pile of drafts for one changelog version. Keep the Idempotency-Key stable for the first create.