PostHog Context Layer Review: The Semantic Layer for AI Agents

PostHog is no longer just a product analytics tool. With its context warehouse and semantic layer, it now aims to be the single source of truth that AI agents read before answering questions about your product. This review examines what that means in practice: who benefits, where it falls short, and how to decide if it fits your stack.

What the PostHog context layer actually is

First viewport screenshot of PostHog - your product’s context layer.

PostHog's context layer is a governed catalog of definitions that sits on top of your existing data. It tells both people and AI agents what metrics mean, which tables to trust, and how data sources connect. The semantic layer is the component that stores these definitions, and the context warehouse is where PostHog pulls together product events, imported sources like Stripe, and data models.

The core problem it solves is ambiguity. Ask three different AI tools "what was our MRR last month?" and you may get three different numbers because each tool invents its own definition. PostHog's semantic layer fixes this by giving every agent a single place to read the approved definition from.

How the semantic layer works

Definitions live as ordinary SQL tables. Metrics are a table, and there is no bespoke API to learn. If an agent can run execute-sql, it can read the entire semantic layer. Discovery becomes a query, not an integration.

When you create a metric from an insight, PostHog snapshots the insight's query and stores it server-side. The metric and the dashboard execute identical queries, so they stay in lockstep. If someone edits the underlying insight, the metric is flagged as drifted and a human must re-review it.

Governance guardrails

Nothing an agent creates becomes canonical on its own. Every agent-generated definition lands as proposed. A human must promote it to approved. Editing an approved metric drops it back to proposed. A result is only canonical when status = 'approved' and is_drifted = false. Everything else is labeled non-canonical.

Who should use PostHog's context layer

First viewport screenshot of Changelog - PostHog.

PostHog remains an engineer-led platform. The context layer is most valuable for teams that already have engineering capacity and a growing data stack.

Ideal users

• Engineering-led product teams that want analytics embedded in development workflows.
• Data teams with multiple sources (Stripe, Salesforce, HubSpot, product events) where metric definitions are inconsistent.
• Companies using AI agents for analytics who need deterministic, governed answers.
• PLG startups that have outgrown tribal knowledge and need a single source of truth.

Less ideal users

• Marketing-first teams whose primary need is traffic, campaigns, and conversions. Dedicated web analytics tools are faster and simpler.
• Non-technical PMs without engineering support. Custom instrumentation and SQL still require technical help.
• Small teams with a handful of tables that already know where everything is. The overhead may not be justified yet.

Key use cases

First viewport screenshot of Changelog - PostHog.

1. Consistent metric definitions across AI agents

The primary use case is eliminating the "three different MRR numbers" problem. When an agent checks the semantic layer first, it runs the governed definition instead of writing its own SQL. Same question, same number, every time.

2. Onboarding new analysts and agents

New team members no longer need to learn which revenue table is the real one. The semantic layer documents what each metric is, which tables to trust, and how sources join. This reduces the tribal knowledge burden.

3. Data governance at scale

As you add more data sources and models, the meaning of tables stops being obvious. The semantic layer provides a governed catalog with human approval, drift detection, and clear status labels.

4. AI-assisted analysis with guardrails

Agents can propose metric definitions, suggest canonical tables, and spot likely joins. But nothing becomes official without human approval. This balances automation with trust.

Strengths

• Deterministic answers: Insight-backed and SQL-backed metrics are more reliable than plain English definitions.
• Lockstep with dashboards: Metrics snapshot the insight query, so they cannot silently diverge.
• Drift detection: Live comparison flags when an insight changes underneath a metric.
• SQL-native: No new query language to learn. The semantic layer is queryable with existing SQL skills.
• Human-in-the-loop governance: Agents propose, humans approve. This prevents hallucinated definitions from becoming canonical.
• Open source foundation: PostHog remains open source, with self-hosting options.

Limitations

• Steep learning curve: The interface and concepts are complex. Non-technical users will struggle.
• Engineering dependency: Custom instrumentation, taxonomy, and SQL still require engineers.
• No semantic query language (yet): PostHog deliberately avoided building a dbt-like language in v1. In-editor composition of non-SQL metrics is not supported.
• Pricing unpredictability: Usage-based pricing across products can be hard to forecast at scale.
• Session replay costs: Can explode for consumer products with high user volumes. Mobile replays cost 2x web pricing.
• Data warehouse maturity: Less mature than dedicated warehouses like Snowflake or BigQuery.

