What the agent does
The job starts with two inputs and no code change. The repository is a Next.js app like umami-software/umami: Next.js 16.3.4 with pnpm 12.3.4 on Node 22, Prisma 7.10.0 against Postgres, and the app code under src/app with colocated tests for the API route modules. The other input is the PostHog connection: PostHog is one of the built-in connectors, described as querying product analytics, feature flags, experiments, error tracking and logs. Naming it on the run gives the agent the signup funnel, the week's recordings and the event properties for the accounts that stalled.
The agent reads the funnel first. Through the connection it pulls the signup funnel for the week before the drop and the week of it, step by step, and finds the step where users vanish: a form step that lost a third of its completions reads very differently from a tracking gap where the events simply stopped firing. Recordings for sessions that reached the lost step are sampled next, and the agent watches what those users actually saw: a validation error, a spinner that never resolves, a button that does nothing. Error tracking and logs in the same connection cover the other flank, whether the step started throwing client-side.
Then the repository side. With the step named, the agent runs git log over the signup path in this repository, the route module, the form component and the API handler behind it, and correlates commits against the day the funnel broke. A change merged the morning the drop started is the prime suspect, and the agent reads that diff rather than guessing: what the commit touched, which of the funnel's events it could plausibly break, and whether a config or feature-flag change shipped beside it. Where the app is instrumented through its own tracker, the agent confirms the events the funnel counts actually correspond to the code paths that fire them.
The report it writes carries the numbers: the funnel step counts for both weeks and their ratio, the recordings sampled and what they showed, the commits in the window with the one it indicts and why, and the checks that would confirm or clear it. Nothing is committed to the repository; the run's output is the report artifact and the evidence trail.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Signup conversion fell this week. Through the PostHog connection, read the signup funnel and recordings for the week before and after, find the step that lost users, find the commits that touched that step in this repository, and write a report with the numbers and the likely cause. Change no code.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- 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 result is a report artifact with the funnel numbers for both weeks side by side, the step where the loss concentrates, a small set of session recordings described by what they show, and a short list of commits that touched that step with one named as the likely cause and the reasoning. Where the evidence is ambiguous, the report says what would disambiguate it: a flag to toggle back, a revert to try, a log line to add. The agent changed no code, and the report says so.
A reader checks the correlation before the conclusion: the funnel timestamps and the commit dates should line up to the day, and the indicted diff should plausibly affect the events the funnel counts. The transcript is the second artifact: every query to PostHog and every git command is recorded there, so the numbers in the report are traceable to the calls that produced them. If you disagree with the suspect, a follow-up on the finished turn can ask the agent to re-examine a different commit or widen the window.
Run it on every funnel drop alert
Set the PostHog insight that watches the signup funnel to alert when a step drops past a threshold, and have your alert handler send POST /o/{org}/sessions with this prompt. The run names the PostHog connection and the app repository, so the investigation starts from the alert's own numbers instead of a human restating them. Install the Rush GitHub App on the repository first and authenticate with an API key; an Idempotency-Key header keeps a retried alert from starting two investigations.
Keep the returned execution_id and read the session when the run settles, or receive the key's completion webhook. Each alert opens its own investigation with its own evidence trail, so a noisy week produces parallel reports you can compare rather than one muddled one. A follow-up on a finished turn can ask the agent to dig into a specific segment, such as mobile sessions only.
The use case this job follows, with its automation and trigger: Investigate an incident.
Why run it on Rush?
This investigation lives in two systems at once: the analytics product holding the funnel and the repository holding the code, and the answer only exists where they join. On Rush the agent reads PostHog through the named connection and the code through the repository clone in the same sandbox, with every query and command kept in the transcript, so the report's numbers trace to real calls instead of a screenshot pasted from a dashboard. Because the run changes nothing, it is safe to fire on every alert.
For a portfolio of apps, submit one investigation per funnel per run within your key's concurrency allowance and a bad week becomes a set of parallel reports rather than a queue. The read-only constraint is what makes that safe: no run can ship a fix you did not ask for. The useful proof is the correlation, funnel break to commit, with the disambiguating experiment named.
Frequently asked questions
Does the agent change any code?
No. The prompt is explicit and the use case is a report with evidence: the agent reads the funnel and recordings through the PostHog connection, reads the repository, and writes a report. If you want the fix after reading the report, that is a follow-up run.
What does the PostHog connection give the agent?
The built-in PostHog connector queries product analytics, feature flags, experiments, error tracking and logs. Named on the run, it lets the agent pull the funnel for both weeks, sample session recordings at the lost step, and check whether the step started throwing, all with the same sign-in.
How does it know which commit caused the drop?
Correlation, not certainty: the funnel says when the step broke, and git log over the signup path says what changed that day. The report names the prime suspect with the reasoning and, where the evidence is ambiguous, the check that would settle it. The commits are quoted so you can vet the diff yourself.
What if the events just stopped firing?
That is one of the two patterns the agent distinguishes: a tracking break, where events stop rather than users stalling, points at instrumentation or a config change rather than the form itself. In umami's case the app carries its own tracker, so the agent can confirm which code path fires the funnel's events and check whether that path changed.
Can it investigate just one segment?
Yes. A follow-up on the finished turn can scope the next pass to mobile sessions, a locale or a traffic source; the messages endpoint wakes the parked sandbox with its PostHog connection still in place.