September 2026 Summaries

PostHog’s analysis of 63 million MCP tool calls from 130,000 people over 90 days found that AI agents, primarily operating through code editors and terminals rather than chat interfaces, are increasingly interacting with product data and features. After excluding PostHog’s own automated traffic, Anthropic-based clients accounted for roughly half of third-party calls, followed by OpenAI at 25%, with Claude Code and Codex leading individual clients. Agents relied heavily on raw SQL and schema inspection while making limited use of the platform’s many specialized tools, though they created substantially more analytics insights, dashboards, actions, and experiments than human web users. Codex-generated requests had the lowest error rate among third-party clients, while SQL queries caused more failures than schema discovery, and agents often successfully recovered by retrying failed calls. The study also found that a small number of dashboard-related operations generated a disproportionately large share of returned tokens. In response, PostHog introduced MCP Analytics, a beta monitoring feature that records tool-call events, client activity, errors, response sizes, and agent sessions to help MCP providers identify usability problems and improve agent-facing tools.

Ella, a technical customer success manager at PostHog with a background in sales and no engineering degree, argues that becoming technical in customer-facing roles is primarily a matter of developing practical habits rather than completing formal training. She recommends working with technical products and customers, independently investigating technical questions before escalating them to engineers, and using lean-team constraints to build problem-solving skills and credibility with engineering colleagues. She also highlights AI-assisted “vibe coding” as a useful learning tool when used to build and maintain real solutions that regularly encounter problems, forcing users to troubleshoot and understand systems. Rather than mastering every technical discipline, she says effective technical CSMs need a solid foundation, adaptability, curiosity, and an understanding of how product components fit together to help customers gain value.

Technical account managers (TAMs) help customers implement, optimize, troubleshoot, and expand their use of increasingly complex technical products, particularly as SaaS pricing shifts toward usage-based models and larger long-term contracts. They work closely with engineering teams on implementation planning, cost optimization, integrations, migrations, bug resolution, training, and proactive account monitoring, sometimes reducing customer spend when it improves trust and renewal prospects. TAMs overlap with customer success managers, forward-deployed engineers, support engineers, and account executives, but typically combine technical expertise with sustained ownership of specific customer relationships. At PostHog, TAMs also hold commercial responsibility, acting as technical salespeople who manage accounts after landing, drive product adoption and expansion, and may contribute fixes directly to the product. Successful TAMs generally have senior technical or customer-facing experience, can build scripts, write SQL, create sample applications, analyze dashboards, and balance humility with persistence when solving customers’ long-term problems.

Answer engine optimization is presented as a promising but highly difficult-to-verify marketing discipline because no reliable public data shows which prompts people actually submit to large language models, making common metrics such as visibility, citation rate, and average rank dependent on selected prompt sets and methodological assumptions. While AEO can produce genuine business value, including sign-ups, referral traffic, and self-reported attribution, the author argues that public claims of success can be easily manufactured by choosing favorable prompts, competitors, models, dates, samples, and metrics, then implying causation from loosely related changes. The piece distinguishes brand visibility, which measures whether a brand is mentioned, from citation rate, which measures whether a brand’s URL is linked, and average rank, which measures placement among recommended options. It advocates for greater skepticism, clearer methodological context, and greater reliance on measurable business outcomes despite their attribution limitations, while noting that emerging approaches such as agent-level measurement and improved data reconciliation may eventually make AEO reporting more trustworthy.

Replay Vision is PostHog’s AI layer for Session Replay, using configurable scanners to watch individual recordings and produce observations such as labels, scores, summaries, or yes-or-no findings with cited evidence. After analyzing more than 400,000 recordings internally, PostHog found that useful scanners require a narrow, observable question, a carefully targeted set of relevant sessions, and the ability to return “no” or “inconclusive” rather than generate speculative findings. The guidance emphasizes that humans must define product-relevant questions and validate results, while queries, prompts, calibration on small batches, and model selection determine the quality and cost of automated analysis. Examples include identifying users who abandon error investigation for AI help, detecting product contradictions and dead ends, finding feature opportunities, analyzing experiment behavior, reviewing sessions before low-NPS responses, and understanding high-value users’ first sessions. Digests and Scouts are intended to synthesize patterns across many observations, while individual scanners remain focused on evidence from one recording at a time.