Pricing signals

PostHog offers a generous free tier that resets monthly. Most early-stage startups can run on it for 6–12 months without paying.

After the free tier, pricing is pay-as-you-go. Product analytics is roughly $0.00005 per event ($50 per 1M events). Session replay starts at $0.005 per recording with volume discounts. Feature flags are $0.0001 per request after 1M free. Volume discounts can reach 82% at very high volume.

Add-on packages include Boost ($250/month), Scale ($750/month), and Enterprise (~$2,000/month base plus usage). Hidden costs to model include session replay volume, data warehouse sync rows, and implementation time (20–60 engineering hours).

Setup and instrumentation

Setup starts with installing the PostHog SDK. Auto-capture begins tracking raw data like clicks, page views, and errors immediately. But to get full value, you need custom instrumentation: defining events, ensuring consistent naming conventions, and avoiding duplicate users.

For the context layer specifically, the workflow is:

1. Create a saved view or insight that defines your metric.
2. Create a metric from that insight. PostHog snapshots the query.
3. Let agents propose additional definitions, but review and approve them manually.
4. Monitor for drift flags and re-approve when definitions change.

If you are comparing analytics platforms more broadly, see our Data4 vs Heap vs Piwik PRO comparison for a decision framework. For privacy-focused alternatives, the top 10 privacy-focused web analytics products roundup is useful.

Decision criteria: Is PostHog right for you?

First viewport screenshot of Changelog - PostHog.

Ask these questions before committing:

1. Do you have engineers who own analytics? If not, PostHog will create overhead.
2. Do you have multiple data sources with inconsistent definitions? If yes, the semantic layer adds real value.
3. Are you using AI agents for analytics? If yes, governed definitions prevent hallucinated numbers.
4. Can you tolerate usage-based pricing? If you need flat-rate predictability, consider alternatives.
5. Is your primary need product behavior or marketing analytics? PostHog excels at the former, not the latter.

For teams that need branded client reporting, a white label client analytics reports guide covers how to deliver analytics under your own brand.

Related reading

• How to Use Data4 with Optimizely: A Practical Integration Guide - Learn how to combine Data4 website analytics with Optimizely experimentation and personalization. Setup steps, workflow, examples, and key limitations.
• Data4 vs Fathom vs Piwik PRO: Best Privacy Analytics? - Data4 vs Fathom Analytics vs Piwik PRO compared: privacy, setup, event depth, compliance, and pricing. Find the right Google Analytics alternative.

FAQ

What is PostHog's semantic layer?

It is a governed catalog of definitions that sits on top of your existing data. It tells agents and people what metrics mean, which tables to trust, and how sources connect. It does not copy or move data.

How does PostHog prevent AI agents from hallucinating metrics?

Agents must check the semantic layer first. If an approved metric exists, they run the governed definition instead of writing their own SQL. Agent-created definitions are proposed until a human approves them.

What is drift detection in PostHog?

When a metric is created from an insight, PostHog snapshots the insight's query. If someone edits the insight later, the metric is flagged as drifted and needs human re-review.

Is PostHog free?

PostHog has a generous free tier that resets monthly. After that, pricing is usage-based across products. Most early-stage startups can use it free for 6–12 months.

Who should not use PostHog?

Marketing-first teams, non-technical teams without engineering support, and small teams with simple data stacks may find PostHog overly complex and expensive compared to dedicated alternatives.

Does PostHog support self-hosting?

Yes. PostHog is open source and can be self-hosted on your own infrastructure at no license cost.

Conclusion

PostHog's context layer and semantic layer represent a meaningful shift: from a product analytics tool to a governed context layer for AI agents. The strengths are real—deterministic metrics, drift detection, SQL-native design, and human-in-the-loop governance. The limitations are equally real—engineering dependency, a steep learning curve, and usage-based pricing that can surprise at scale.

If you have engineers, multiple data sources, and a growing need for consistent metric definitions across AI agents, PostHog is a strong fit. If you need simple marketing analytics or flat-rate pricing, look elsewhere. The decision comes down to whether you value governed context over out-of-the-box simplicity.

For further reading, see PostHog's official semantic layer announcement, PrettyInsights' PostHog review, and Userpilot's PostHog analytics deep-dive.