What the agent does
PostHog's remote MCP server, https://mcp.posthog.com/mcp, is the PostHog entry in the Rush connector catalog, and it can query product analytics as well as flags and experiments. Connect it once with POST /me/connections ("type": "mcp", name posthog, that URL, "auth": {"mode": "oauth"}) and sign in to PostHog. PostHog's own skills, bundled with Rush, come with any run that reaches its server.
The agent runs the same four measurements for two windows, the last 7 days and the 7 before. Weekly active users is distinct persons with any event in the window. Signups is a count of the event your product fires on account creation, which the agent finds by name among the project's events or takes from the prompt. Activation rate is the share of that week's signups who also fired the activation event within the week. The top 10 events are counted by volume, leaving out PostHog's built-in events whose names start with $ unless the prompt says to keep them.
Each measurement is a HogQL query the agent writes and runs, so the report can show it. When it has both weeks, it computes the change for each number as an absolute and a percentage, and then looks for the movements worth a person's time: a large swing in a small number is reported with its size so it is not overread, and a change in one event that lines up with a change in activation is called out together.
The prompt says to create no insight or dashboard, so the agent only queries. It writes metrics.md in its sandbox with the numbers, the changes, the three movements it picked and the query behind each.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the PostHog connection to compute, for the last 7 days and the 7 days before: weekly active users, signups (the user_signed_up event), the activation rate (signups in the week who also fired project_created within the week), and the 10 most frequent events, leaving out built-in events whose names start with $. Write metrics.md with each number for both weeks and its change, then the three changes most worth investigating, each with the HogQL query behind it and one sentence on what to look at next. Read only: create no insight, dashboard or cohort.",
"connections": [
"posthog"
]
}- 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
The session returns metrics.md as an artifact. The first section is a table of the four measurements for both weeks with the change. The second lists the top events with their counts and changes. The third is the three movements the agent picked, each with its query in a code block, so anyone can paste it into PostHog and see the same number.
The transcript keeps every query and its result, which matters when a number surprises someone in the Monday meeting. Before sharing the report, a product lead checks that the signup and activation events in the prompt are the ones the team actually uses, since those two definitions decide half the report.
Run it on every Monday morning
An automation with a schedule trigger in a Project sends the request every Monday at a cron like 0 7 * * 1 in your timezone. Each run computes both windows fresh, so a late-arriving event from last week is counted the next time rather than missed.
Give the key a webhook URL; Rush POSTs run.completed with the session_url when the turn ends. Your server can read the session, take the first table out of metrics.md and post it to the product channel, linking the full file.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
A weekly metrics email usually means a dashboard someone built once and nobody updates, or an analyst spending Monday morning on the same queries. The agent writes the queries, runs them in its own sandbox through the connection, and explains the changes in words, with the query beside each claim.
Because it creates nothing, the PostHog project does not fill up with one-off insights. Products with separate PostHog projects can start one run per project at once, up to the key's concurrent run limit, and each report stands on its own record.
Frequently asked questions
Our signup and activation events have different names. What do I change?
Only the prompt. Replace user_signed_up and project_created with your event names, or describe the activation step in words and let the agent find the matching event. The report states which events it used.
Will it create insights or dashboards in PostHog?
No. The prompt says to create none, and the agent runs its queries directly. The transcript shows each tool call, so you can confirm nothing was saved.
Can it compare against the same week last year?
Yes, if the project has the data. Add the window to the prompt; the agent runs the same queries over it and adds a column.
How does it pick the three changes worth a look?
By size relative to the number's usual level and by whether changes line up, such as a drop in one step and a drop in activation the same week. It says why it picked each one, so you can disagree.