Posthog AI advanced context engineering

Feature request

Is your feature request related to a problem?

Our org makes heavy use of PostHog’s data warehouse sources, and many of those datasets correspond to KPIs we previously tracked (or still track) via product analytics events.

When using PostHogAI, we often ask questions using internal business terms (metric names/aliases specific to our company). PostHogAI often interprets these correctly, but sometimes it appears to favor the product analytics/event-based version of a KPI even when we’d prefer the warehouse-backed definition (e.g., because the event-based KPI is legacy/outdated).

This isn’t a huge issue for technical users who can sanity-check queries and sources, but it becomes a real barrier for non-technical colleagues trying to self-serve. They may not know which definition PostHogAI chose, or how to correct it, which can reduce trust and adoption.

Describe the solution you'd like

A way to provide curated org- or project-level context that PostHogAI can use when interpreting our terminology and choosing between multiple possible KPI definitions/sources.

What would be helpful for us:

• A business glossary (internal terms + aliases) that PostHogAI can reference

• A way to express source-of-truth preferences (e.g., “For KPI X, prefer warehouse model/table Y over legacy event Z”)

• Optional notes on relationships/caveats for key warehouse tables/models (what they represent, how they join, known gotchas)

• Ideally this context is explicitly curated, not automatically expanded from individual chats (current memory can be too eager to persist one-off chat details globally)

Describe alternatives you've considered

• Relying on PostHogAI memory today: helpful sometimes, but hard to keep “global” memory clean/curated; it can pick up chat-specific details that shouldn’t become durable guidance.

• Keeping template prompts in internal docs elsewhere: works for humans, but doesn’t directly help PostHogAI disambiguate terms or prefer the correct data source.

• Using local agents with Posthog mcp: this allows us to use traditional agents.md/skills patterns. This is equally unfriendly for non-technical users

Additional context

We’ve been thinking about where this context could live. A few possibilities:

• Single “AI context” document per project (similar to an AGENTS.md / agent skills pattern)
  • Could contain glossary + “preferred metric definitions” + deprecations
  • Distinct from chat memory; edited intentionally
• Context/annotations attached to warehouse sources
  • Per table/model notes describing what it represents, how it relates to other sources, and which KPIs it powers
  • Could also fit alongside a “models” concept if that’s the direction PostHog is going
• Sync an external Git repo
  • Engineers could maintain context/definitions alongside schema/model changes
  • Brings versioning/review workflows and automatic updates

Happy to provide concrete examples of KPI collisions (event-based vs warehouse-based) if that would help.

Debug info

- [ ] PostHog Cloud, Debug information: [please copy/paste from https://us.posthog.com/settings/project-details#variables]
- [ ] PostHog Hobby self-hosted with `docker compose`, version/commit: [please provide]
- [ ] PostHog self-hosted with Kubernetes (deprecated, see [`Sunsetting Kubernetes support`](https://posthog.com/blog/sunsetting-helm-support-posthog)), version/commit: [please provide]

No implementation files, tests, or entry points are named. Start by reviewing the existing PostHogAI memory and warehouse-source behavior, then compare the proposed glossary, source-of-truth preferences, annotations, and external Git synchronization; done means a concrete, intentionally curated context mechanism is defined.