PostHog added Model Context Protocol (MCP) support to expose product analytics, session replays, error tracking, and feature flags as agent-queryable context. This creates an architectural boundary problem: agents need observability data to debug and optimize products, but the observability system must also track agent behavior without creating circular dependencies where agent queries generate new events that agents then query.
The repo (37.8K stars, trending #12 in Python) explicitly positions observability as agent infrastructure. The description says agents need context to "diagnose problems, uncover opportunities, and ship fixes." The self-driving mode turns product signals like rage clicks and failed queries into researched reports and pull requests.
The Circular Dependency Problem
Traditional observability tools assume human operators query dashboards. When agents query the same data programmatically, three failure modes appear:
- Event pollution: Agent queries generate analytics events (page views, API calls, feature flag evaluations) that pollute the dataset agents are analyzing.
- Cost spiral: Session replay queries or SQL warehouse access can trigger expensive operations. Agents without cost awareness will exhaust rate limits.
- State drift: Agents that read feature flags or experiment assignments may inadvertently change user bucketing if the observability system tracks flag evaluations as events.
PostHog's MCP integration must enforce read boundaries and filter agent-generated traffic to avoid these loops.
MCP Server Architecture
The MCP server exposes PostHog data through three tool categories:
| Tool Type | Scope | Write Access | Rate Limit Risk |
|---|---|---|---|
| Analytics queries | Event data, trends, funnels | Read-only | Medium (SQL execution cost) |
| Session replays | Video playback, console logs | Read-only | High (storage bandwidth) |
| Feature flags | Flag state, experiment results | Read-only (likely) | Low (cached lookups) |
The server likely runs as a sidecar or proxy that authenticates against PostHog's API. Agents call MCP tools like query_events, fetch_replay, or check_flag_state. The server translates these into PostHog API calls or direct database queries.
Query Boundary Enforcement
To prevent feedback loops, the MCP server must:
-
Tag agent traffic: All agent-initiated requests carry a metadata tag (e.g.,
source: mcp_agent) so PostHog can filter them from analytics datasets. - Disable autocapture: Agent sessions should not trigger session replay recording or automatic event capture.
- Use service accounts: Agent API keys should map to non-user accounts that do not participate in experiments or flag evaluations.
Without these boundaries, an agent analyzing conversion funnels would see its own API calls as user events.
Self-Driving Mode Plumbing
PostHog's self-driving mode watches for product signals (errors, rage clicks, failed queries) and generates reports or pull requests. The flow likely looks like this:
# Simplified self-driving agent loop
def self_driving_loop(posthog_client, mcp_server):
signals = posthog_client.query_signals(
filters=["error_rate > threshold", "rage_click_detected"],
exclude_source="mcp_agent" # Avoid feedback loop
)
for signal in signals:
# Fetch context via MCP
replay = mcp_server.call_tool("fetch_replay", {
"session_id": signal.session_id,
"include_console": True
})
# Analyze and generate report
report = analyze_signal(signal, replay)
# Create PR (external tool, not MCP)
if report.confidence > 0.8:
create_pull_request(report)
The agent queries PostHog for anomalies, uses MCP to fetch session replays and logs, then generates a report. The key is the exclude_source filter that prevents the agent from analyzing its own queries.
Rate Limiting and Cost Control
Session replay queries are expensive. A single replay can be hundreds of megabytes of video and console logs. If an agent runs a batch analysis across 1,000 sessions, it could exhaust bandwidth or storage quotas.
PostHog's MCP server likely enforces:
- Query quotas: Maximum number of replays per hour or day.
- Sampling: Agents can request replay metadata (duration, error count) without downloading full video.
- Lazy loading: Replay data streams incrementally rather than loading entire sessions upfront.
The MCP protocol supports streaming responses, so the server can send replay chunks as they are fetched from storage.
Feature Flag and Experiment Access
Feature flags introduce a write boundary question: can agents toggle flags or create experiments via MCP, or is access read-only?
Read-only access is safer. Agents query flag state to understand why a user saw a particular UI variant, but they cannot change flag rules. This prevents agents from accidentally disabling features or corrupting experiment assignments.
Write access would allow agents to create experiments or adjust flag rollout percentages. This is powerful but risky. An agent optimizing conversion rates could create dozens of overlapping experiments, invalidating statistical significance.
PostHog's MCP integration likely starts with read-only flag access and adds write capabilities behind explicit user approval gates.
Observability of Observability
PostHog must track agent behavior without creating infinite recursion. The solution is a separate telemetry stream:
- Agent activity logs: Track which tools agents call, query latency, and error rates. Store these in a separate table or namespace.
- Cost attribution: Tag agent queries with the originating workflow or user so teams can see which agents are expensive.
- Audit trail: Record all agent-initiated changes (if write access is enabled) for compliance and rollback.
This telemetry stream does not feed back into the main analytics dataset that agents query.
Deployment Shape
The MCP server can run in three configurations:
- Sidecar: Deployed alongside PostHog's main application, sharing the same database connection pool.
- Standalone proxy: Separate service that calls PostHog's public API. Easier to scale independently but adds network latency.
- Embedded: MCP server runs inside the PostHog application process. Lowest latency but harder to isolate failures.
PostHog's architecture (Django backend, ClickHouse for analytics, Postgres for metadata) suggests the sidecar model. The MCP server can query ClickHouse directly for analytics and Postgres for feature flag state.
Failure Modes
| Failure | Symptom | Mitigation |
|---|---|---|
| Agent query loop | Analytics dataset grows exponentially | Tag and filter agent traffic |
| Replay bandwidth exhaustion | Storage costs spike | Enforce query quotas and sampling |
| Stale flag state | Agents see outdated experiment assignments | Cache invalidation on flag updates |
| SQL injection via MCP | Malicious agent queries corrupt data | Parameterized queries, query allowlists |
The SQL injection risk is real. If agents can construct arbitrary SQL queries via MCP, a compromised agent could exfiltrate data or corrupt the warehouse. PostHog likely restricts agents to predefined query templates with parameter substitution.
Technical Verdict
Use PostHog's MCP integration when:
- You are building agents that need to understand user behavior, errors, or feature flag state to make decisions.
- You already use PostHog for product analytics and want to expose that context to agents without building custom APIs.
- You need session replays and console logs as debugging context for agent-generated reports.
Avoid it when:
- You need agents to write feature flags or experiments programmatically. The write boundary is unclear and risky.
- Your agents run high-frequency queries (multiple times per second). The MCP server is designed for context retrieval, not real-time streaming.
- You cannot enforce agent traffic tagging. Without it, you will pollute your analytics dataset with agent-generated events.
PostHog's MCP integration is a concrete example of retrofitting observability tools for agent access. The key insight is that agents need observability data as context, but the observability system must also track agent behavior without creating feedback loops. The solution is strict read boundaries, traffic tagging, and separate telemetry streams.
Top comments (0)