PostHog build mode editorial newsletter

Forwarded this email? Subscribe here for more We're building multiplayer AI. Here's what we've learned so far Non-obvious lessons for multi-human agent systems Jina Yoon Sep 28 READ IN APP Welcome to build mode Don’t recognize this sender? Unsubscribe with one click PostHog recently imported your email address from another platform to Substack. You'll now receive their posts via email or the Substack app. To set up your profile and discover more on Substack, click here. Ethan Mollick @emollick Multiplayer AI, where many people in an organization can use AI together to accomplish goals, remains one of the biggest (non-technical) problems in using AI right now. Approaches tend to be pretty primitive and based around AI-as-a-person-in-your-group-chat. That is limiting. 6:52 PM · Sep 3, 2026 · 126K Views 117 Replies · 41 Reposts · 649 Likes When people imagine multiplayer AI, they usually think of products like Claude Tag or PostHog in Slack. These are fine for simple tasks, like fixing minor bugs and querying data, but most work happens outside Slack across dozens of apps in messy, nonlinear processes. This creates a UI bottleneck that forces people to translate rich information into flat text, only to be transformed back into the original shape by agents at the end of the funnel. We wanted to build a collaboration tool that’s designed for agents from the start, so we’ve been exploring alternatives beyond Slack for multiplayer AI these last few months. Here are a few of the lessons we’ve learned so far about building multiplayer in PostHog Desktop. 1. You need to establish a shared reality Context is important for any AI system, but the key word in multiplayer is shared context. Siloed context wastes tokens, duplicates work, and creates inconsistencies. Say two teammates attend the same meeting but write down slightly different definitions of a goal metric. Their context now differs, which means their work may diverge without them even knowing. With agents, these minor differences can compound into completely different realities at scale. A shared context system reduces that risk by being a source of truth. This also decreases the friction of information handoff, since teammates can just check a shared resource instead of asking and waiting on each other. There’s no reason to not have a shared context system since it can be as simple as a team Notion page connected via MCP. The real challenges are in keeping it up to date, trustworthy, and complete. How we’re building it In chat-based systems, shared context is basically free since you can infer what’s in scope from the root conversation. When the PostHog in Slack bot gets tagged in a thread, it can just read what people have said in chat so far. It also has context from the relevant PostHog project for that organization via our MCP. But our approach to multiplayer in PostHog Desktop is built on Spaces, not conversations. Spaces are like “rooms” that hold people, agents, and work objects in a shared container. They’re entirely user-defined, so there’s no way to automatically identify and initialize shared context. We first tried to solve this by asking users to write down the purpose of a Space in a CONTEXT.md at creation time and update it regularly. As you’d expect, that never actually happened. Over 90 days, only 64 users ever started a shared context file, and only 14 users ever edited it. We’ve since been exploring automatic context maintenance for Spaces through an AI-powered context layer. It starts out almost empty and grows by running a nightly “dreaming” task that records what happened that day in a version-controlled Markdown wiki. This is similar to what others might describe as an implicit knowledge layer, or company brain. The actual work objects like docs, PRs, and tickets live elsewhere; the context layer just looks at them to extract information: A key part of the design is that it only looks at what was actually shipped, merged, or