Improve your product on AutoPilot with Posthog
PostHog just showed what product automation looks like when it is done honestly: agents that observe real user behavior, propose concrete changes as pull requests, and measure whether each change worked after it was merged. If it did not work, the system generates new signals and evaluates a rollback. Nobody touches production until a human presses "merge." They called it "self-driving mode," and it is worth taking the time to understand why that architecture matters beyond the world of product engineering.
The difference between an agent that proposes and one that acts
Most conversations about AI automation collapse into one of two extremes: the assistant that needs manual instructions for every task, or the "autonomous" agent that makes changes without supervision and nobody quite knows what it touched. PostHog built something in between, and the structure of that middle ground is what makes it interesting.
The system starts with what they call Signals: raw observations about product behavior. They can come from error tracking (exceptions with their stack traces), from session replay (dead clicks, stalled sessions), or from external tools like Zendesk, Linear, or GitHub. The agent is not inventing a problem: it is reading what is already happening. From those signals, Scouts running with persistent memory convert them into reports that land in an Inbox, already deduplicated and grouped. From there, the agent proposes a PR. The PR reaches the human. The human decides.
What makes the loop complete, rather than just the expensive half, is the post-merge stage: every change that enters production carries its own instrumentation, PostHog measures whether the target metric actually moved, and if it did not, that generates new signals. The system closes the loop on its own outputs. That discipline of measure-and-consider-rollback is what separates an honest workflow from one where agents "do things" and the team never quite knows whether they worked.
Why the architecture matters more than the name
"Self-driving" is a marketing name, but the underlying design has three principles worth attention: observation grounded in real data (not agent assumptions), proposal instead of action (PRs rather than direct changes), and post-hoc validation with the possibility of reversal. The three together form an epistemological stance: the agent does not know whether its proposal is good, and the system is designed to discover that empirically rather than assume it is.
On security and privacy, PostHog made reasonable decisions for the beta stage: execution environments are isolated, customer code and data are not used to train models, and the agents respect the branch protections and CI rules the team already has in place. The most eloquent proof point is that PostHog itself uses the system on its own repository: there are merged PRs covering caching, web analytics, cohorts, and feature flag infrastructure. This is not a controlled demo. It is the product applying itself to itself.
The read for growth, paid media, and martech
PostHog's offering is specifically about product code. It does not run on Google Ads accounts, it does not touch Meta Business Manager, it does not move budgets or creatives. That detail matters: a paid media or growth practitioner who reads this as "there are already agents managing my campaigns autonomously" is reading something the page does not say.
What it does say, and this is what is relevant for the broader ecosystem, is that the architecture of the loop exists and works. Observe-propose-gate-measure-rollback is a reproducible pattern. There are already signals that something equivalent is arriving in the ads and martech world: platforms that generate creative variants, tools that suggest bid adjustments, or the ads MCP servers that allow an agent to read and write across advertising accounts through natural-language instructions (see our note on ads MCP servers). The question is not whether that loop will reach client accounts. It is which version of the loop will prove durable.
The durable version looks like what PostHog built: an informed human who approves, and an objective measurement that judges whether the change was worth making. The version that will generate "the agent wrecked the campaign" headlines is the one that skips one of those two.
The governance question the page does not answer
The system is in beta, and the per-completed-pull-request pricing model is unusual. It is not yet clear how it scales when PRs are complex or when the Inbox fills with contradictory signals. It is also unclear how much weight the agent carries in prioritizing which Signals deserve a Scout and which are noise: if that prioritization is opaque, the human at the gate is approving or rejecting proposals without knowing why the agent chose that problem and not another.
The most open question is one of governance: who on the team has access to the Inbox, and how will anyone audit, six months from now, which PRs the agent opened, which were merged, and what changed in the metric. The measurement loop exists, but the historical traceability of the human decisions inside that loop is not documented in what the page shows today. That is something any organization adopting this class of tool will have to resolve on its own, regardless of what the platform offers by default.
Sources
This content was developed with AI assistance and reviewed by the Zenda team. The bad ideas are 100% ours.