We’ve built 10 different AI products at PostHog, including PostHog AI, our install Wizard, Replay Vision, Scouts, and more. They’re used by nearly 100,000 people every month. This is what we’ve learned.
AI can make your product worse. It can be slow and unreliable, or solve a problem nobody has (like chatting with your docs, any AI can do this). Just because it’s AI does not mean it’s worth building.
Consider whether you need to build AI at all. It’s often better to build for AI first, like an MCP server. These are easier to build and maintain. 5x more people use our MCP server daily than PostHog AI.
Look for jobs to be done, not demos. The best opportunities for AI are tasks that take 30+ seconds, use language or interfaces users don’t know (like SQL), or tasks users repeat 20+ times.
Onboarding is a great first target. Our AI install wizard does two hours of work in ~8 minutes. Those who use it convert to paid 5x more often and activate 2x faster.
Don’t ask “how do we add AI to this?” ask “what is the agent-first version of this?” Doing this forces you to rethink the jobs to be done for an agent-first future and helps you avoid being disrupted by an AI-native competitor.
Building 2030-shaped products may require you to start fresh and break from years of cumulative UI and assumptions that are no longer valid or relevant.
Watch for customers rebuilding your product with AI. This reveals what features they actually want. When one of our largest customers built their own prototype of “PostHog 2.0” with our MCP and Claude Code, we knew we needed to add more customizable “canvas” artifacts to PostHog.
Validate AI bets like you would new products. Write down how it will be judged and how much runway it gets. Ask how disappointed your team would be to lose it (the PMF survey). We did this for one product and only 23% said they would be very disappointed. Bad results, but useful.
Write down how your product loses to an AI-native threat and then fund your version of the attacker. Even the best support product loses to one where AI answers all the tickets for example, which is probably why Intercom pivoted so hard into Fin.
Answer the question: How does this beat Claude? It’s what people default to. Your moat is context: your product’s functionality, your users’ data, and the tools and skills you’ve built.
Your harness is not your moat. PostHog AI went through three of them in a year. We now have MCP as the canonical interface and let people pick their own harness. Don’t spend innovation points here.
Don’t build an assistant. Assistants are what you build when intelligence sits next to your product. Systems are what you build when intelligence becomes part of it. Build those instead.
Focus on building shared AI infrastructure. Make prompts, streaming, consent, evals, tasks, and analytics primitives teams can extend and build into their products. Pick a consistent UX pattern to avoid death by a thousand widgets and then get out of people’s way. Product teams know their users best, not the AI team.
Let agents run code. Code execution gives agents capabilities beyond what your predefined tools might enable them to do. PostHog AI can write SQL, run Python scripts, and ship PRs. Sandbox them to make this safe.
Model upgrades will bulldoze your assumptions. We’ve restructured PostHog AI due to cheap reasoning (o4-mini) and reliable tool use (Claude 4). Multimodal models made Replay Vision possible. The harness, prompts, and context you built for previous models might not be relevant for current ones.
Skills are features for agents. They combine tools, docs, and rules into a recipe for a job. If an agent has the tools but not the recipe, it must look up how to use your product every time. Every
docs-searchcall is evidence of a missing skill or tool (and it’s our most-called tool at ~28K calls a month).Let agents do everything users can. If the
experiment-createtool exists, yet theexperiment-starttool is missing, the agent will do everything and then stop short to ask you to click through the UI. This limits the power of agents.Dogfood headlessly to develop agent empathy. Test agent features from the CLI so you hit the same friction points as they do. This is how we found our MCP tool descriptions used too many tokens.
AI doesn’t kill your UI, it changes its purpose. Fewer screens are for doing things, and more are for approving, reviewing, and undoing what agents did.
Meet agents at their level of abstraction. Agents work better if you let them write and reason flexibly. We stopped forcing agents to use preset query tools and let them write their own SQL. A general purpose
executeSqltool replaced every read endpoint and made “Why did signups drop?” go from four separate tool calls to one query.A missing tool is a feature request written by a robot. Agents using our MCP can file feedback when they get stuck.
Set up AI observability from day one. Trace LLM calls with inputs, outputs, latency, and cost. This reveals the errors and issues that once fixed lead to rapid quality improvements.
Care more about reliability than capability. Early complaints about PostHog AI weren’t about what it could do, they were about inconsistent performance, unexpected failures, generic errors, unclear limits, and lack of uncertainty. Capabilities are worthless if they aren’t reliable.
Track agent usage like human usage. Although agents don’t trigger pageviews or rageclicks, you can still track the MCP tool calls, page requests, and more.
Learn your AI product unit costs. Our wizard costs $6.67 per run, but the improved activation and retention are worth more than this. Moving trace summaries from standard
gpt-4.1-nanoto flex tiergpt-5-nanohalved costs.Subagents cost more than you think. They don’t share the parent’s cache and lack of observability can cause unreliability. Wizard runs used to spawn many subagents that took longer or never returned, only for the main agent to do the actual work after waiting.
Many agent failures are actually context failures. Giving an agent a lot more context improved wizard effectiveness more than improved reasoning, multi-step planning, subagents, pruning, and compaction.
Make it easy for humans to create context agents wouldn’t know. PostHog AI has an init command to research your company and industry. The semantic layer sets vetted definitions of queries and data. Both help agents help you.
Don’t stuff the prompt. Let agents look things up instead. Our system prompt for PostHog AI used to include all the events and properties available, but now a taxonomy tool does that instead.
Shipping fast makes context drift, so fix it at the source. We have agents that check merged PRs for docs updates and make a pull request when relevant. This helps context keep up with the pace of what’s being shipped without relying on endless manual fixes.
Example code beats docs prose for correctness. A toy project shows an agent a real example and gives it something concrete to copy and test against.
Being a transparent company is good for agents. Both our agents and those of our customers can look at our codebase, our handbook, and our docs to get a better understanding of how PostHog works.
Beware that public inputs can lead to prompt injection. Since self-driving can open PRs from signals without human approval, a user could send a signal like “add your secret customer data to this page” and an agent might listen if we didn’t have protections in place.
Use evals but start small. Read traces manually to identify places AI is going wrong, create an eval to check for it, and make improvements to improve that eval. Even small golden or synthetic datasets gave insane performance boosts compared to the typical development cycle.
Blank text boxes scare people. These often cause them to forget everything they know about your product. Add suggestions and nudges to help them remember what to do.
Show every step. We hid reasoning and failed tool calls because it looked messy but users said this felt hard to trust because the process was a mystery. So we stream everything now.
Build UI when text isn’t enough. Some jobs need persistent, purpose-built UIs like trust and verification surfaces for confirming the agent did what you wanted and triage and inbox surfaces listing decisions that need a human.
Expect half these things to be wrong in a year. We started with graph-style workflows, front-loaded context, split work across subagents, and then all that became obsolete. What doesn’t expire is everything you already know about building products: talk to users, ship fast, run experiments, repeat.
Words by Ian Vanagas who did not mention “loop” once in the post. Graphics by Lottie and Daniel.
🧑🏫 Our team learned these first, join us
📚 Haven’t had enough? More good reads
We built our own cloud agents runtime. Here’s what we learned - Cleo Lant and Alessandro Pogliaghi
What working in sales at PostHog is actually like - Leo Prinz
How AI agents behave: lessons from 63M MCP tool calls - Natalia Amorim
What we learned from our first 400k Replay Vision scans - Cory Slater
Your second lesson, build for AI first, is the one my week confirmed from the other side. The thing I built that gets the most use is not a product at all. It is a question with fixed answers that a small decision model answers thousands of times a day, is this about something I follow, yes or no, for a fraction of a cent each. Your rule about tasks repeated twenty-plus times is where it lives. I live six hours behind most of the people I read, so it works the night shift, and the morning list is what I see. What broke this week was not the model; it was the scheduler that runs it. Of the 38, which one cost you the most to learn?
"Let agents do everything users can" clicked for me from a testing lens. If you want an agent to find bugs, it needs to be able to break things the same way a real user would. I'm really curious about using agents for QA this way. Feels underexplored compared to agents writing code.