What the agent does
The run needs no repository. It starts in the agent's own cloud computer with the target keyword in the prompt and one named connection, Semrush, which Rush lists as a read-only remote MCP server that spends the connected account's API units. The agent cannot edit anything in Semrush; it can only look things up.
It begins with the keyword itself: search volume and keyword difficulty, which set expectations for how hard the page will be to rank. Then it widens out through Semrush: related keywords that share the same intent, and question keywords people search around the topic. It groups them as it reads, so "how long to proof sourdough" and "sourdough proofing time" end up as one topic to cover instead of two headings.
Next it reads the pages that already rank. Semrush gives the URLs in the top 10 for the keyword, and the agent opens each one with the computer's browser, the way a writer would, and reads its headings, how long it is, what it answers and what it leaves out. This is the step that turns keyword data into a brief: the gaps in the top pages are what a new page can win on.
Last it writes brief.md and returns it as an artifact on the session: a working title, an H2 outline in order, the related terms to use and where, the questions to answer with the heading each belongs under, and what the top pages miss. The keyword data it used is in the brief too, so the writer and the editor see the same numbers.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "The target keyword follows this prompt. Use the Semrush connection to read its volume and difficulty, related keywords and question keywords, and the URLs ranking in the top 10. Read those pages, then write brief.md with a title, an H2 outline, the related terms to cover, the questions to answer and what the top pages miss.\n\nKeyword: sourdough starter",
"connections": [
"semrush"
]
}- 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 brief.md, an artifact on the session with a download link valid for an hour, refreshed each time the session is read. It has a header with the keyword, its volume and difficulty as Semrush reported them; a proposed title; the H2 outline; a table of related terms grouped by subtopic; the questions to answer, each placed under an outline heading; and a section on what the current top 10 pages miss, each point naming the pages it was observed on.
An editor reads it for intent before handing it on. The outline should match what searchers want (a how-to keyword needs steps, a comparison keyword needs a table), and the gaps should be real gaps rather than things the top pages cover under another heading. Because every top page the agent read is listed by URL, both are quick to check.
The session's transcript holds every Semrush call with the data returned and every page the agent opened in the browser. A writer who wants more than the brief, such as the full related-keyword list, finds it there.
Run it on every keyword added to the content plan
Briefs are needed one keyword at a time, as the plan grows. A webhook trigger on a Project automation gives you a URL to POST to: have your content calendar or a form send the keyword as the body, and the body becomes the event text the run receives. Each keyword starts its own run and ends with its own brief.md.
Or call the API from your own tooling: put the keyword after the prompt, send the request, and set a webhook URL on the API key so run.completed tells your system the brief is ready to fetch from the session's artifacts.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
A good brief takes keyword data and a careful read of ten competing pages, and the second half is what usually gets skipped. On Rush the agent does both in its own sandbox with a real browser, and the transcript keeps the Semrush responses and the pages it read, so the brief's claims about the top 10 can be checked against them.
Twenty keywords in a quarter's plan become twenty runs started at once, each in its own sandbox, each returning a brief built the same way. Writers start from data instead of a guess, and nobody spends a day collecting it.
Frequently asked questions
Do I need a Semrush account?
Yes. The run reads through your Semrush connection and spends that account's API units. The key's creator connects it once with POST /me/connections, and the request names it in connections.
Does the agent write the article too?
Not in this request: it returns the brief, and the article is a separate job. You can send a follow-up message to the same session asking for a draft from the brief, and the agent continues in the same sandbox with everything it already read.
Can it target a country other than the US?
Semrush keeps separate databases per country. Say which one in the prompt, for example the UK database, and the agent asks Semrush for that market's volume, difficulty and rankings.
What if a ranking page blocks automated browsers?
The agent notes in the brief which pages it could not read and builds the gaps section from the ones it could. The brief never describes a page the agent did not open.