What the agent does
No repository is involved. The agent works through your PostHog connection, PostHog's remote MCP server at mcp.posthog.com, which Rush lists among its connectors for querying product analytics, feature flags and experiments. You connect it once and name it in the request's connections; the run gets that connection and nothing else, and the prompt keeps it to reading.
It first checks that the events the funnel needs exist and are named the way the prompt says. It looks for $pageview events whose $pathname is /signup (or whose $current_url ends in it, for projects that do not send $pathname), and for the custom signed_up and onboarding_completed events, and it reports how many of each it found in the last 30 days. A step with no events usually means a different event name, and the agent says so before running a funnel that would show a meaningless zero.
Then it runs the funnel through PostHog's query tool (query-run in PostHog's MCP source), as a funnels query over the three steps, ordered, counted per person, with the project's conversion window, over the last 30 days. It reads the conversion from each step to the next and overall, picks the step with the largest absolute drop, and runs that one step again broken down by $browser, $device_type and $initial_referring_domain. Segments too small to mean anything, below a size it states in the report, are grouped as other, so a single visitor on an unusual browser does not top the list.
Last, it looks for a likely cause in the data it can see: whether the drop is concentrated in one browser or device, whether one referrer brings visitors who leave at a much higher rate, and whether the time from one step to the next is unusually long. It writes funnel.md with each query it ran, so the numbers can be reproduced in PostHog.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the PostHog connection. First count, over the last 30 days, $pageview events on /signup and the signed_up and onboarding_completed events, and stop to report if any step has none. Then run the funnel $pageview on /signup, then signed_up, then onboarding_completed over the last 30 days, ordered and counted per person. Write funnel.md with conversion at each step and overall, the step with the largest drop, that step's conversion broken down by $browser, $device_type and $initial_referring_domain with small segments grouped as other, the median time between steps, and every query you ran. Read only: create, change or delete nothing in PostHog.",
"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
What comes back is funnel.md, an artifact on the session with a download link valid for an hour. It starts with the funnel itself: people at each of the three steps, conversion from step to step and end to end, and the median time between steps. The next section names the step with the biggest drop and shows its breakdowns by browser, device type and initial referrer, each as a small table of segment, people entering, people converting and conversion rate.
The findings section turns those tables into a few plain statements, such as which segment converts far below the rest at the worst step, each with the numbers behind it. The appendix holds every query the agent ran, so an analyst can paste one into PostHog and see the same result. The session's transcript records each call to PostHog with the response it returned.
Before acting on it, a reviewer checks that the event definitions match how the product is instrumented (a signed_up sent from the server has no browser, which skews a browser breakdown), that the 30-day window is not dominated by one campaign, and that a segment's gap is large enough to matter. The report gives a cause to test, not a verdict; the test itself is an experiment or a fix.
Run it on every Monday morning
Funnel drop-off moves with releases and campaigns, so a weekly run is a useful habit. Have a scheduler on your server send this request every Monday morning with an Idempotency-Key built from the week, so a retry does not start a second run.
Put a webhook URL on the API key and Rush POSTs run.completed with the session_url and the agent's summary as result. Your server posts the summary to the growth channel with a link to funnel.md, and the weekly files together show whether a change moved the worst step.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
Answering where users drop off means building the funnel, then re-running the worst step with one breakdown after another, then checking the event names when something looks wrong. The agent does that whole loop in its own sandbox through a connection you approved once, with no personal API key pasted into a notebook.
The result is a report with its evidence: every number comes with the query that produced it, and the run's record keeps each call and response. Several funnels, or several products, can run at once, one run each, up to the key's concurrent run limit, and each comes back as a file the team can read without opening PostHog.
Frequently asked questions
What if my events are named differently?
Change the event names in the prompt. The agent counts each step's events before running the funnel and stops to report when one has none, which is the usual sign of a different name or a step that is only sent from some platforms.
Will it create insights or dashboards in my PostHog project?
No. The prompt makes the run read only, so the agent only runs queries and writes the report into its sandbox. If you want a saved insight, ask for one in a follow-up message to the same session.
How does the run reach PostHog?
Connect PostHog's MCP server once with POST /me/connections and "auth": {"mode": "oauth"}, and open the authorize_url it returns while signed in to the console. Then name it in connections, posthog here. Only runs that name it can use it.
Can it break down by a property of my own, like plan or country?
Yes. Add the property to the prompt, such as a person property for plan or $geoip_country_code, and the agent adds that breakdown for the worst step with the same small-segment grouping.