What Is PostHog? The Context Warehouse for AI Agents

PostHog is an integrated developer platform built to be a context warehouse for AI agents.

It unifies product analytics, session replays, feature flags, and a managed data warehouse, which hands autonomous development the two things it usually goes without: granular behavioral data, and the business logic that says why any of it matters. That is a different shape from the traditional monitoring suite, because an agent working inside it can go from watching something happen in production to executing code against it without ever leaving the platform.

The pitch is infrastructure rather than reporting, a self-driving system rather than a dashboard somebody opens on Monday morning. What it aims at is the gap most coding agents already live inside: an agent can read every line in your repository and still have no idea how any of those lines behaves once real users touch them. Because PostHog keeps the data streams in one place, an agent can diagnose a technical failure and then rank the work by real-world impact, instead of by code metrics that only ever describe the code.

PostHog stays firmly engineer-shaped, so raw data reaches you through SQL dialects and programmatic interfaces rather than through a curated dashboard, and a team that adopts it stops maintaining one vendor for telemetry and a second one for experimentation. PostHog wants to be the single layer an agent reads customer behavior through, and the one it writes pull requests out of.

A context warehouse unifying product behavior data and business context into one source an AI agent can read

What is PostHog?

PostHog is a developer platform that puts product and web analytics, session replay, feature flags, and experimentation on one data layer. It started life as a specialized analytics suite and has grown into a managed data warehouse and an infrastructure layer meant to cover the full product lifecycle. What you get out of that consolidation is mostly subtraction: you are no longer stitching together fragmented point solutions for telemetry, observability, and product growth, and no longer maintaining the glue that holds them together.

Today the whole thing is tuned for a self-driving product development model. PostHog aims to be the automated system itself rather than a visualization tool a human operator reads, so it runs scouts — scheduled agents that watch a slice of your data and raise a hand when something is worth knowing — and those scouts produce signals. A signal is a structured finding: what is happening, the evidence behind it, and a suggested action. Signals are what let the system interpret customer behavior, diagnose technical regressions, and propose autonomous code changes, so agents can prioritize engineering tasks by actual usage patterns and revenue risk rather than by whichever ticket happens to be loudest.

PostHog runs at real scale, with over 500,000 teams on it. Pricing is usage-based and climbs with volume: 10 million anonymous product-analytics events cost roughly $324.40 a month. There is a free tier of 1 million monthly events, but the platform is built for engineering-led organizations that want low-level control, including the ability to run complex behavioral queries in HogQL, PostHog's own SQL dialect.

Why AI agents lack product context

The bottleneck in agentic development is not the model, it is the context gap that fragmented data silos leave behind. The average organization runs 106 separate SaaS applications, which leaves billing, support, and analytics sitting in datasets that never meet. A general-purpose coding agent can read your source code through the repository, but it knows nothing about usage patterns or revenue, and without that visibility it cannot tell a critical regression on a high-value account apart from a minor bug hit once by a trial user who was churning anyway.

Data scattered across separate SaaS applications, leaving an AI agent able to read the repository but blind to user behavior and revenue

How unready that data is turns out to be measurable. About 56% of teams identify data quality as their most frequent challenge, and two-thirds of data professionals admit they do not completely trust the data powering their AI systems. Feed an agent numbers nobody trusts and what comes back is confident and wrong: a technically functional fix shipped for a low-priority error while a high-revenue funnel quietly drops off, because the business data that would have ranked those two against each other was never in reach.

Building more pipelines, which is the traditional answer, tends to make it worse. Around 70% of teams report that pipeline management is complex, and data engineers spend over half their time on repetitive maintenance tasks. Using AI to build those pipelines frequently leads to hallucinations, for the same reason: no context. So 42% of teams say more than half of their AI projects have stalled, not because the models fell short, but because the underlying data is unreachable or disorganized in a way no agent can parse.

How a context warehouse differs from a data warehouse

A traditional data warehouse is built for business intelligence and for the human data engineers who feed it. It is passive storage, and turning raw data into something usable takes ETL and modeling pipelines that somebody has to own. That leaves a structural gap between the data and the tools that use it, so you end up with frequent syncs and manual schema mapping, and the latency in that arrangement is exactly what stops an AI agent from acting on a behavioral signal while the signal is still real-time.

A traditional data warehouse with an ETL pipeline standing in between, beside a context warehouse where every tool reads one shared source

A context warehouse redefines the relationship by unifying ingestion, modeling, storage, and querying in a single environment. Product events are already there: ingestion is native, so no export job has to move data from an analytics tool into a separate warehouse. Every component of the stack, including feature flags, experiments, and agents, reads from the same source. The difference is not the storage engine; it is what is allowed to touch the data without a pipeline standing in between.

For an AI agent, that means the data is ready to query on arrival. A standard warehouse makes it work through complex joins across external tables before it can ask anything useful, while a context warehouse hands it a consistent schema in which behavioral identifiers and business logic have already been reconciled. The agent can do the modeling and the deciding itself, using native context to identify engineering priorities without waiting on data engineers to prepare curated tables.

What counts as context

To do autonomous work such as generating pull requests, an agent needs three distinct layers of context. Layer 1: product usage data covers the granular behavior of the product: events, session replays, error tracking, and survey feedback. This is the layer that shows the agent how the product actually behaves, and where users hit the kind of technical friction a standard warehouse never sees at all.

Three stacked layers of context: product usage data, warehouse imports from Stripe and HubSpot, and business data from Slack and Notion

