For a few strange quarters, parts of the tech industry decided that the best way to measure AI adoption was to count how many tokens engineers burned. This trend was called tokenmaxxing.

Meta built an internal leaderboard ranking all 85,000+ employees by token consumption. Top users earned titles like "Session Immortal" and "Token Legend." In one 30-day period, Meta employees burned through 60.2 trillion tokens, a number that, at standard Anthropic API pricing, would cost around $900 million. Even at enterprise discount rates, the bill likely ran to $100 million or more. A meaningful chunk of that, by all accounts, was deliberate waste.

Microsoft ran a similar leaderboard. Salesforce set minimum monthly token spend targets and made everyone's spend visible to their teammates.

The message was clear: use enough tokens, or get flagged. But the results were also entirely predictable.

The Pragmatic Engineer reports this quote from a software engineer at Microsoft:

“I am conscious of not wanting to be seen as “uses too little AI,” and I’m not ashamed to say I need to do tokenmaxxing to do this. Things I do to inflate my token usage metrics: Ask AI questions about the code already in the documentation. The AI pulls up the documentation, processes it, and gives me results 10x slower, but while burning lots of tokens. I could use “readthedocs” [an internal product], but then my token numbers would be lower. Ask the AI to prototype a feature that I have no intention of working on. Prompt it a few more times, then throw the whole thing away. Default to always using the agent, even when I know I could do the work by hand much faster. Then watch it fail”

This engineer’s behavior is the logical output of a badly designed incentive: someone who knows exactly what they're doing, knows it's wasteful, and does it anyway because the alternative is being tagged as insufficiently AI-native.

This isn't the first time the industry has run headfirst into Goodhart's Law: when a measure becomes a target, it ceases to be a good measure. Tokenmaxxing is the spiritual successor to "lines of code shipped" a regression to the pre-DORA era of developer productivity measurement, where what got counted was an input to the process, not an outcome of it.

Token leaderboards are already coming down and, this trend, hopefully, is in the rear-view mirror. What replaces it matters and the case for token optimization is stronger than most teams realize.

Three reasons token optimization is now inevitable

There are three structural forces making the correction from tokenmaxxing to token optimization inevitable:

The cost will catch up

Tokenmaxxing as a productivity measure might seem merely wasteful while AI providers are still subsidizing adoption. It will be fiscally irresponsible and embarrassing to justify when the bills start reflecting what inference actually costs.

AI providers are pricing tokens to drive developer adoption, not to recover their infrastructure costs. The economics of training and running large models at scale are still deeply unfavorable, and every indication is that the current pricing represents a land-grab phase, not a sustainable market rate. When prices eventually reflect real costs, teams that have built workflows around burning tokens freely will face a reckoning they haven't budgeted for.

Even now, CFOs are starting to see AI tooling costs appear as a significant line item without a corresponding improvement in the metrics most engineering managers care about. The data doesn't make a comfortable case for this level of continued spending: incidents per PR up 242%, bugs per developer up 54%, PR revert rates flat despite record token consumption. The productivity gain is real at the individual level (more code shipped, more tasks closed) but more tokens are not buying more reliable, higher quality software.

More tokens, same problems

The Jellyfish AI Engineering Trends data makes the point plainly: engineers with the largest token budgets produced the most pull requests, but productivity improvement didn't scale with token spend. The correlation between token consumption and output quality simply isn't there.

Tokenmaxxing behavior (e.g. running agents on loosely specified tasks or burning through context with throwaway prototypes) is part of the problem. But the deeper issue is structural.

We are trying to solve a data problem with more tokens and better models. An AI agent is only as good as the environment it operates in, and it requires precise, complete runtime data about your system to reason correctly about what broke and how to fix it.

When you bolt an AI agent onto an observability stack designed to give humans dashboards for assessing system health, the agent inherits all the limitations of that architecture: sampled and aggregated data, siloed context, and no correlation across the system boundaries where complex failures actually live.

Closing that gap requires moving away from passive data dumping and restructuring the data layer for machine consumption: capturing full-fidelity, pre-correlated session data at the source, before it ever reaches an agent.

The environmental cost is real and growing

This one gets less attention, but it will increasingly show up in enterprise decision-making. Large-scale AI inference carries a meaningful energy footprint (data center power consumption, water cooling, hardware cycling) and the numbers are growing as adoption scales. The data is still noisy and methodologies vary, but the direction is unambiguous.

This matters for two reasons. First, many enterprises have made public sustainability commitments that will eventually come into conflict with "maximize token spend" as an engineering culture norm. Second, regulators in the EU and elsewhere are beginning to require disclosure of AI energy use in corporate reporting. "We ran 60 trillion tokens last month" is going to read differently in a sustainability report than it does on a leaderboard.

What token optimization actually looks like in practice

Token optimization is about being precise: giving agents exactly what they need to do their best work, and nothing more. Here are four concrete strategies engineering teams are already using.

Give agents the right data, not all the data

The most direct path to token waste is also the most common: feeding agents everything available and hoping they'll figure out what's relevant. An agent debugging a production bug doesn't need everything the observability stack collected since last Tuesday. It needs the unsampled, full-stack session data scoped to the specific failure: pre-correlated, deduplicated, ready to reason about.

This is the data problem that runs underneath the token problem. When agents work from sampled, aggregated, siloed observability data, they burn tokens reconstructing context that was never complete to begin with, and still produce fixes that miss the actual root cause. Precision beats volume. Not just for cost reasons, but because the quality of the output depends entirely on the quality of the input.

Use the right model for the right task

Frontier models are extraordinary at complex reasoning, architectural decisions, and multi-step problem solving. They're also expensive, and they're not necessary for most of what agents actually spend time on.

A practical token optimization strategy treats model selection like any other resource allocation decision. Use a smaller, faster, cheaper model for boilerplate generation, code formatting, routine refactoring, and low-stakes tasks. Reserve frontier models for the work that actually requires them: root cause analysis, architectural judgment, anything where the reasoning chain is long and the stakes of getting it wrong are high. You don't need a Ferrari to go grocery shopping.

Context minimalism

Cat Wu, Head of Product for Claude Code at Anthropic, calls herself "a context minimalist": tell the model only what it needs, then let it choose the route. Every file read, rule, hook, skill, and subagent changes what the model is carrying around, and the more it carries, the more tokens every exchange costs.

This represents a maturity shift in how teams think about working with agents. The early instinct was context engineering: curate everything you might possibly need and hand it all over. The current approach tends more toward context minimalism: trust the agent to find what it needs, and resist the urge to front-load the context window with everything that could conceivably be relevant.

Anthropic's own team confirmed this shift when they deleted around half the system prompt for Claude Code: the information wasn’t wrong, but newer models no longer needed it spelled out.

Teach your agents to be less verbose

Agents left to their own devices write more code than necessary. They install (or create!) libraries for problems the standard library already solves. They create abstractions for things that don't need abstracting. They generate fifty lines when five would do… and every line costs tokens to produce and tokens to review.