A PostHog employee argues that conventional corporate reporting often consumes substantial time while producing few meaningful decisions, describing how elaborate decks, reviews, forecasts, and business cases can become performative artifacts rather than tools for action. Drawing on experience in large corporate environments and an early overly detailed PostHog analysis, the author distinguishes useful reporting from excessive reporting, emphasizing that organizations should understand key metrics but reduce the effort spent on presentation, redundant analysis, and speculative approval processes. PostHog’s alternative relies on automated daily and monthly reporting in Slack, asynchronous discussion, self-service access to data through bots and AI tools, and reserving meetings for issues requiring real-time collaboration. The approach is presented as part of a culture that pairs employee autonomy with accountability, enabling teams to test ideas, observe results, and adjust quickly; readers are encouraged to assess whether their own reports have led to concrete decisions.

Feature flags may appear simple to build because they evaluate a key and return a value, but reliable production systems require extensive integrations for user targeting, experimentation, real-time cohorts, analytics, data warehouses, administration, and multiple SDKs. The discussion argues that self-built flag platforms can introduce critical-path reliability risks, performance problems, security concerns, and costly maintenance as organizations encounter production failures and evolving requirements such as deterministic rollout bucketing, multilingual support, auditing, and migration-safe architecture. It also highlights the growing need for agent-oriented capabilities, including MCP and CLI tools, access controls, audit logs, debugging, and monitoring of malformed or unauthorized agent actions. Adoption further depends on clear documentation and a strong developer experience, since internally developed tools can contribute to fragmentation and inconsistent practices. Building may still be appropriate when feature management is a business differentiator, a dedicated team can operate it as a product, or an organization has substantial reliability, compliance, or trust concerns about third-party providers; otherwise, the source presents commercial platforms such as PostHog as an alternative.

A PostHog self-driving team member describes how automated “loops” combine monitoring, triage, implementation, human review, and post-deployment validation to improve products and internal systems. These loops collect structured MCP agent feedback, Slack bug discussions, GitHub issue specifications, metric anomaly alerts, session-recording observations, and runtime logs; scouts then group duplicate signals, investigate likely causes, route reports to owners, and sometimes initiate pull requests. Examples include adding a missing MCP tool, fixing task-link permissions, implementing skill renaming, resolving a deployment compatibility issue, improving user-facing provider-error handling, and preventing oversized sandbox metadata tags. Human contributors primarily define specifications, guide investigations when needed, review reports and code, and approve merges, while the automated scouts continue checking whether fixes work in production and consolidate recurring evidence rather than creating redundant investigations.

PostHog reports expanding from one in-person event to more than 100 annually since summer 2025, with most events involving customer conversations and over half of employees participating in product demos worldwide. It attributes this engagement to a culture of openness, product engineers’ broad ownership of user relationships and business outcomes, and frequent internal demo practices through all-hands meetings, hackathons, and a dedicated demo channel. The events team supports speakers by identifying relevant opportunities, providing event details, travel budgets, merchandise, brand materials, and optional guidance, while largely allowing engineers to present their own work without extensive preparation requirements. It also uses an internal tool that reviews engineers’ recent GitHub contributions to suggest possible talk topics. The approach aims to make speaking voluntary, sustainable, and connected to product priorities, while recognizing that public demos are not suitable or desirable for every employee.

Replay Vision was developed to automate analysis of vast numbers of session recordings that are typically stored and never watched, using multimodal AI to identify user actions and problems at scale. Because session replays are not videos but rrweb event streams that reconstruct browser DOM changes, they were too large and structurally opaque for language models to interpret directly, requiring a rasterization system that converts replays into MP4 video. The team built a service using headless Chromium, Puppeteer, Temporal, and ffmpeg, but initially encountered skipped frames, freezes, and nondeterministic video lengths when rendering and capture processes competed for CPU resources. They resolved this by using Chrome’s HeadlessExperimental.beginFrame mode to synchronize rendering and capture one frame at a time, while virtualizing JavaScript time so the rrweb player advances at a fixed frame interval regardless of real-world processing delays. In production since March 2026, the deterministic rasterizer runs hundreds of concurrent jobs, has converted more than 370 years of recordings into about 3.5 million videos, and enables Replay Vision and related Session Replay features to provide multimodal AI with viewable recordings.