Layer 2: warehouse imports syncs external data from production databases such as Postgres and MySQL, and from business systems like Stripe for billing or HubSpot for CRM. Aligning that data with product events is what lets the agent calculate the business impact of a technical issue, correlating a specific stack trace with the MRR (monthly recurring revenue) of the affected cohort, which is where revenue-aware prioritization actually comes from.

Layer 3: business data is the qualitative knowledge sitting in tools like Slack, Notion, and support tickets. It supplies the "why" behind the behavioral data, so the agent can read business intent and documentation instead of only outcomes. With all three layers unified, scouts read the combined context to produce signals, and those signals trigger the self-driving loop that lets an agent reason about development rather than merely complete code.

Why PostHog rebuilt its data warehouse

PostHog moved its data warehouse off a multi-tenant ClickHouse cluster and onto a single-tenant DuckDB-based system, because multi-tenancy was the thing breaking. ClickHouse is optimized for fast, short-lived analytical queries, and it struggles with long-running modeling queries that can run for hours. On a shared cluster, those heavy modeling jobs risked destabilizing the entire application, which meant the most sophisticated teams were quietly prevented from running complex transformations at all.

PostHog's rebuilt architecture: a per-organization DuckDB instance inside a Firecracker MicroVM, with storage partitioned on S3

The new architecture runs single-tenant DuckDB instances inside Firecracker MicroVMs, so each organization gets a fully isolated compute environment and one customer's modeling job can no longer degrade another customer's dashboard. The storage layer, DuckLake, separates compute from storage by partitioning data on S3. A lifecycle service manages the instances, letting them sleep when idle and wake in roughly 300ms when a query arrives.

To bridge the gap with standard BI tooling, PostHog implemented a Postgres wire protocol endpoint, which translates the Postgres catalog into DuckDB SQL so tools like dbt and Hex can introspect the schema and run queries as though they were hitting an ordinary database. Engineers keep the modeling tools they already like, while the underlying data stays unified inside PostHog. That is the polite version of a hard migration problem, and it is the right call.

For developers and agents that need fast local iteration, PostHog added DuckHog, a DuckDB extension that pulls subsets of warehouse data into local memory via pandas or polars. Agents can iterate on that data locally and write results back to the warehouse, which avoids the latency of round-tripping every query to the cloud cluster — the round trip a fast-moving agentic loop cannot afford.

How agents read the data over MCP

The way an agent actually reaches the context warehouse is the Model Context Protocol. PostHog runs a free, hosted MCP server that sits between the platform and agents running in clients like Cursor, Claude Code, or Zed. Through it, agents issue plain-text requests to query behavioral data, manage feature flags, and triage errors, and the developer never leaves the editor to do any of it.

The server exposes specialized tools, including query-trends, query-funnel, and execute-sql. The one that earns its keep is the actors variant each query tool carries, because it lists the specific person IDs behind a data point. If a conversion funnel drops, the agent can retrieve the exact users and session replays involved, then investigate the failure and propose a fix grounded in those users' stack traces rather than in a summary statistic that averages the problem away.

Integration runs through a setup wizard. You add the context warehouse to a local environment with a single command:

bash

npx @posthog/wizard mcp add

In a typical loop, an agent picks up a spike in errors from a scout, queries the warehouse for the affected code path, and watches session replays to see what the user experience looked like, then proposes a fix in the IDE. The loop only closes because the agent has programmatic access to query the warehouse for granular context over MCP.

What PostHog does not do

PostHog has structural ceilings, and they are worth weighing before you plan an architecture around it. Its semantic layer exists but is still in beta, and its governance model is deliberately human-gated: an agent can propose a metric, but nothing an agent creates is canonical until a person approves it, editing an approved definition drops it straight back to proposed, and a metric whose underlying insight changes gets flagged as drifted for re-review. That is a different maturity level from a settled dbt-based governance stack, and the burden of keeping a metric like churn consistent still lands on your engineering team.

The BI and data modeling side is still growing up too. PostHog says outright that its internal SQL editor and visualization tools are not yet equivalent to dedicated platforms like dbt or Hex, which I appreciate more than I would a marketing page claiming otherwise. If your transformations are complicated, the internal modeling will not be enough, and you will keep the specialized tools around for the advanced analytics.

Connector coverage is the other ceiling. PostHog's managed source catalog covers the common systems (Stripe, Postgres, Salesforce, HubSpot) but remains narrower than a dedicated ETL platform's, so niche tools and legacy enterprise systems may have no connector at all. There is a technical bar on top of that: DuckDB brings standard SQL, but PostHog's internal logic still leans on HogQL in many places, which is a barrier for non-engineering teams and takes dedicated attention to manage without running up usage costs.

When PostHog is the right call

PostHog is the right architectural choice for engineer-led teams that want product analytics coupled tightly to the development loop. It works best when the analytics you need are mostly product analytics and the team intends to run agentic, self-driving development cycles, because unifying the stack takes away the overhead of assembling a multi-vendor platform while giving agents the context layer they need in order to act.

If I were adopting it, I would start on Cloud and find the limits of the context warehouse there, before committing engineering effort to a self-hosted or more elaborate data stack. An organization that needs strictly governed business metrics across finance, operations, and executive reporting, or hundreds of niche connectors, will eventually outgrow this warehouse — but for rapid, agent-assisted product iteration, nothing else puts the behavioral evidence and the agent's reach over it in the same place.