Skills like Ponytail and Caveman are built around the YAGNI (You Aren't Gonna Need It) philosophy. Ponytail, for example, forces the agent to work through a hierarchy before writing a single line: does this need to exist? Does the standard library handle it? Is there a native platform feature? Is there an existing dependency? Only after exhausting those options does it write code, and then only the minimum that works.

The benchmarks are striking: 80-94% less code, 47-77% less cost, and 3-6x faster than an unconstrained agent. The project's tagline captures the philosophy better than any benchmark: "the best code is the code you never wrote."

Final thoughts

Every technology platform goes through this arc. The gold rush phase is about maximizing usage, learning what the tools can do, and pushing limits. The discipline phase is about doing more with less.

The token leaderboards are already coming down. The correction is underway. Token optimization is the natural next step in learning to work with these tools well. The teams that figure it out first will have lower AI bills, but most importantly, they'll have better software.

When we started building Multiplayer's debugging agent, we made the same mistake almost everyone makes. We gave our coding agent access to observability data and expected it to figure out what was relevant.

It didn't. The agent called the wrong tools, chased the wrong signals, and produced fixes that looked plausible but failed in production. We were using state-of-the-art models, but we were handing them raw observability data without any curation or filtering. We later realized that we were just routing them noise.

What follows is what we learned about what you actually have to do with observability data before it's fit for an AI agent to act on.

The signal-to-noise problem

Observability data has one of the worst signal-to-noise ratio of any data type you could feed an AI agent.

A single production issue might involve hundreds of spans across a dozen services, thousands of log lines, missing request and response payloads, redacted headers, clock-skewed timestamps, and events distributed across tools that have never been correlated with each other. A human debugging this issue brings years of context: they know which services are noisy, which logs matter, which timestamps to trust, and roughly where in the stack the problem lives. They navigate the noise because they understand the system.

An agent sees everything with equal weight. Garbage spans get the same attention as the one span that actually shows the failure. Thousands of log lines get processed before the agent can ask a useful question. And because context windows are finite and expensive, you burn through your budget before you've even framed the problem correctly.

This is a data preparation problem. And it's one that has to be solved before the data reaches the agent, not by the agent itself.

What data curation actually means

Data curation for AI agents shouldn’t be confused with summarization or compression, which is what most engineering teams end up doing.

In actuality, it's the process of transforming raw observability data into a structured, scoped, context-rich package that an agent can reason about correctly. That means making a series of deliberate decisions: what to include, what to exclude, how to group related signals, and what additional context the agent needs to understand the problem.

At Multiplayer, we do this in four stages before any data reaches a coding agent.

Stage one: group and correlate aggressively

The first thing we do with raw observability data is group related events and correlate them across service boundaries.

A single bug will typically surface across many sessions, environments, and services. Without grouping, each occurrence looks like a separate issue. And without correlation, the agent can't see the causal chain that connects a user action on the frontend to a failure deep in the backend.

We correlate aggressively: user interactions, session metadata, network requests, backend traces, and log events get tied together into a single timeline before anything else happens. The agent needs to see that the click at 14:32:01 caused the cascade that showed up in the backend logs at 14:32:04. It can't infer that from timestamps alone (especially under any real load or clock skew). The correlation has to be built into the data structure before the agent sees it.

We also deduplicate at this stage. The same bug appearing across a hundred user sessions becomes one issue, not a hundred separate signals. This is both because of cost and quality management. An agent acting on deduplicated, grouped data produces one PR for one issue. An agent acting on raw, ungrouped data produces dozens of PRs for the same issue, burns through tokens unnecessarily, or gets confused trying to reconcile conflicting signals from the same underlying failure.

Stage two: assess fixability before routing to the agent

Not every issue is worth routing to a coding agent, and not every issue is something a coding agent can fix.

Before anything reaches the coding agent, we run a fixability assessment through a dedicated agent. Is this a deterministic, reproducible failure with a clear root cause? Or is it an intermittent, environment-specific issue that requires human judgment to diagnose?

This matters for a few reasons. First, coding agents produce their worst outputs on problems they don't have enough context to solve correctly, which are often the hardest, most intermittent bugs. Routing those to a coding agent without human oversight wastes tokens and produces plausible-looking fixes that don't hold.

Second, fixability scoring lets you prioritize. High-fixability issues (clear root cause, deterministic reproduction, well-scoped impact) go to the coding agent immediately. Lower-fixability issues get flagged for human review with the curated context already attached.

The goal is to keep humans in the loop where human judgment is actually needed, and route everything else through the automated fix cycle.

Stage three: add release context and metadata

Raw observability data tells you that something broke, but it doesn't tell you what changed that caused it to break.

Before the data reaches the coding agent, we automatically add release context: build information, deployment timestamps, recent commits, the specific version of each service involved in the failure. Bugs don't appear in a vacuum. They're usually introduced at a specific point in the git history, often in a specific commit, often by a specific change that touched the affected code path.

A coding agent producing a fix without this context is guessing about the causal history of the bug. With release metadata attached, the agent can connect the failure signal to the change that introduced it. That changes the quality of the fix significantly: it goes from "here's a patch that handles this error case" to "here's what the change introduced and here's how to correct it."

We also add service metadata, environment information, and any relevant configuration context that helps the agent understand the system it's operating in. Custom service name mappings (e.g. "payment-service," "svc-payments," and "payments_v2" all referring to the same thing) get resolved here so the agent isn't treating three names as three entities.

Stage four: format and summarize for machine consumption

The final stage is the one that most teams skip entirely, and it's where a lot of debugging agent performance gets left on the table.

Raw observability data is formatted for humans: JSON payloads, nested span structures, log lines with internal formatting conventions. These are designed to be readable by someone who understands the system and is looking at a dashboard.

We reformat data before it reaches the coding agent. Spans get converted from nested JSON into a structured narrative that describes the execution path. Log lines get filtered to the ones that are actually relevant to the failure window and reformatted to make the timeline legible. Request and response payloads (which most observability tools strip out by default, and which we capture specifically because they're the most useful debugging signal) get included with the context that explains why they're relevant.

We also produce an issue summary that we call "explain it like I'm 5". The goal is to bring the coding agent up to speed the way you'd brief a developer who's just joined an incident call: here's what broke, here's when it started, here's what changed recently, here's where in the stack the failure lives, here's what the error looks like when it surfaces.

What this looks like in practice

The difference between V1 and V2 of Multiplayer's debugging agent was almost entirely in the curation layer.

V1 mirrored our API and gave the agent a lot of tools to work with. The agent called the wrong tools, used the wrong parameters, burned through tokens, and produced PRs that missed the actual root cause. The model wasn't the problem. The data access pattern was the problem.

V2 had one main tool that returned a curated, correlated, formatted package of everything the agent needed to understand the issue. The agent called the right thing at the right time, asked focused follow-up questions when it needed more context, and produced fixes that held up in production.

What made the difference was the curation layer: grouping, deduplication, fixability assessment, release context, formatting, and issue summary.

The question to ask yourself

Most debugging agents and MCP servers are built to answer the question: "How do I give the AI access to my observability data?"

That's the wrong question.

The right question is: "What does the agent need to understand about this specific issue in order to produce a fix worth shipping?"

Those questions lead to very different architectures. The first leads to raw data exposure: give the agent access to everything and let it figure out what's relevant. The second leads to curation: do the work of making the data fit for machine consumption before it ever reaches the agent.

The observability data you have right now was built for humans. It's sampled, aggregated, siloed, and formatted for dashboards. Sending it directly to a coding agent without transformation is the reason most debugging agents produce output that looks right and fails in production.

Today we're open sourcing the Multiplayer debugging agent: connect your favorite coding agent to prod to fix application bugs automatically. Run it locally and eliminate PR slop.

The core (session-based data capture, local-first architecture, intelligent deduplication, and coding agent integration) is publicly available under MIT, free to use, and auditable by anyone.

You can find it here: https://github.com/multiplayer-app/multiplayer

Why we believe in open source

Open source is under real stress right now: maintainers are burning out under floods of AI-generated pull requests, projects are shutting their doors, and SaaS companies are reverting to closed-source and declaring “open source is dead”. GitHub even had to ship maintainer-relief tools just to keep the contribution model functioning.

The structural problem is simple and brutal: AI coding tools dropped the cost of generating a pull request to near-zero, while the cost of reviewing one stayed exactly the same (our CTO and cofounder Thomas Johnson wrote in depth about the PR reviews crisis).

We made this decision with eyes open. Open sourcing Multiplayer means accepting some version of that reality. So why do it?

Because trust has to be earned, not assumed.

Multiplayer runs locally, next to your coding agent, and captures full-stack session data when something breaks in production. We're designed to minimize data exposure by default: we only capture full-stack session data when something goes wrong, and nothing gets sent anywhere until we've identified a new issue worth surfacing.

The open source core takes that further. When you self-host Multiplayer, nothing leaves your infrastructure, period. If your organization has policies that prevent sending production data to third-party services, or you simply want full control over where your data lives, self-hosting is the right model.

It also gives you the means to verify that Multiplayer works the way we describe it. The honest answer to "how do we know what this thing is actually doing?" is: read the code. Inspect the capture logic. Verify that data stays local until an issue is identified. Confirm that nothing gets sent anywhere until Multiplayer has found something worth surfacing.

Because open source is the best answer we have to the PR slop problem.

One of the major causes of the flood of low-quality AI contributions is the data problem. Agents generating pull requests without sufficient context about the system they're modifying produce plausible-looking code that crumbles under review and fails in production. The same mechanism that produces bad debugging fixes produces bad open source contributions: an agent working blind, guessing at what the system needs, generating output that looks right on the surface and fails in practice.

Making Multiplayer available to as many developers as possible is the most direct way we can address that. Better runtime data for coding agents means higher quality outputs, both in production debugging and across the whole AI coding workflow, including open source contributions. As models improve, as context engineering practices mature, and as developers get better at giving agents the right data to work from, the quality of AI-assisted contributions will follow. We're open sourcing because we believe that, and because we want to accelerate it.

There's also the security argument, which is straightforward: security through obscurity is not security. More eyes on the code (including AI-assisted eyes) is a net positive for security, not a liability. The right response to AI-powered vulnerability scanning is transparency and continuous improvement, not keeping the code closed and hoping nobody looks.

How it works: open core, hosted, and enterprise

We're launching with three tiers, and we want to be clear about what each one is and why.

Open source core (MIT)

Everything a developer needs to run Multiplayer locally is open source. Full-stack, unsampled session capture. Local-first architecture that caches sessions and only sends data when a new issue is identified (there is an error or exception in your frontend or backend). Intelligent deduplication so the same bug gets tracked once. Coding agent integration with Claude Code, (and coming soon) Codex, Copilot, Cursor, and whatever ships next.

Hosted plan

If you want to use Multiplayer without managing your own infrastructure, the hosted plan is the right option. We handle deployments, updates, maintenance, and uptime. The hosted plan includes SSO/SAML, 30-day session retention, and email support.

One thing worth being explicit about: Multiplayer is designed to minimize data exposure by default. We only capture full-stack session data when something goes wrong. Nothing gets sent anywhere until we've identified a new issue worth surfacing. The hosted plan gives you the convenience of a fully managed service without the broad data exposure that usually comes with SaaS tooling.

Enterprise features

Audit logs, compliance reporting, team management, and other features that only matter at scale are licensed commercially and separately from the open source core.

A note on contributions

We welcome contributions, and we want to be honest about what makes a good one.

The PR slop problem is real and we're not immune to it. The contributions that will move Multiplayer forward are the ones grounded in real runtime data: bug reports that come from developers who have actually run Multiplayer against a production system and hit a specific edge case. We're optimizing for signal, not PR volume.

The contributing guide is here: https://github.com/multiplayer-app/multiplayer/blob/main/CONTRIBUTING.md

If you're using Multiplayer and something is broken or missing, we want to hear from you.

Get started

The repo is here: https://github.com/multiplayer-app/multiplayer

The hosted plan is here: https://go.multiplayer.app/

The docs are here: https://www.multiplayer.app/docs/

Observability as we know it is on its way out.

For over a decade, we built telemetry stacks around a single consumer: a human, staring at a dashboard, trying to make sense of a system under stress. Every architectural decision that followed (sampling, aggregation, retention limits) was optimized for that consumer, forcing us to throw away a large portion of our data just to keep costs down and dashboards readable.

That tradeoff made sense when a person was doing the looking. It stops making sense the moment an agent is.

Autonomous AI agents are increasingly the ones detecting issues, investigating root causes, and shipping fixes. And they're drowning in exactly the data we spent a decade optimizing for human eyes: telemetry collected by casting the widest possible net, then sampled and aggregated down to whatever a dashboard could display.

The result is a system drowning in data and starving for signal.

This article makes the case for why the observability data we collect today fails agents, and what a runtime architecture built for this new consumer actually looks like.

We ship code (and bugs) faster than ever

Teams using coding agents are shipping faster: more code, more changes, more features, without growing the team. But the same data shows the other side. More bugs per developer. More incidents per PR. More risk in the code AI writes.

Velocity up, stability down. Both true at the same time. Recent research converges on the same conclusion:

• DX's AI-assisted engineering report: Some companies are increasing the Change Failure Rate (CFR) value by almost 2%. Given an industry benchmark of 4%, this means some companies are shipping up to 50% more defects than before.
• Sonar's State of Code Developer Survey: 96% of developers working with coding agents don't fully trust that AI-generated code (42% of all committed code) is functionally correct. Yet 48% are regularly shipping code they haven't fully verified.
• Aikido Security's State of AI in Security & Development report: AI-generated code is responsible for roughly one in five security vulnerabilities discovered.
• Apiiro's research inside Fortune 50 enterprises: AI coding assistants can be up to four times faster than humans working alone, but the code they ship carries ten times the risk.
• Faros's AI Engineering Report: incidents per PR are up by 242%, monthly incidents are up 58%, bugs per developer are up 54%, bugs per PR are up 29%.

And in case there was any doubt, the latest Jellyfish's AI Engineering Trends research shows token consumption climbing sharply (P90 is now 173M weekly tokens per user as of May 2026), but PR revert rates haven't followed. They remain roughly flat across all AI adoption tiers, hovering in the same 0.45%–0.65% band they were in a year ago. More tokens per developer hasn't bought fewer reverted PRs.

Why human-optimized data creates friction for AI

Historically, observability data has required practical compromises to manage storage costs and prevent human cognitive overload. These were sensible, rational engineering choices for teams of human operators with finite attention spans and budgets.

Those compromises made sense for their intended audience. They're also exactly why this data is such a poor fit for an agent's context window.

Here are six reasons the observability data you're already collecting was never built for an agent.

1. Volume

Most telemetry collection is preventative. Teams collect everything because they don't know in advance what they'll need when something breaks, and instrumenting after the fact, once a gap is exposed, is slow and expensive. So the default is to cast the widest possible net.

Casting a wide net and catching the right fish, however, are different problems. The result is organizations sitting on enormous volumes of generic telemetry, wrestling with the storage bill that comes with it, and, for agents, burning through a context window before they've even gotten to the question.

Paradoxically, OpenTelemetry made this worse, not better. Democratized instrumentation is genuinely good for standardization, but it also made it trivial for every team to auto-instrument everything, and most do, without anyone asking whether the data is useful. The result is a system drowning in telemetry and starving for signal. As Michele Mancioppi, head of product at Dash0, put it on a recent LeadDev panel: "[…] of the logs getting into observability tools, less than 1% are fatal errors. All the rest is probably a waste of money."

2. Sampling

Sampling gives you a representative picture of system behavior at a fraction of the cost. For a human looking for patterns across millions of events, that tradeoff is reasonable. For an agent trying to reconstruct one specific failure across service boundaries, it's close to useless: the agent can't reason over the gaps. Indeed, it has no way of knowing the gaps are even there.

3. Aggregation

A p99 latency metric is more useful to a human scanning a dashboard than a million raw data points would be. But an agent debugging a specific failure needs the individual events, in order, with full payloads. Averages can obscure the outlier that caused the bug (and, sometimes, they erase it entirely).

4. Data that was never collected

Request/response payloads aren’t captured by default due to privacy and cost concerns. You can see that an API call was made, but not what data was sent or what came back. Headers (authentication tokens, routing info, custom metadata) are often redacted for security reasons, removing critical debugging context. External API exchanges are black boxes. Distributed tracing stops at your system boundary. When your backend calls Stripe, Twilio, or AWS, you see the call happened and how long it took, but not what you sent them or what they returned.

5. Siloed collection

DevOps and platform engineering were supposed to be the industry's answer to this. Break down the wall between different teams, frontend and backend, and the silos go with it.

In practice, not all silos have disappeared, especially in larger organizations. Frontend errors still live in one tool, backend traces in another, and the correlation between them still lives in tribal knowledge: developers know how to correlate a user click at 14:32:01 to the cascade that showed up in the backend logs at 14:32:04.

An agent has no such intuition. In theory, it could query every tool separately and correlate the results itself. In practice, this rarely works: each platform has its own APIs, auth, and data formats, and the correlation keys that tie events together (request IDs, trace IDs, session IDs) rarely propagate across tool boundaries. The agent is left guessing which frontend error maps to which backend trace based on timestamps alone, an approach that falls apart under any real load or clock skew. Even with perfect access to every tool, the agent can't reconstruct the full picture unless the data was correlated at the point of collection.

6. Metadata inconsistency

This is the gap humans paper over without noticing. Everyone on the team eventually learns that "payment-service," "svc-payments," and "payments_v2" are the same thing. It comes up in a Slack thread, gets mentioned during onboarding, and lives in someone's head from then on. An agent has none of that. It sees three different entities, because as far as it's concerned, that's exactly what they are.

Stop bolting AI onto the interface. Fix the data underneath it.

None of the practices described above were mistakes. They were the right calls for an era of human-led debugging. But you can't ask an agent to debug a system when the exact data it needs was sampled out or discarded to save on storage.

The Jellyfish data makes the point cleanly: you can't fix a data problem with more compute. If more tokens and better models produce the same PR quality as before, the bottleneck was never compute to begin with.

The industry spent years solving for open-loop observability: helping humans detect problems through dashboards and alerts, which would then be fixed (closing the loop) in another tool, with another workflow. In the past year, every major platform bolted on an AI agent or an MCP server and declared the bug-to-fix loop closed: "We don't just detect issues, we fix them."

These integrations offer real value, and they do speed up workflows. But connecting an agent to your observability stack isn't the same as giving it what it needs to fix something.

An agent's capabilities are fundamentally bound by the system underneath it. If a trace was sampled out or a payload was dropped at collection time, no amount of agent intelligence on top can recover it. The data simply isn't there to analyze.

Closing the loop isn't an integration problem. It's a data problem, and it requires an architectural shift in how runtime signals are captured, retained, and correlated.

Flip the question

Most teams are asking: how do I give my AI agent access to my telemetry?

That's the wrong question.

The right one is: what does this agent actually need to fix what's broken?

The two are not the same. Access to a platform built for a different consumer doesn't make the data inside it any more complete. To understand if your observability data is ready for autonomous agents, ask yourself:

1. Does the agent get the exact, unbroken session, or a sampled trace with gaps it can't see?

2. Is data correlated across service boundaries at the point of collection or is the agent matching timestamps and guessing?

3. Can the agent see real request and response payloads including calls to third parties like Stripe, Twilio, or AWS?

4. Does the agent receive a deduplicated, scoped issue or a raw stream of telemetry it has to make sense of first?

5. Is the agent positioned to act (producing a fix, ranked by severity, ready for review) or only to summarize and page a human?

If the answer to most of these is no, the gap isn't in your agent. It's in everything the agent is standing on.

The dashboard is dying because the questions worth asking have changed, and dashboards were never built to answer the new ones. The teams that can effectively leverage all the potential presented by AI agents will be the ones whose runtime data was ready for them.

AI coding assistants are great at writing code. They are not great at fixing bugs in production and the reason is simple: they don’t have runtime visibility.

The obvious solution is to connect them to your existing observability stack. Teams are already doing this: hooking Claude Code or Cursor up to a Datadog MCP server, using Sentry Seer to understand their error logs, building integrations that give coding agents access to traces and dashboards. On the surface this looks like runtime visibility. In practice, it produces plausible-looking PRs that fail in production.

The problem is the data itself. Your observability stack was designed for humans monitoring system health. It's sampled (sometimes at 1%, sometimes at 10%) to keep storage costs manageable, which means the specific request that caused the failure may not exist in your telemetry at all. It's aggregated across sessions and time windows, which strips out the exact sequence of events that preceded a failure. It's missing critical content entirely such as request/response payloads and headers from deep within your system. And it lives across multiple tools, each with their own MCP server and integration requirements, that a coding agent has to stitch together without native correlation across service boundaries.

Developers have to spend hours assembling enough context to write a fix or waste tokens having coding agents grep through non relevant data and rewriting bug fixes.

We got tired of grepping through logs, dealing with missing data, and PR slop.

That’s why we built the Multiplayer debugging agent: a companion that runs locally next to your coding agent and manages the whole process from bug identified to bug fixed, using full-stack, unsampled runtime data.

The developer experience is intentionally simple. Multiplayer runs locally in the background while you work. When a bug surfaces, your coding agent gets notified, a new git branch is created, and a PR lands in your review queue. You review it, merge it, and move on. No manual investigation, context-switching, or wasted tokens.

How it works under the hood

Most observability tools are built around always-on data collection: instrument everything, ship it to a cloud backend, sample aggressively to manage costs, and hope the data you need wasn't in the 90% that got dropped. That model was not designed for coding agents that need complete, pre-correlated runtime context to write accurate fixes.

We built Multiplayer's data layer differently from the start, around three architectural decisions that matter:

Full-stack, session-based data collection

Multiplayer listens continuously but only saves data when something goes wrong. When a backend or frontend error or exception fires, we capture and correlate all the sessions across your stack: user interactions, network requests, console logs, backend traces, request/response content and headers from every component in your system. Everything that happened before, during, and immediately after the failure. Sessions that ran clean get dropped entirely.

This ensures you have full-stack, pre-correlated, unsampled runtime data about an issue, while storage costs are kept low.

Local-first caching

Multiplayer runs right next to your favorite coding agent (Claude Code, Codex, Copilot, etc.) without requiring access to your codebase. Sessions are also cached locally before any data gets sent.

This matters for security: your code never leaves your machine, and you retain complete control over what gets debugged and when.

Intelligent triage and deduplication before the coding agent ever sees the issue

This is where most debugging tools break down when you connect them to a coding agent. A bug that surfaces across a hundred user sessions generates a hundred error events. Without deduplication, your coding agent gets prompted a hundred times, opens near-identical PRs, and your review queue fills up with variations of the same broken fix.

Multiplayer checks every new error against existing issues. If it's new, we save the full session data, score it for fixability, and create an issue that we send to your coding agent to automatically fix.

If it's a known bug, we add the session to the existing issue or drop it entirely if we already have enough examples of that error.

This means we're not burning tokens on issues that have already been identified, and we're not opening PRs for bugs your coding agent has already seen.

Try it today for free

We built Multiplayer because developers want self-healing systems, not just more alerts and dashboards.

If you are already using an AI agent to write your code, Multiplayer gives it the data it needs to fix application bugs in production when they break. You can get started in just a couple of minutes by copy/pasting one command line into your terminal.

npm install -g @multiplayer-app/cli && multiplayer

If you're a technical leader, there's a good chance your team is spending significant time on custom logging… and you might not even realize how much it's costing you in productivity and incomplete debugging data.

Let's start with a simple test. When a production incident hits, can your team immediately answer these (or similar) questions?

If you're seeing mostly yellow and red on the left side, your team has a custom logging problem. And it's costing you more than you think.

What is custom logging (and why do teams do it)?

Custom logging is when developers manually add code to capture and record information about what's happening in your application. Specifically, the request and response data flowing through your system.

Here's what it looks like in practice:

# Before calling Stripe API
logger.info("Calling Stripe charge API", extra={
    "amount": 1000,
    "currency": "usd",
    "customer_id": "cus_123"
})

# Make the API call
response = stripe.Charge.create(amount=1000, currency="usd")

# After getting the response
logger.info("Stripe response received", extra={
    "charge_id": response.id,
    "status": response.status,
    "response": response.to_dict()
})

Standard observability tools (Datadog, New Relic, Honeycomb, etc.) capture that API calls happened. You can see "POST to Stripe, 200ms, success", but they don't capture what data was in those calls. To understand what actually went wrong during a bug, you need the request and response content: what you sent, what came back, and where it broke.

So teams add custom logging everywhere: in checkout flows, payment processing, email sending, file uploads, database queries. Anywhere they might need to debug later.

The problem: it requires constant manual discipline

Custom logging sounds reasonable in theory. Just add logging when you write the code, right? But here's what actually happens:

"I'll add it later" (never happens)

During a rushed bug fix or feature launch, logging gets deprioritized. "Let's just ship this, we'll add proper logging in the next sprint." The next sprint comes with its own priorities. The logging never gets added.

One-off integrations get skipped

Your team integrates a new third-party service, maybe a document signing API or a geocoding service. The main flow gets logged, but edge cases and error paths don't. Six months later, an issue happens in one of those paths, and there's no data to debug with.

New developers forget

A junior developer ships a new feature. They test it, it works, they move on. Three weeks later, that feature breaks in production. The team scrambles to debug it and realizes: there's no logging. No one can see what data the user submitted or what the external API returned.

Response logging is inconsistent

Even when developers remember to log the request to an external API, they often forget to log the response. Or they log success cases but not errors. Or vice versa. During an incident, you're left guessing what the external service actually returned.

The hidden cost: time and incomplete coverage

Here's what custom logging looks like in practice:

When custom logging coverage is incomplete, here's what happens during incidents:

• Longer debugging time: Engineers spend hours hunting for data that doesn't exist, context-switching between tools, trying to reproduce issues locally.
• Ongoing maintenance burden: Every new feature, every new integration, every new external API requires thinking about logging. It's a tax on velocity.
• Friction in code reviews: "Did you add logging for this?" becomes a frequent review comment that slows down reviews. Teams try to enforce it through checklists and linters, but it's never perfect.
• False confidence: Leadership sees "we have logging" in the observability platform and assumes the team can debug any issue. The reality only becomes clear during incidents when critical data is missing.

How Multiplayer is different

Multiplayer takes a fundamentally different approach: automatic capture instead of manual instrumentation.

Instead of requiring developers to remember to log every API call, Multiplayer automatically captures:

• All internal service requests and responses (full content and headers)
• All external API calls (Stripe, Twilio, AWS, etc.) with full request/response data
• Frontend user actions and network activity
• Everything correlated in one timeline

With Multiplayer:

The session-based difference

The other key difference: Multiplayer uses session-based recording instead of "always-on for all traffic."

Traditional approach (custom logging + observability):

• Collect logs and traces for 100% of traffic (or sample heavily to control costs)
• Store everything forever
• Pay for massive volumes of data you'll never look at
• Still missing the payloads you actually need because you didn’t manually instrument for it

Multiplayer approach:

• Only record sessions where you need visibility (user-reported bugs, errors, specific conditions)
• When you do record, capture everything for that session
• Lower cost because you're not ingesting terabytes of generic logs

This means you get complete data where it matters without the cost of logging everything, everywhere, always.

What this means for technical leaders

If you're responsible for engineering productivity and infrastructure costs, here are the questions to ask:

1. What percentage of our external API calls are actually logged?Ask your team to audit. The answer is usually surprising (and lower than expected).
2. How much time do engineers spend adding logging to new features?This is a hidden tax on velocity. Every feature requires thinking about and implementing logging.
3. During the last 5 incidents, how often did we have all the data we needed?"We had to reproduce it locally" or "we couldn't see what Stripe returned" are red flags.
4. What's our monthly cost for log ingestion and storage?Custom logging creates massive volumes. Even with sampling, the costs add up.
5. How do junior developers learn what to log and where?If the answer is "code reviews catch it" or "tribal knowledge," coverage will stay incomplete.

The bottom line

Custom logging can technically capture everything, but in practice, it rarely does. Coverage degrades over time, external APIs get forgotten, and during incidents, you're left asking "did anyone log this?" instead of debugging.

Automatic capture solves this by ensuring that when an issue happens, you have the complete context (frontend, backend, external APIs, request / response content and headers) already correlated and ready to investigate.

Your team stops spending time on logging instrumentation and starts spending time on what actually matters: understanding and fixing bugs.

There's a common belief in the observability space: if you just collect more data, you'll have what you need to debug any issue.

The reality is more frustrating: even with 100% unsampled observability, you're still missing critical debugging data.

The problem isn't sampling. It's what observability tools are designed to capture in the first place.

What observability tools actually collect

Traditional observability platforms (Datadog, New Relic, Dynatrace, Grafana, etc.) are excellent at their core job: monitoring distributed systems. They collect:

• Traces: The path a request takes through your services
• Logs: Events and errors from your applications
• Metrics: System health, latency, error rates

This gives you visibility that something happened and where it happened. You can see that Service A called Service B, the call took 250ms, it returned a 500 error and that the error rate spiked at 14:23 UTC.

For traditional monitoring and alerting, this is great. But for debugging complex issues, especially if you’re leveraging AI coding assistants, this data is incomplete.

The three data gaps that sampling doesn't fix

Gap 1: Request/response payloads for internal services

Observability tools capture HTTP metadata (method, URL, status code, response time) and trace headers for correlation. However, they don't capture the actual request and response bodies: the JSON payloads, form data, or API responses your services exchange.

Why this matters:

When a checkout fails with a 400 error, you can see that the /api/checkout endpoint failed. But you can't see:

• What data was in the checkout request (cart contents, payment method, shipping address)
• What validation error was returned in the response body
• What custom headers were passed (tenant ID, feature flags, API version)

The sampling myth:

Making your traces unsampled (capturing 100% instead of 1-10%) doesn't solve this. You still only get metadata, not payloads. You're just getting metadata for every request instead of a sampled subset of requests.

How teams work around this:

Custom logging. You manually instrument your code to log payloads:

logger.info("Checkout request", extra={"body": request.json()})

This works, but:

• Requires instrumentation in every service
• Creates massive log volumes (and costs)
• Lives in a separate tool from your traces
• Requires manual correlation with your other data

Gap 2: External API calls are black boxes

Your observability tools can tell you that your backend called Stripe, Twilio, or AWS. The call took some amount of milliseconds. It succeeded or failed. However, they don't capture:

• What you sent to the external API
• What the external API returned
• Error details from the external service

Why this matters:

A payment fails. Your trace shows:

POST /api/checkout → calls Stripe → 400 error → returns error to user

But you can't see:

• The payment payload you sent to Stripe (amount, currency, customer ID)
• Stripe's error response ("Currency mismatch: customer configured for EUR, request sent USD")
• Whether retry logic was triggered

The sampling myth:

Unsampled observability still sees external APIs as opaque boxes. Distributed tracing stops at your system boundary. To see what Stripe returned, you need to:

1. Log into Stripe's dashboard
2. Search by timestamp or customer ID
3. Manually correlate with your trace

How teams work around this:

Manual logging before and after every external call:

logger.info("Calling Stripe", extra={"payload": stripe_data})
response = stripe.Charge.create(**stripe_data)
logger.info("Stripe response", extra={"response": response.to_dict()})

This is tedious, error-prone, and easy to forget, especially for one-off integrations.

Gap 3: Frontend context is disconnected

Many observability tools focus only on backend traces and logs. However, some also have RUM / session replay functionalities in their toolkit (e.g. Datadog RUM) or integrations with third-party frontend tools (e.g. Sentry, LogRocket, etc.).

Ultimately, however, obtaining full stack visibility is not as simple as it may seem: it requires more tooling instrumentation, maybe a separate subscription and, oftentimes, manual ID correlation.

In short, you don’t always get an automatic correlation between "what the user did" and "what happened in the backend."

Why this matters:

A user reports: "Checkout is broken." You need to:

1. Get the timestamp from the session replay
2. Find the corresponding backend trace by matching timestamps (hoping there's no clock skew)
3. Correlate the request ID if it was propagated (often it wasn't)

The sampling myth:

Even with 100% unsampled backend traces and full frontend session capture, correlation is still manual. The tools don't automatically link "this user session" to "these backend traces" unless you've explicitly propagated session IDs everywhere and configured correlation across platforms.

The complexity trap

Here's what happens when teams try to solve these gaps with traditional observability tools:

Level 1: Observability (sampled)

• Cost: $ (manageable)
• Traces & logs: 1-10% sampled
• Internal payloads: ❌ By default, you capture only metadata about the request (method, URL, status)
• External APIs: ❌ Black boxes
• Frontend: ❌ No visibility
• Correlation: ❌ No

Level 2: Observability + RUM

The main differences are:

• Cost: $$ (increased due to more tools and instrumentation overhead)
• Frontend: ✅ Visual replay, console logs, browser network, etc.
• Correlation: ⚠️ Manual setup required to propagate session IDs, configure tools, etc.

Level 3: Unsampled observability + RUM

The main differences are:

• Cost: $$$ (high, you’re ingesting and storing 10-100x more data)
• Traces & logs: ✅ 100% captured

Level 4: Unsampled observability + RUM + custom payload logging

The main differences are:

• Cost: $$$$ (very high—now logging full payloads for everything)
• Internal payloads: ✅ Available (if you instrumented it)
• External APIs: ⚠️ Available (if you manually logged every call)

Notice the pattern: complexity and cost increase, but fundamental gaps remain.

What's needed instead: auto-correlated, session-based capture

The problem with traditional observability is the collection model itself: "collect everything, all the time, hope you have what you need later."

There’s a different approach:

1. Collect on-demand: Don't record every request. Record specific sessions where you need visibility (user-reported bugs, errors, failed transactions).
2. Capture everything for those sessions: When you do record, get the complete picture: full traces, request/response payloads (internal and external), frontend context, all automatically correlated.
3. Store it together: Don't split data across observability (traces), logging (payloads), RUM (frontend), and external dashboards (Stripe). Keep it in one place, already linked.

This is what tools like Multiplayer, with its session-based recording, are built for:

• Cost: $ (low: only recording specific sessions, not all traffic)
• Traces & logs: ✅ Unsampled per session
• Internal payloads: ✅ Full content & headers out of the box
• External APIs: ✅ Full content & headers (Stripe, Twilio, AWS), out of the box
• Frontend: ✅ Full capture (visual replay, console, network, device info)

Correlation: ✅ Automatic (everything linked by session)

The benefit for humans and AI tools

Having auto-correlated, full-stack data matters even more when you're using AI to debug.

AI tools and agents are only as good as the data you give them. When you paste a stack trace and some logs into Copilot or Claude, the AI pattern-matches against common issues. It's guessing based on incomplete information.

But if you can give the AI:

• The full user journey (what they clicked, in order)
• The exact request the frontend sent
• What your backend received and how it processed it
• What you sent to Stripe and what Stripe returned
• Where in that chain it broke

...now the AI can provide specific diagnosis based on what actually happened in your system.

Getting that complete picture with traditional observability, even unsampled, is much more costly, time-consuming and effort-intense. You'd need to manually gather fragments of information from multiple data silos and tools and then paste them all in.

The path forward

If you're an engineering leader evaluating observability tools, ask these questions:

1. What does it cost to have complete, unsampled data for the requests I care about?
   • If the answer involves "collect everything 24/7," the cost will be prohibitive at scale.
2. Can this tool capture request/response payloads for internal services without custom instrumentation?
   • If no, you're signing up for ongoing instrumentation work and incomplete coverage.
3. Can this tool automatically capture what I send to and receive from external APIs (Stripe, Twilio, AWS)?
   • If no, external services remain black boxes unless you manually log every call.
4. Does this tool automatically correlate frontend user sessions with backend behavior?
   • If no, you're manually stitching data together during incidents.

The goal isn't more data. It's the right data, captured automatically, already correlated, available when you need it. Whether you're debugging manually or using AI to help.

When I first read GitHub’s article about spec-driven development, my first impression was: “Wait a minute. I’ve heard this before…”

Here's how they describe it:

You provide a high-level description of what you’re building and why […] It’s about user journeys, experiences, and what success looks like. […] Now you get technical. In this phase, you provide the coding agent with your desired stack, architecture, and constraints, and the coding agent generates a comprehensive technical plan…

Does this sound familiar? It should.

We used to call this Big Design Up Front (BDUF). We spent decades running away from it. And now we're sprinting right back, rebranding it as innovation for the AI era. From GitHub:

[…] we’re rethinking specifications — not as static documents, but as living, executable artifacts that evolve with the project. Specs become the shared source of truth. When something doesn’t make sense, you go back to the spec; when a project grows complex, you refine it; when tasks feel too large, you break them down.

The irony is so thick you could easily represent it with a UML diagram. Documentation was always meant to be a living, evolving artifact. Engineering teams should have always started with some upfront system design before jumping into code.

But, also, implementing those best practices was harder than it sounded. Documentation was outdated the moment you pushed your next commit, writing it well was a days-long slog, and no amount of good intentions survived the pressure to ship new features.

So what’s changed? The biggest difference between BDUF and spec-driven development is that AI changes the economics of doing it well.

For the first time, writing a thorough, living specification isn't a weeks-long documentation marathon. It's a few hours (minutes?) of conversation.

That’s why teams can and should adopt it now. Spec-driven development with AI is genuinely better than BDUF and it will make your team more productive.

A quick trip through history

To understand why this matters, it's worth remembering what we're comparing it to.

In the waterfall days, BDUF was gospel. You'd spend months perfecting every requirement, every architecture diagram, every interface specification before writing a single line of code. The theory was sound: think deeply before building, catch problems early, avoid expensive rewrites.

The reality was brutal. Requirements changed while you were still in month three of design reviews. Technologies evolved. Markets shifted. By the time you finished your perfect blueprint, it was already obsolete. And when implementation finally started, reality had an annoying habit of disagreeing with your theoretical perfection.

Then the Agile Manifesto arrived and we all collectively exhaled. Finally. No more soul-crushing design documents that nobody reads.

But here's what happened: a lot of teams heard "Responding to change over following a plan," and translated it to "don't plan at all." They took "working software over comprehensive documentation" to mean "no documentation."

The pendulum swung from BDUF paralysis to "we'll figure it out as we go" chaos.

I've written about why this is a problem before. Modern distributed systems are too complex to hold in your head. Without some upfront design, you end up with:

• Teams working from different mental models of the same system
• Architecture decisions made by accident rather than intention
• Critical trade-offs (security, scalability, cost) discovered too late
• Knowledge that lives in someone's head until they leave

The answer isn't BDUF. But it's also not "no design." It’s somewhere in the middle: enough upfront design to establish shared vision, identify significant risks, and make conscious trade-offs, without the paralysis of trying to specify everything in advance.

We always knew this. We just struggled to do it consistently, because it takes discipline, the benefits feel distant, and there's always pressure to just start coding.

AI tools are changing that calculus.

Why AI agents need structure and how they make it easier

Here's the thing about AI coding tools and agents: they need specificity and structure.

Why? Because they lack the capabilities that let human developers work with ambiguity:

• They lack context beyond the prompt. When you tell a senior engineer "build an authentication system," they know you're already using Auth0 for your customer portal, and follow the same pattern for consistency. An AI agent? It might give you a perfectly functional JWT implementation from scratch, or suggest Passport.js, or recommend Firebase Auth. All reasonable choices in isolation, but potentially creating fragmentation in your architecture. They don't have access to your team's tribal knowledge, past design decisions, or the unwritten "we standardized on XYZ" agreements.
• They don't think defensively or double-check edge cases. A human developer building a user registration endpoint will pause and think: "Wait, what if someone registers with the same email twice? What if the email service is down? What about internationalized characters in names?". They'll ping you on Slack if they're unsure. An AI agent will confidently write the happy path and keep moving.
• They struggle with ambiguity. Tell a human developer "make it performant" and they'll ask clarifying questions or make reasonable assumptions based on the application type. Tell an AI agent "make it performant" and you might get... literally anything. But write "Ensure 95th percentile response time stays under 200ms" and suddenly they have something concrete to optimize for.

That’s why GitHub created Spec Kit, a toolkit that formalizes a four-phase process: Specify (user journeys, experiences, outcomes) → Plan (stack, architecture, constraints) → Tasks (small, reviewable chunks) → Implement (AI generates code).

But here's what's different from BDUF: you don't have to write all of this yourself, from scratch, in a vacuum. The process is collaborative and iterative, with AI doing the heavy lifting at every stage.

What this actually looks like in practice

At each stage of this iterative conversation with AI tools, the humans are doing the high-value work: making judgment calls, catching misalignments, applying context the AI doesn't have. The AI is doing the drafting, the structuring, the fleshing-out.

What used to take days of writing and review meetings now takes hours.

The barrier to actually doing upfront design properly (the time cost, the documentation overhead, the discipline required) drops dramatically.

"We need to do this for the AI tools to work well" means that engineering teams finally:

• Write clear specifications before coding
• Document architectural decisions while they're fresh (not six months later when someone asks "why did we build it this way?")
• Break down work into reviewable, testable chunks
• Maintain living documentation that evolves with the system (actually keeping it updated as things change)

The humans get better collaboration, clearer communication, and knowledge that survives beyond individual team members. The AI gets the context it needs to generate useful code. Future developers (human or AI) inherit comprehensible systems instead of archaeological dig sites.

Where this really pays off: parallel AI agents

The single most compelling argument for spec-driven development is what happens when you start running multiple AI coding agents in parallel.

This is where structured upfront design becomes essential: when you have several agents working simultaneously on different parts of a system (e.g. one building the API layer, another handling the data model, another working on the frontend integration) the spec and the task breakdown become the coordination mechanism. They're how the agents know what they're each responsible for, what interfaces they can rely on from each other, and what the boundaries of their work are.

Without that shared source of truth, parallel agents will do what parallel human teams do without proper coordination: make inconsistent assumptions, build to incompatible interfaces, duplicate work, and create integration problems that are expensive to untangle later.

With a well-structured spec and clearly decomposed tasks, each agent has exactly the context it needs. It knows the overall architecture. It knows the constraints. It knows what it owns and what it depends on. The result is faster development that actually fits together.

Full circle, but wiser

So yes, there's a family resemblance between spec-driven development and BDUF. Both involve designing before you build. Both emphasize clear requirements and structured planning.

But the differences matter. BDUF was slow, manual, expensive, and brittle. Spec-driven development with AI is fast, iterative, collaborative, and maintainable.

More importantly, it's actually achievable.

The reason teams skipped upfront design wasn't that they didn't believe in it, it was because the cost was too high relative to the short-term pressure to just start coding. AI changes that equation. When a solid spec takes hours instead of weeks, the discipline becomes sustainable.

We've come full circle, but we've brought better tools.

One more thing AI agents need

Better specs and clearer task decomposition are a significant step forward. But specs and plans describe intentions. What AI agents also need (especially for debugging, iteration, and understanding production behavior) is visibility into what systems actually do at runtime.

Your AI coding assistant can't debug a production issue if your observability stack only shows sampled traces. It can't understand a user-reported bug if you can't connect frontend errors to backend failures. It can't suggest meaningful fixes if it can't see the complete context of what actually happened.

The same trend that's pushing us toward better design practices upfront should also push us toward better observability practices in production. AI agents are revealing gaps in both, and closing those gaps is what will make AI-assisted development genuinely powerful, end to end.

AI coding assistants have transformed how we write code. For example, GitHub Copilot, Cursor, and ChatGPT can generate Stripe integration boilerplate in seconds. They'll scaffold your payment flow, suggest error handling patterns, and even write unit tests.

But when your Stripe integration breaks in production can AI actually help you debug it? The honest answer: not really. At least, not yet.

Here’s why.

The limitation: AI needs context it can't get on its own

When you ask an AI assistant "why is my Stripe payment failing?", it responds with educated guesses based on common patterns:

• "Check if the card is expired"
• "Verify you're using the correct currency format"
• "Ensure you're handling insufficient funds errors"
• "Confirm your API keys are valid"

These are all reasonable suggestions. They're based on what usually causes Stripe payment failures across thousands of codebases the AI was trained on. But the AI doesn't know what actually happened in your specific case. It doesn't have access to:

• What payload did your frontend send to your backend?
• What request did your backend construct and send to Stripe?
• What response did Stripe return?
• How did your backend process that response?
• What error (if any) made it back to the user?

Without this runtime context, the AI is pattern-matching. It's giving you a troubleshooting checklist, not a diagnosis.

The problem: getting context for external APIs is effort-intensive

The irony is that the data AI needs often exists, it's just scattered and difficult to access.

When a Stripe integration breaks, you need to see the complete request/response exchange: what you sent them, what they returned, and how your system handled it. This is where traditional debugging approaches fall short, particularly for external API calls.

APM tools show that you made the call and how long it took, but not the payload exchange. Most Application Performance Monitoring platforms (Datadog, New Relic, Dynatrace) can track that your backend called stripe.charges.create() and that it took 340ms. They might even show it returned a 400 error. But they typically don't capture the full request body you sent or the detailed error response Stripe returned. At least not by default.

In theory, APM tools CAN capture this data IF properly instrumented. You can configure custom spans, add metadata attributes, and enrich traces with payload information. But this requires:

• Configuration complexity: Custom instrumentation for each external API integration
• Cost considerations: Full payload capture dramatically increases data volumes and APM bills
• Intentional redaction: Many teams deliberately avoid logging payment data due to PCI compliance requirements

The result? When debugging external API failures, most teams end up manually gathering context from multiple sources:

1. Check your application logs (CloudWatch, Splunk) for what you sent
2. Check Stripe's dashboard for their logs of the request
3. Check your error monitoring (Sentry, Rollbar) for the exception
4. Check your frontend session replay to see what the user experienced
5. Manually correlate timestamps, request IDs, and user sessions across all of these

Once you've spent 30-60 minutes gathering this fragmented context, then you can paste it into an AI assistant and ask for help. But at that point, you've already done most of the debugging work yourself.

A real example: the AMEX one-time code bug

Let's walk through a concrete scenario to see where AI debugging breaks down.

The Problem:

After deploying new payment features, customers complain they don't receive one-time authentication codes on their phones when paying with American Express cards. The issue is intermittent and doesn't affect Visa or Mastercard. Engineering teams suspect an authentication bug but can't reproduce it reliably.

Traditional Debugging Workflow

Step 1: Check error monitoring

Sentry shows some frontend timeout errors during checkout, but no clear stack trace pointing to the root cause. The errors are generic: "Request timeout after 30s."

Step 2: Check application logs

Search CloudWatch for logs around the time customers reported issues. Find log entries showing successful calls to Stripe's API, but the logs don't include full request payloads (they were redacted for PCI compliance).

Step 3: Check Stripe's dashboard

Log into Stripe's dashboard and search for the affected transactions by timestamp and customer email. Finally discover that some requests are receiving authentication_required responses, but your system isn't handling them correctly.

Step 4: Reproduce locally

Try to reproduce the issue in staging with test AMEX cards. It doesn't happen consistently. Realize you need to see the actual production payloads to understand the pattern.

Step 5: Add more logging and wait

Deploy additional logging to capture more details about AMEX transactions. Wait for the issue to occur again.

Total time to diagnosis: Hours to days, depending on how quickly the issue reproduces.

At this point, could you ask AI for help? You could paste your fragmented logs and ask "why might Stripe authentication fail for AMEX?". The AI would suggest checking 3DS configuration, webhook handling, and card type compatibility. All reasonable but generic advice.

Full stack session recording with auto-correlated API data

Now imagine a different debugging workflow:

1. A customer reports the issue
2. You pull up the full-stack replay of their session
3. You see:

• The exact checkout form they filled out (frontend)
• The API request your backend constructed (POST /v1/payment_intents)
• The full payload sent to Stripe, including the discovery that card numbers for AMEX are getting an extra digit appended (aha! that’s the issue!)
• Stripe's response: invalid_card_number
• How your backend handled this response (incorrectly treating it as a generic timeout)
• What the user saw (spinning loader with no error message)

Total time to diagnosis: 5-10 minutes.

Now when you ask AI for help, you can provide the complete context: "Here's the exact payload we sent to Stripe for AMEX cards. Stripe returned invalid_card_number. Our code is adding an extra digit. Why?"

The AI can now give you a specific answer: "Your string concatenation logic in formatCardNumber() is applying AMEX-specific formatting twice. Here's the fix..." Instead of guessing at possibilities, it's debugging actual runtime behavior.

The future: auto-correlation makes AI debugging actually useful

The next generation of debugging doesn’t depend exclusively on the quality of AI models, but it’s heavily dependent on feeding AI tools the context they need to be useful.

Auto-correlation tools like Multiplayer automatically capture and link data across your entire stack: frontend interactions, backend traces and logs, and end-to-end request/response headers and content from internal service and external API calls. This data becomes the foundation for effective AI-assisted debugging.

When AI has access to:

• What the user actually did (not what you think they did)
• What data your system actually sent (not what it should send)
• What external APIs actually returned (not what the docs say they return)
• How your code actually processed the response (not what you intended)

... then AI can shift from suggesting possibilities to diagnosing realities.

This is why auto-correlation and AI coding assistants are complementary, not competing technologies. Correlation tools provide the runtime context that transforms AI from a pattern-matcher into a debugger.

2025 was a defining year for Multiplayer.

We focused on a simple but ambitious goal: making debugging faster, less fragmented and less manual. That meant meeting developers where they were already working and capturing the right context at the right time.

Across the year, Multiplayer evolved from a powerful session recording tool into a full workflow for understanding what actually happens in production - from the user’s screen all the way to deep backend calls - and acting on that knowledge faster.

Here’s a look back at what we shipped in 2025, and where we’re headed next.

Full stack session recordings

At the core of Multiplayer is the idea that debugging starts with context. This year, we significantly expanded how that context is captured, shared, and used.

• Multiple recording modes: You’re in control of what gets captured and when. Record on-demand when users hit issues, or run continuous recording in the background to automatically capture issues and exceptions. No more "I wish we had been recording when that happened."
• Annotations: Sketch directly on recordings and annotate any data point collected, from individual timestamps to clicks, traces, and spans. Your team has all the context they need to understand exactly where the UI broke or which log entry needs investigation.
• Mobile support: We've shipped React Native support, bringing the same full stack recording capabilities you have on web to your mobile applications. Whether you're troubleshooting a checkout flow on iOS or diagnosing API failures on Android, you get the complete picture.

AI-powered workflows

AI tools are only as useful as the context you give them. In 2025, we focused on making Multiplayer a high-quality data source for AI-assisted debugging.

• MCP server: brings full stack session recordings into MCP-compatible AI tools like Cursor, Claude Code, Copilot, Windsurf, and Zed. Instead of feeding your IDE partial context, you give it everything: frontend replays, user actions, backend traces, logs, request/response payloads, and your team's annotations.
• VS Code extension: Your full stack session recordings are now available directly in your editor: pull up any recording, review frontend screens, backend traces, logs, request/response content and headers, and jump to the exact line of code where an error occurred.

Full cycle debugging

Debugging doesn’t end when the issue is fixed. It’s also about learning, documenting, and preventing regressions.

• Notebooks: An interactive sandbox for designing, debugging and documenting real-world API integrations. You can also automatically generate test scripts from your full stack session recordings to verify fixes, document real behavior, and prevent regressions.
• System architecture auto-documentation: Automatically map all your components, dependencies, and APIs and visualize your application's structure. No more outdated, manually-drawn architecture diagrams - your system maps stays current as your system evolves.

Better onboarding & resources

We also invested heavily in making Multiplayer easier to adopt and understand.

• A major documentation overhaul with 34+ new pages covering: use case examples, tool comparisons (FullStory, LogRocket, Sentry, and others), technical deep-dives on recording modes and data collection
• Streamlined onboarding with framework-specific setup guides for React, Next.js, Angular, and Vue.js. Getting the in-app widget running takes just minutes.
• A free sandbox and demo app to experience full-stack session recordings before installing anything.

What's next: 2026 roadmap

The features below are currently in private beta with design partners and enterprise customers, and are planned for GA in early 2026.

Multiplayer AI agent

Automatically receive suggested fixes and pull requests based on issues identified in session recordings.

Today, teams manually feed recordings into AI tools. With the Multiplayer AI agent, this workflow becomes automated: instead of alerts, developers receive actionable PR suggestions grounded in real production context.

Conditional recording mode

Automatically record sessions for specific users or conditions, without manual start/stop and without “always-on recording” overhead.

This allows teams to capture issues even when users don’t report them, eliminating incomplete tickets and giving engineers immediate, actionable context.

Issue tracking

A unified view of errors, exceptions, and performance issues across frontend and backend, all linked to the sessions where they occurred.

User tracking

View all active users and remotely trigger recording conditions during live sessions. Ideal for testing, debugging, and high-touch support scenarios.

Slack integration

Get notified when recordings are created and share session links directly in Slack, keeping context close to where conversations already happen.

Thank you!

None of this would be possible without the teams who trusted Multiplayer in production, shared feedback candidly, and pushed us to build something better.

Thank you to our users, design partners, community members, and everyone who challenged us to think deeper about debugging, support, and how engineers actually work.

We’re excited for what’s ahead in 2026 and grateful to be building it together. 💜

You're using LogRocket and, for "full stack" visibility you also integrate it with Datadog. A user reports a checkout error. You open the session replay, see the frontend flow, and follow the link to the backend integration... but the trace is sampled out. You see some backend data, but you're missing the actual request payload that failed. Now you're back in Datadog, manually searching for the right trace, trying to find the request content, and piecing together what actually broke.

This is the gap between frontend analytics tools with backend integrations and true full-stack debugging tools.

TL;DR

Choose Multiplayer if: You need to resolve technical issues fast, with complete, unsampled, frontend + backend context in one place, and you need to improve your debugging workflows across multiple teams (e.g. Support → Engineering).

Choose LogRocket if: You primarily need user behavior analytics and frontend monitoring.

Key difference: LogRocket captures frontend behavior with optional sampled backend data through third-party integrations. Multiplayer captures complete, unsampled full-stack sessions (frontend and backend) out of the box, with no integrations required.

Quick comparison

More resources:

• Multiplayer vs LogRocket deep dive
• Multiplayer vs other tools

The real difference: frontend + integrations vs native full-stack

LogRocket: frontend-first with partial backend visibility

LogRocket captures comprehensive frontend data: clicks, page loads, console logs, network requests. For product analytics and UX monitoring, this works well. You can also integrate with APM tools like Datadog or New Relic to link out to some backend data.

But here's the catch: the backend data is sampled, and critical debugging information is still missing. Even with integrations configured, you don't get:

• Complete, unsampled logs and traces (APM sampling means you might miss the exact data you need)
• Request/response content and headers from internal service calls

Not to mention that the backend data still lives in a separate tool. When debugging a production issue, you're forced to:

• Search LogRocket session replays for the frontend behavior
• Follow a link to switch to your APM tool for backend data (hoping it wasn’t sampled out)
• Manually correlate timestamps between systems
• Still miss critical data like full request/response content and headers from internal services

Multiplayer: complete full-stack context by default

Multiplayer captures full-stack session recordings natively, with zero sampling. Every frontend action is automatically correlated with complete backend traces, logs, and request/response data, in a single timeline.

When that checkout error happens, you see:

• The user's click
• The API request
• The unsampled backend trace showing which service failed
• The exact error message and stack trace
• Request/response content and headers from internal service calls

No sampling gaps. No tool switching. No missing data.

By leveraging OpenTelemetry, Multiplayer works with any observability platform, ensuring no vendor lock in or the need for additional tools.

Recording control: always-on vs choose-your-adventure

LogRocket: Always-on recording via SDK

LogRocket uses always-on recording through its SDK: you're recording and storing everything, whether you need it or not. This works for aggregate analytics, but creates friction for debugging:

• No granular control over when and which sessions to capture
• Can't easily capture specific user cohorts or error scenarios
• Limited to SDK installation (no browser extensions or widgets for end-users)

Multiplayer: record what you need, when you need it

Multiplayer offers three recording modes and three installation methods. It’s a choose-your-own-adventure approach that adapts to your teams’ workflows.

Recording modes:

• On-demand: Start/stop recording manually. Perfect for reproducing specific bugs.
• Continuous: Start/stop recording in the background, for your entire working session. Great for development and QA to automatically save sessions with errors and exceptions.
• Conditional: Silent capture of specific user cohorts or error conditions.

Installation methods:

• In-app widget: Let users report issues with replays attached automatically, directly from your app
• Browser extension: Quickly capture a bug, unexpected behavior, or new feature idea
• SDK / CLI Apps: Full integration for programmatic control

Real scenario: Your support team gets a vague bug description. They ask the end-user to record a full stack session replay through the in-app widget. Support is able to fully understand the problem and they can reproduce the issue in 30 seconds. It’s immediately clear what the next steps (or possible fixes) are.

Support workflows: serial handoffs vs parallel collaboration

LogRocket: Built for analytics, adapted for debugging

LogRocket's collaboration features focus on sharing and reviewing sessions:

• Share session links
• View frontend behavior
• Check integrated backend data (when available and not sampled out)

But for technical debugging, you're still doing serial handoffs:

1. Support searches and watches the replay (frontend only)
2. Support checks for backend data (might be sampled out)
3. Support escalates to Engineering with partial context
4. Engineering opens APM tool to find complete traces
5. Engineering searches for request/response content
6. Multiple rounds of back-and-forth to gather full context

Multiplayer: complete context from the start

Multiplayer is built for parallel Support ↔ Engineering workflows:

Single, sharable timeline:

• Frontend screens, user actions, backend traces, logs, request/response data, and user feedback, all correlated automatically
• Support sees the user's experience; Engineering sees the technical root cause
• Both work from the same data, at the same time

Annotations and collaboration:

• Sketch directly on recordings
• Annotate any data point in the timeline
• Create interactive sandboxes for API integration
• Link sessions directly to Zendesk, Intercom, or Jira tickets

Real scenario: Support receives a bug report via the in-app widget (with replay automatically attached). They open it, see the user's error, scroll down to see the backend trace showing a 500 error from the auth service, view the exact request that failed, annotate the failing request, and share with the backend team, all in 60 seconds. The backend team has complete context and starts fixing the issue immediately.

What you actually get per session

LogRocket captures:

• User clicks ✓
• Page navigations ✓
• DOM events ✓
• Console messages ✓
• Network requests ✓
• Backend traces (link to another tool, sampled data) ✓

Multiplayer captures:

Everything LogRocket captures, plus:

• Correlated backend logs and traces (any observability platform, unsampled) ✓
• Backend errors ✓
• Full request/response content and headers (including from internal service calls) ✓
• User feedback integrated in the timeline ✓
• Service and dependency maps ✓

Integration and deployment: flexibility matters

LogRocket:

• SDK installation only
• Requires third-party APM integration for backend data (additional vendor, additional setup)
• Proprietary AI agent working with partial context and no support for AI coding workflows beyond their platform

Multiplayer:

• Multiple installation methods (extension, widget, SDK)
• Works with any observability platform, language, framework, architecture
• MCP server for AI-native debugging in your IDE or AI assistant

For AI-forward teams: LogRocket's proprietary AI works only within their platform and has limited context. Multiplayer's MCP server feeds complete session context (frontend + unsampled backend + annotations + full request/response data) directly to Claude, Cursor, or your AI tool of choice. Ask "why did this checkout fail?" and get answers grounded in complete, unsampled session data.

Which tool should you choose

Choose Multiplayer if:

• You need to fix bugs and resolve technical issues fast
• You want complete, unsampled backend visibility without integration complexity
• Your support team regularly escalates issues to engineering
• You need full request/response content from internal services and middleware
• You want flexible recording modes (not just always-on)
• You want AI-native debugging workflows with complete context

Choose LogRocket if:

• Your primary goal is product analytics and frontend monitoring
• PM and product teams are your main users
• You're comfortable with sampled backend data and managing APM integrations
• Always-on, frontend-focused recording meets your needs

Consider both if:

• You're a large organization where user analytics and technical debugging are handled by separate teams with separate objectives

The bottom line

LogRocket is a solid user analytics platform with frontend monitoring capabilities. The APM integrations add some backend visibility, but you're still working with sampled data, missing critical information, and switching between tools to piece together what happened.

Multiplayer gives you the complete picture: frontend and backend, unsampled traces, full request/response content, all correlated automatically in a single timeline. It's session replay designed for the reality of debugging modern distributed systems, where you need complete technical context to fix issues fast.

You've got a critical bug report. A user can't complete their purchase at checkout. You open Mixpanel, navigate to session replay, watch them click through the checkout flow... and then they get stuck. The frontend looks fine, but something's clearly broken. What failed on the backend? Was it a payment service timeout? A validation error?

Now you're digging through logs, checking APM dashboards, correlating timestamps, and trying to piece together what happened on the backend.

This is the gap between product analytics platforms with session replay features and purpose-built debugging tools.

TL;DR

Choose Multiplayer if: You need to resolve technical issues fast, with complete frontend + backend context in one place, and you need to improve your debugging workflows across multiple teams (e.g. Support → Engineering).

Choose Mixpanel if: You primarily need product analytics with session replay as a supplementary feature for understanding user behavior.

Key difference: Mixpanel shows you how users behave on your frontend, aggregating website performance metrics. Multiplayer shows how your system behaves, from user actions to backend traces, and how to fix a bug (or have your AI coding assistant do it for you).

Quick comparison

More resources:

• Multiplayer vs Mixpanel deep dive
• Multiplayer vs other tools

The real difference: frontend vs full stack

Mixpanel: product analytics platform with session replay bolted on

Mixpanel is a mature product analytics platform with core features such as: event tracking, funnels, cohort analysis, A/B testing. Session replays is an additional feature in this toolset to help understand user behavior and product metrics.

But when you need to debug a technical issue, you only get frontend data. Mixpanel has no backend data or observability tools integrations, which means:

• No visibility into API calls beyond the browser
• No distributed traces showing which services were involved
• No request/response content from your backend services
• No console messages or HTML source code

When debugging a production issue, you're forced to:

• Search through Mixpanel's session replays (frontend only)
• Switch to your observability platform and hunt through logs to find the right data
• Manually correlate timestamps across systems
• Piece together what happened without a unified view

Multiplayer: purpose-built for debugging

Multiplayer captures full stack session recordings by default. Every frontend action is automatically correlated with backend traces, logs, and request/response data, in a single, unified timeline.

When the checkout button fails, you see:

• The user's click
• The API request
• The backend trace showing which service failed
• The exact error message and stack trace
• Request/response content and headers from internal service calls

No hunting. No manual correlation. No tool switching. Everything you need to fix the bug is in one place.

Recording control: always-on vs choose-your-adventure

Mixpanel: Always-on recording via SDK

Mixpanel uses always-on recording through its SDK: you're recording and storing everything, whether you need it or not. This works for aggregate analytics, but creates friction for debugging:

• No granular control over when and which sessions to capture
• Can't easily capture specific user cohorts or error scenarios
• Limited to SDK installation (no browser extensions or widgets for end-users)

Multiplayer: record what you need, when you need it

Multiplayer offers three recording modes and three installation methods. It’s a choose-your-own-adventure approach that adapts to your teams’ workflows.

Recording modes:

• On-demand: Start/stop recording manually. Perfect for reproducing specific bugs.
• Continuous: Start/stop recording in the background, during your entire working session. Great for development and QA to automatically save sessions with errors and exceptions.
• Conditional: Silent capture of specific user cohorts or error conditions.

Installation methods:

• In-app widget: Let users report issues with replays attached automatically, directly from your app
• Browser extension: Quickly capture a bug, unexpected behavior, or new feature idea
• SDK / CLI Apps: Full integration for programmatic control

Real scenario: Your support team gets a vague bug description. They ask the end-user to record a full stack session replay through the in-app widget. Support is able to fully understand the problem and they can reproduce the issue in 30 seconds. It’s immediately clear what the next steps (or possible fixes) are.

Support workflows: serial handoffs vs parallel collaboration

Mixpanel: Built for product teams, not support workflows

Mixpanel's workflow is designed for product analytics:

• Track events and user properties
• Analyze funnels and retention
• View session replays as supplementary context
• Share reports and dashboards

For technical debugging, you're doing manual work:

1. Support searches and watches a session replay in Mixpanel
2. Support escalates to Engineering with partial context
3. Engineering opens observability tools to find backend data
4. Engineering searches for the right logs and traces
5. Multiple rounds of back-and-forth to gather full context

Multiplayer: complete context from the start

Multiplayer is built for parallel Support ↔ Engineering workflows:

Single, sharable timeline:

• Frontend screens, user actions, backend traces, logs, request/response data, and user feedback, all correlated automatically
• Support sees the user's experience; Engineering sees the technical root cause
• Both work from the same data, at the same time

Annotations and collaboration:

• Sketch directly on recordings
• Annotate any data point in the timeline
• Create interactive sandboxes for API integrations
• Link sessions directly to Zendesk, Intercom, or Jira tickets

What you actually get per session

Mixpanel captures:

• User clicks ✓
• Page navigations ✓
• DOM events ✓
• Network requests ✓

Multiplayer captures:

Everything Mixpanel captures, plus:

• Console messages ✓
• HTML source code ✓
• Correlated backend logs and traces (any observability platform, unsampled) ✓
• Backend errors ✓
• Full request/response content and headers (including from internal service calls) ✓
• User feedback integrated in the timeline ✓
• Service and dependency maps ✓

Integration and deployment: flexibility matters

Mixpanel:

• SDK installation only
• SaaS deployment only
• MCP server for interrogating product data (not debugging)

Multiplayer:

• Multiple installation methods (extension, widget, SDK)
• SaaS or self-hosted deployment
• Works with any observability platform, language, framework, architecture
• MCP server feeds complete context to your IDE or AI tool

For teams with compliance requirements: Mixpanel's SaaS-only model can be a dealbreaker. Multiplayer's self-hosted option keeps sensitive data in your infrastructure.

For AI-forward teams: Mixpanel's MCP server is optimized for product data analysis: understanding user behavior and product metrics. Multiplayer's MCP server feeds complete debugging context (frontend + unsampled backend + annotations + full request/response data) directly to Claude, Cursor, or your AI tool of choice. Ask "why did this checkout fail?" and get answers grounded in complete session data, not just frontend clicks.

Which tool should you choose

Choose Multiplayer if:

• You need to fix bugs and resolve technical issues fast
• You want complete backend visibility alongside frontend data
• Your support team regularly escalates issues to engineering
• You need full request/response content from internal services
• You want flexible recording modes and installation options
• You have compliance requirements that need self-hosting
• You want AI-native debugging workflows with complete context

Choose Mixpanel if:

• Your primary goal is product analytics (funnels, cohorts, retention, A/B testing)
• Product and UX teams are your main users
• Session replay is a supplementary feature for understanding user behavior
• You don't need backend debugging data
• You're comfortable managing separate tools for analytics and debugging

Consider both if:

• You're a large organization where product analytics and technical debugging are handled by separate teams with separate objectives

The bottom line

Mixpanel is a powerful product analytics platform with comprehensive event tracking and analysis capabilities. Session replay is an add-on feature designed for understanding user behavior, not for debugging technical issues across your full stack.

Multiplayer is purpose-built for debugging. Full-stack session recordings give you frontend and backend context, automatically correlated in a single timeline. It's session replay designed for the reality of modern distributed systems, where you need complete technical context to fix issues fast.

You've got a bug report from a frustrated user. You open PostHog, search through all the session replays to find the right one, watch the frontend interaction, and see where they got stuck. But you can't see what failed on the backend. Was it a timeout? A validation error? A service dependency issue?

Now you're digging through logs, checking APM dashboards, correlating timestamps, and trying to piece together what happened on the backend.

This is the gap between product analytics platforms with session replay features and purpose-built debugging tools.

TL;DR

Choose Multiplayer if: You need to resolve technical issues fast, with complete frontend + backend context in one place, and you need to improve your debugging workflows across multiple teams (e.g. Support → Engineering).

Choose PostHog if: You primarily need product analytics with session replay as a supplementary feature for understanding user behavior.

Key difference: PostHog is a product analytics platform with frontend-only session replay. Multiplayer is purpose-built for debugging with full-stack session recordings, from user actions to backend traces, showing you how to fix a bug (or have your AI coding assistant do it for you).

Quick comparison

More resources:

• Multiplayer vs PostHog deep dive
• Multiplayer vs other tools

The real difference: product analytics vs debugging tool

PostHog: Analytics platform with session replay

PostHog is a comprehensive product analytics platform. Session replay is one feature among many (feature flags, A/B testing, surveys, product analytics). For understanding user behavior, funnel analysis, and product decisions, this works well.

But when you need to debug a technical issue, you only get frontend data. PostHog has no backend data or observability integrations, which means:

• No visibility into API calls beyond the browser
• No distributed traces showing which services were involved
• No request/response content from your backend services

When debugging a production issue, you're forced to:

• Search through PostHog to find the right session replay (frontend only)
• Switch to your observability platform for backend data
• Manually correlate timestamps across systems
• Piece together what happened without a unified view

Multiplayer: Purpose-built for debugging

Multiplayer is focused on resolving technical issues. Full-stack session recordings capture everything you need in a single timeline:

• The user's frontend actions
• The API requests
• Backend traces showing which services were called
• Request/response content and headers from internal service calls
• Error messages and stack traces
• User feedback

No searching through hundreds of sessions. No tool switching. No manual correlation.

Recording control: analytics-first vs choose-your-adventure

PostHog: conditional recording

PostHog offers always-on recording (via SDK) based on conditions you can customize. This works for product analytics where you want to capture broad user behavior:

• No granular control over when and which sessions to capture
• Limited to SDK installation (no browser extensions or widgets for end-users)

Multiplayer: record what you need, when you need it

Multiplayer offers three recording modes and three installation methods. It’s a choose-your-own-adventure approach that adapts to your teams’ workflows.

Recording modes:

• On-demand: Start/stop recording manually. Perfect for reproducing specific bugs.
• Continuous: Start/stop recording in the background during your entire working session. Great for development and QA to automatically save sessions with errors and exceptions.
• Conditional: Silent capture of specific user cohorts or error conditions.

Installation methods:

• In-app widget: Let users report issues with replays attached automatically, directly from your app
• Browser extension: Quickly capture a bug, unexpected behavior, or new feature idea
• SDK / CLI Apps: Full integration for programmatic control

Real scenario: Your support team gets a vague bug description. They ask the end-user to record a full stack session replay through the in-app widget. Support is able to fully understand the problem and they can reproduce the issue in 30 seconds. It’s immediately clear what the next steps (or possible fixes) are.

Support workflows: serial handoffs vs parallel collaboration

PostHog: Built for product teams, adapted for support

PostHog's workflow is designed for product analytics:

• Search through session replays to find the relevant one
• Share session links with your team
• View frontend behavior
• Build dashboards and funnels

But for technical debugging, this creates serial handoffs:

1. Support searches and watches the replay (frontend only)
2. Support escalates to Engineering with partial context
3. Engineering opens observability tools to find backend data
4. Engineering searches for the right logs and traces
5. Multiple rounds of back-and-forth to gather full context

Multiplayer: complete context from the start

Multiplayer is built for parallel Support ↔ Engineering workflows:

Single, sharable timeline:

• Frontend screens, user actions, backend traces, logs, request/response data, and user feedback, all correlated automatically
• Support sees the user's experience; Engineering sees the technical root cause
• Both work from the same data, at the same time

Annotations and collaboration:

• Sketch directly on recordings
• Annotate any data point in the timeline
• Create interactive sandboxes for API integrations
• Link sessions directly to Zendesk, Intercom, or Jira tickets

What you actually get per session

PostHog captures:

• User clicks ✓
• Page navigations ✓
• DOM events ✓
• Console messages ✓
• Network requests ✓
• Backend errors (requires PostHog backend instrumentation—vendor lock-in) ✓

Multiplayer captures:

Everything PostHog captures, plus:

• Correlated backend logs and traces (any observability platform, unsampled) ✓
• Backend errors (no vendor lock-in) ✓
• Full request/response content and headers (including from internal service calls) ✓
• User feedback integrated in the timeline ✓
• Service and dependency maps ✓

Which tool should you choose

Choose Multiplayer if:

• You need to fix bugs and resolve technical issues fast
• You want complete backend visibility alongside frontend data
• Your support team regularly escalates issues to engineering
• You need full request/response content from internal services
• You want flexible recording modes and installation options
• You want AI-native debugging workflows with complete context

Choose PostHog if:

• Your primary goal is product analytics (funnels, feature flags, A/B testing, surveys)
• Product and UX teams are your main users
• Session replay is a supplementary feature for understanding user behavior
• You don't need backend debugging data
• You're comfortable managing separate tools for analytics and debugging

Consider both if:

• You're a large organization where product analytics and technical debugging are handled by separate teams with separate objectives

The bottom line

PostHog is a powerful product analytics platform with many valuable features. Session replay is one tool among many, designed for understanding user behavior and product performance, not for debugging technical issues across your full stack.

Multiplayer is purpose-built for debugging. Full-stack session recordings give you frontend and backend context, automatically correlated in a single timeline. It's session replay designed for the reality of modern distributed systems, where you need complete technical context to fix issues fast.

You've got a critical bug report. A user can't complete checkout. You open Fullstory, watch the session replay, see them click the checkout button... and then what? The frontend looks fine, but something's clearly broken. Now you're digging through logs, checking APM dashboards, correlating timestamps, and trying to piece together what happened on the backend.

This is the gap between user analytics tools and debugging tools.

TL;DR

Choose Multiplayer if: You need to resolve technical issues fast, with full frontend + backend context in one place, and you need to improve your debugging workflows across multiple teams (e.g. Support → Engineering).

Choose Fullstory if: You primarily need behavioral analytics for product and UX decisions.

Key difference: Fullstory shows you how users behave on your website, aggregating performance metrics. Multiplayer shows how your system behaves, from user actions to backend traces, and how to fix a bug (or have your AI coding assistant do it for you).

Quick comparison

More resources:

• Multiplayer vs Fullstory deep dive
• Multiplayer vs other tools

The real difference: frontend vs full stack

Fullstory (or half the story?)

Fullstory captures what happens in the browser: clicks, page loads, DOM events. For understanding user flows and UX patterns, this is valuable. But when you're debugging a technical issue, you're missing the critical half: what happened in your backend.

When an API call fails, a database query times out, or a microservice throws an error, you're forced to:

• Switch to your observability platform
• Manually correlate timestamps
• Hunt through logs to find the right data
• Piece together context across multiple tools

Multiplayer: the actual full story

Multiplayer captures full stack session recordings by default. Every frontend action is automatically correlated with backend traces, logs, and request/response data, in a single, unified timeline.

When that checkout button fails, you see:

• The user's click
• The API request
• The backend trace showing which service failed
• The exact error message and stack trace
• Request/response content and headers from internal service calls

No hunting. No manual correlation. No tool switching. Everything you need to fix the bug is in one place.

Real scenario: A user reports "payment failed" but your logs show a 200 response. With Multiplayer, you see: the button click, the API call to your payment service, the upstream call to Stripe, the 429 rate limit error from Stripe, and the incorrectly handled error response your service returned as a 200.

Recording control: always-on vs choose-your-adventure

Fullstory: Always-on recording via SDK

Fullstory uses always-on recording through its SDK: you're recording and storing everything, whether you need it or not. This works fine for aggregate analytics, but creates friction for debugging:

• No granular control over when and which sessions to capture
• Can't easily capture specific user cohorts or error scenarios
• Limited to SDK installation (no browser extensions or widgets for end-users)

Multiplayer: record what you need, when you need it

Multiplayer offers three recording modes and three installation methods. It’s a choose-your-own-adventure approach that adapts to your teams’ workflows.

Recording modes:

• On-demand: Start/stop recording manually. Perfect for reproducing specific bugs.
• Continuous: Start/stop recording in the background during your entire working session. Great for development and QA to automatically save sessions with errors and exceptions.
• Conditional: Silent capture of specific user cohorts or error conditions.

Installation methods:

• In-app widget: Let users report issues with replays attached automatically, directly from your app
• Browser extension: Quickly capture a bug, unexpected behavior, or new feature idea
• SDK / CLI Apps: Full integration for programmatic control

Real scenario: Your support team gets a vague bug description. They ask the end-user to record a full stack session replay through the in-app widget. Support is able to fully understand the problem and they can reproduce the issue in 30 seconds. It’s immediately clear what the next steps (or possible fixes) are.

Support workflows: serial handoffs vs parallel collaboration

Fullstory: built for analysts, not debugging teams

Fullstory's collaboration features are designed for PM and UX teams reviewing sessions asynchronously:

• Share session links
• Add highlights and notes
• Build funnels and dashboards

But for technical debugging, this creates serial handoffs:

1. Support searches and watches the replay (frontend only)
2. Support escalates to Engineering with partial context
3. Engineering opens observability tools to find backend data
4. Engineering asks follow-up questions
5. Support provides more details
6. Repeat until enough context is gathered

Multiplayer: complete context from the start

Multiplayer is built for parallel Support ↔ Engineering workflows:

Single, sharable timeline:

• Frontend screens, user actions, backend traces, logs, request/response data, and user feedback, all correlated automatically
• Support sees the user's experience; Engineering sees the technical root cause
• Both work from the same data, at the same time

Annotations and collaboration:

• Sketch directly on recordings
• Annotate any data point in the timeline
• Create interactive sandboxes for API integrations
• Link sessions directly to Zendesk, Intercom, or Jira tickets

What you actually get per session

Fullstory captures:

• User clicks ✓
• Page navigations ✓
• DOM events ✓
• Console messages (browser only) ✓
• Network requests (paid plans only) ✓

Multiplayer captures:

Everything Fullstory captures, plus:

• Correlated backend logs and traces (any observability platform, unsampled) ✓
• Backend errors ✓
• Full request/response content and headers (including from internal service calls) ✓
• User feedback integrated in the timeline ✓
• Service and dependency maps ✓

Integration and deployment: flexibility matters

Fullstory:

• SDK installation only
• SaaS deployment only
• Mobile support is a paid add-on
• No backend visibility or observability integrations
• No support for AI coding workflows

Multiplayer:

• Web and mobile support out of the box
• Multiple installation methods (extension, widget, SDK)
• SaaS or self-hosted deployment
• Works with any observability platform (Datadog, New Relic, Grafana, etc.), language, framework, and architecture
• MCP server for AI-native debugging in your IDE or AI assistant

For teams with compliance requirements: Fullstory's SaaS-only model can be a dealbreaker. Multiplayer's self-hosted option keeps sensitive data in your infrastructure.

For AI-forward teams: Multiplayer's MCP server feeds complete session context (frontend + backend + annotations) directly to Claude, Cursor, or your AI tool of choice. Ask "why did this checkout fail?" and get answers grounded in the actual session data.

Which tool should you choose

Choose Multiplayer if:

• You need to fix bugs and resolve technical issues fast
• Your support team regularly escalates issues to engineering
• You need backend visibility alongside frontend data
• You want flexible recording modes (not just always-on)
• You need to correlate frontend and backend data without manual work
• You have compliance requirements that need self-hosting
• You want AI-native debugging workflows

Choose Fullstory if:

• Your primary goal is user analytics and UX optimization
• PM and design teams are your main users
• You don't need backend data integrated with session replays
• Always-on, frontend-only recording meets your needs

Consider both if:

• You're a large organization where user analytics and technical debugging are handled by separate teams with separate objectives

The bottom line

Fullstory is a powerful behavioral analytics platform. But if you're using it to debug technical issues, you're working with one hand tied behind your back. You're missing backend data, manually correlating across tools, and creating slow handoffs between support and engineering.

Multiplayer gives you the complete picture: frontend and backend, correlated automatically, in a single timeline, with purpose-built collaboration for technical teams. It's session replay designed for the reality of modern distributed systems.

Whiteboarding tools are indispensable in system design for visually conveying concepts, ideas, and rough plans. They tap into our natural preference for visual learning. Most people, after all, agree that "a picture is worth a thousand words."

But static whiteboarding tools lack the crucial element that makes feedback truly actionable: context.

That's why we evolved our Sketches feature into Annotations, a way to draw, write, and comment directly on top of full-stack session recordings. Now, instead of sketching ideas in isolation, teams can mark up actual user sessions, highlighting specific UI elements, API calls, and backend traces that need attention.

Why Annotate Session Recordings?

Multiplayer automatically captures everything happening in your application: frontend screens, user actions, backend traces, metrics, logs, and full request/response content and headers. But when something goes wrong or needs improvement, pointing at the exact moment and explaining what should change requires more than just text.

Annotations let you:

• Draw directly on the replay with shapes, arrows, and highlights to mark problem areas or desired changes
• Add on-screen text to explain intended behavior or specify new UI copy
• Attach timestamp notes to clarify reproduction steps, requirements, or design intentions
• Reference full-stack context by annotating user clicks, API calls, traces, and spans directly

Because Multiplayer auto-correlates frontend and backend data, your annotations aren't just surface-level markup: they're tied to the actual technical events that need investigation or modification.

How Support Teams Use Annotations

1. Clarifying Bug Reports

When a customer reports confusing behavior, support teams can create an annotated recording that shows:

• Red circles highlighting where the UI behaved unexpectedly
• Arrows pointing to the button that should have appeared
• Text annotations explaining what the customer expected to see
• Timestamp notes marking the exact API call that returned the wrong data

This annotated session becomes a complete bug report that engineering can understand immediately. No back-and-forth required.

2. Documenting Reproduction Steps

Instead of writing lengthy reproduction steps like "Click the dashboard, then filters, then date range, then apply," support can:

• Record themselves reproducing the issue once
• Add timestamp notes at key moments: "User opens filters here," "Selects invalid date range," "Error appears at 0:45"
• Highlight the error message in red with a note: "This message is confusing. We should clarify valid date format"

Engineering gets a visual, interactive guide to the problem with full backend context included.

3. Collecting Feature Requests with Visual Context

When customers suggest improvements, support can annotate recordings to show:

• Green highlights around areas customers want enhanced
• Sketched mockups showing proposed layouts
• Text annotations with customer quotes about desired behavior

How Engineering Teams Use Annotations

1. Reviewing PRs with Visual Feedback

During code review, engineers can record themselves testing a new feature and add annotations:

• Yellow boxes around UI elements that need spacing adjustments
• Arrows indicating where loading states should appear
• Text specifying exact pixel values or color codes
• Timestamp notes on API calls: "This endpoint takes 2.3s, should we add caching?"

The developer receives actionable visual feedback tied to actual runtime behavior, not abstract suggestions.

2. Debugging with Annotated Evidence

When investigating production issues, engineers can:

• Record a session where the bug occurs
• Circle the problematic UI element in red
• Add arrows pointing from the frontend error to the failing API trace
• Annotate the trace span with notes: "This database query times out under load"

This creates a self-documenting investigation that other team members can follow.

3. Planning Refactors with Visual Context

Before refactoring complex flows, teams can:

• Record the current user journey
• Use different colored annotations to map out different concerns (blue for performance, purple for UX improvements, orange for tech debt)
• Add timestamp notes explaining why each step exists
• Sketch the proposed new flow directly on top of the recording
• Reference specific API calls and traces that will be affected

4. Onboarding New Engineers

Senior engineers can create annotated recordings that serve as interactive documentation:

• Record a typical user flow
• Add green annotations explaining key architectural decisions
• Highlight important code paths with timestamp notes
• Mark API boundaries and service interactions
• Sketch out related system components and their relationships

New team members can pause, replay, and reference the full-stack context as they learn.