The Multiplayer AI Manifesto: Sergey Karayev's Case for Shared Cloud Agents

Most teams running AI coding agents today pay a tax they've never named. Someone spends twenty minutes getting Claude Code or Codex up to speed on a gnarly part of the codebase, solves the problem, and closes their laptop. Two hours later, a teammate hits the exact same wall and starts from zero — a fresh terminal, a fresh context window, the same explanation typed out again. On September 4, 2026, Superconductor cofounder Sergey Karayev (also cofounder of Gradescope) published a manifesto at multiplayer-ai.com naming that pattern the "context tax" and arguing it's the direct result of a design choice most AI tooling still makes by default: agent sessions live privately, on one person's machine.

TL;DR

The five principles, as stated

Karayev's manifesto is built around five explicit principles. Quoting the source directly:

1. Never copy-and-paste. "Agents must live next to the work, instead of in their own chat or in Slack."
2. Work with the door open. Shared sessions let a team absorb good practices from watching each other work with agents, rather than everyone rediscovering the same tricks in isolation.
3. Continuously improve. "When an agent needs correcting, a reusable skill should be created automatically" — a correction one person makes should upgrade the whole team's agents, not just that one session.
4. People are not routers. "A human must never be asked a question that an agent already has the answer to" — if one teammate's agent already resolved a question, a second agent shouldn't ask a human to answer it again.
5. Nothing starts from scratch. A new hire, or anyone picking up someone else's task, should be able to resume a prior agent session with its full context intact rather than starting a fresh, empty one.

The manifesto backs these with specifics from a year of internal use at Superconductor: agents run in cloud sandboxes rather than on laptops, each agent sits behind a firewall limiting it to approved services, permissions on a shared session are scoped to respect existing data-access levels rather than flattening everyone to the same view, and the team stays provider-agnostic — running Claude, Codex, and other agents side by side rather than betting the whole workflow on one vendor. One line from the manifesto is worth keeping as a test for any tool claiming to do this well: "governance means being able to answer four questions about any session a year later." That's a genuinely high bar — most teams today couldn't reconstruct who saw what in a single AI chat from a week ago, let alone a year.

The "context tax," concretely

Strip away the manifesto framing and the context tax is a problem any team running Claude Code, Codex, or another coding-agent harness across multiple people will recognize immediately. Each private session pays it in a few recognizable ways:

• Re-explaining the same codebase. Five engineers running five separate local agent sessions on the same repo each spend the first several minutes of every session re-establishing context an earlier session already built and then discarded when the terminal closed.
• Re-solving already-solved problems. If a teammate's agent already worked out why a flaky test fails intermittently, and that session isn't visible to anyone else, the next person whose agent hits the same test starts the investigation over.
• Losing corrections. When you correct an agent's mistaken assumption about your deploy process, that correction lives in your one session. It doesn't propagate to a colleague's separately-started agent unless someone manually writes it down and both people remember to check.
• Handoffs that reset to zero. A new team member, or someone picking up a task mid-flight, gets a blank agent and a Slack thread to read — not a session they can literally continue.

None of this requires believing in the specific Superconductor product to find compelling. It's the same underlying observation that's shown up in several places this year: agent state — the context an agent has built up, the corrections it's absorbed, the skills it's learned — has value that's currently trapped on whichever machine started the session, and every team using multiple private agent sessions is quietly duplicating work as a result.

Not the first shot at this — how it differs from Chopin, Buzz, and Claude in Slack

This is the third or fourth distinct attempt at "shared agent context" explainx.ai has covered in the last three months, and it's worth being precise about what's actually new here versus what's a different angle on the same idea.

GitHub Next's Chopin, open-sourced two days earlier on September 2, 2026, targets one specific moment: getting a team aligned on a plan together, visually and in real time, before an agent starts executing. It's explicitly an early prototype scoped to the planning phase. Karayev's manifesto is broader and covers the entire session — not just planning, but execution, correction, and handoff, for the full lifetime of an agent's work. Read them as complementary rather than competing: Chopin is trying to fix collaborative planning; the manifesto is trying to fix everything downstream of planning too.

Block's Buzz, which Jack Dorsey launched in July 2026, gets closer to the same territory — agents as first-class members of a shared workspace with chat, a Git forge, and identity all in one event log. Buzz's answer to "who can see what" is a per-agent Nostr key pair with scoped authorization; the manifesto's answer leans toward full visibility by default ("any session is joinable by anyone on the team"), which is a meaningfully more permissive starting position. Buzz's own documentation is explicit that it hasn't solved the harder problem of an agent blending context across channels it has access to but a given human doesn't — the same tension the manifesto's "work with the door open" principle runs straight into.

Claude in Slack (Claude Tag) is the version of this idea already shipping at scale today: one Claude instance per channel, shared by everyone in it, building context from channel history so a teammate can pick up where someone else left off. It satisfies pieces of principles 1, 2, and 5 out of the box, inside Slack's existing permission model — but it's scoped to channels, not to arbitrary cloud coding-agent sessions, and it doesn't attempt principle 3 (skills propagating automatically team-wide) or the full "joinable by anyone" claim.

Put side by side, four different teams converged on a similar diagnosis from different directions in the space of about ten weeks:

That convergence is the actual story here, more than any single announcement. When four independent teams — a startup founder, GitHub's research arm, a public company's CEO, and Anthropic's own product org — all ship variations on "agent context shouldn't be trapped on one laptop" within the same quarter, that's a real signal about where the industry thinks agent tooling is underbuilt, not a coincidence worth ignoring.

Reactions: enthusiasm meets a real security question

The manifesto got a quick, notable reaction from Austen Allred, CEO of GauntletAI: "Very interesting. I could definitely see this becoming the norm. Why should any agents doing work be local? Why shouldn't anyone in the company be able to see and access all of the agents as they run?" The discussion that followed pointed to Shopify's internal "River" system and a tool called "HeyNemoAI" as examples of organizations already experimenting with something in this direction internally, ahead of any public manifesto naming the pattern.

Allred's framing is worth taking seriously — "why should any agent doing work be local" is a genuinely good question for a purely technical workflow with no sensitive data involved. But it undersells the actual cost of the answer he's implying. Full visibility isn't free; it's a specific security posture that most organizations haven't built the scaffolding for yet.

The honest skepticism: what "joinable by anyone" actually costs

Before treating "any session is joinable by anyone on the team" as an unambiguous good, it's worth sitting with what that default actually implies for a real engineering org:

• Credential exposure. An agent session that has legitimate access to a production database credential, a deploy key, or a customer-data API is now visible — mid-task — to every teammate who joins it, not just the person who provisioned that access in the first place. That's a materially larger blast radius than today's default, where a leaked local session is at least bounded by who's sitting at that laptop.
• Blast radius of a bad agent action. If an agent makes a destructive mistake — a bad migration, a force-push, a leaked secret pasted into a prompt — "joinable by anyone" means anyone on the team can watch it happen in real time, and potentially anyone who joins later can see it in the session history. Whether that's a feature (fast collective response) or a liability (wider exposure surface) depends entirely on whether the org has already built the guardrails Karayev's own manifesto calls for — firewalled tool access, scoped permissions, cloud sandboxing — versus treating "joinable" as the whole plan.
• This assumes trust and access-control maturity most teams don't have. The manifesto's own governance bar — being able to answer who could see a given session a year later — is a compliance and audit-logging capability that takes real engineering investment to build correctly. A team that adopts "everyone can join everyone's agent" without first building that audit trail hasn't implemented the manifesto; it's implemented the risky half of it while skipping the accountability half.
• Not every session should be equally visible. Buzz's own documentation flags the unresolved case directly: an agent that's a member of both a private leadership channel and a broader team channel can leak context between them. The same risk applies to a fully joinable coding-agent session that touches both a confidential roadmap discussion and ordinary feature work.

None of this means the direction is wrong — it means "joinable by default" is the aspirational end state, and the manifesto's own emphasis on sandboxing, firewalls, and per-session accountability is implicitly acknowledging that getting there safely is the actual hard engineering problem, not a footnote to it.

Does working with AI actually work better as a team? What the research says

Part of the implicit case for multiplayer AI is that humans and AI genuinely do better work together than either does alone. That claim is often cited more confidently than the underlying research actually supports, so it's worth being precise. The most directly relevant study is Harvard Business School's "The Cybernetic Teammate" field experiment (Dell'Acqua, Ayoubi, Lifshitz-Assaf, Sadun, Mollick, Mollick, Lakhani, and coauthors), a pre-registered study of 776 professionals at Procter & Gamble working on real product-innovation challenges. Its headline finding: individuals working with AI matched the performance of two-person human teams working without AI — AI substituted for some of the collaborative benefit that used to require a second person.

That's a real, citable result, but it's narrower than "AI-human teams always beat AI alone or humans alone." A broader meta-analysis of human-AI collaboration studies found the opposite pattern shows up too: for decision tasks like classifying content, forecasting demand, or some medical diagnosis, AI operating alone often outperformed human-AI combinations — humans anchoring on a wrong initial judgment can drag a good AI signal down rather than improve it. The honest summary is that combinations of humans and AI help most on complex, creative, generative work, and help least (or actively hurt) on narrower classification and decision tasks where the AI's judgment alone is already strong. If a "Harvard study" is cited in a multiplayer-AI discussion without more specificity than that, treat it as likely referring to the P&G field experiment above — but verify the specific claim being made against it rather than accepting the citation at face value, since the result is genuinely task-dependent, not a blanket "teams win" finding.

What you can actually try this week

There's no Superconductor signup link to hand you today — the manifesto itself concedes no existing platform, including its own, fully satisfies all five principles yet. That makes this squarely an opinion and direction piece, not a product review. What a reader can do today is replicate the underlying pattern, not sign up for the specific tool:

• Move agent sessions to the cloud where your harness supports it. Claude Code's cloud and background session features let a task keep running and stay resumable after you close your laptop — a partial answer to principle 1 ("agents must live next to the work") without waiting for a dedicated multiplayer product.
• Give a team a shared surface instead of five private ones. Claude in Slack already gives one channel a single shared Claude session that any member can pick up mid-conversation — a working instance of "nothing starts from scratch" and "work with the door open" for teams that already live in Slack.
• Watch Chopin and Buzz as open-source reference points, not because either is production-ready, but because both make their design tradeoffs public. Chopin's repo shows one team's attempt at multiplayer planning specifically; Buzz's architecture docs show a concrete (if unfinished) answer to per-agent identity and scoped authorization that anyone building toward "joinable sessions" will eventually need to solve too.
• Before adopting anything in this category, write down your own answer to the manifesto's governance question — who could see a given session, and for how long is that answer auditable — before you loosen visibility, not after.

Closing

The multiplayer AI manifesto isn't proposing a wild new idea so much as naming, clearly and in five principles, something several teams have independently been building toward this year: agent context is currently trapped on individual laptops, and that's an expensive, invisible tax on any team using AI agents at more than one-person scale. Karayev's framing is useful even to a reader who never touches Superconductor, because it gives a name — the context tax — to a cost most teams are already paying without measuring. Whether "joinable by anyone" is the right visibility default, versus a scoped, audited version of the same idea, is the real unresolved argument — and it's the same argument Chopin, Buzz, and Claude in Slack are each answering slightly differently right now.

Related reading

• GitHub Next's Chopin: Multiplayer Agent Planning Prototype
• Jack Dorsey's Buzz: Team Chat, AI Agents, and Git Hosting
• Claude Tag: How to Use Anthropic's Team AI in Slack
• Graph Engineering: Wiring Multi-Agent Organizations
• Y Combinator Open-Sources QM: Company-Wide Multi-Agent Harness
• What Is an Agent Harness? Complete Guide
• Claude Code Commands: Complete Reference Guide

Official links: multiplayer-ai.com · Superconductor · The Cybernetic Teammate — Harvard Business School

This post reflects the state of the multiplayer-ai.com manifesto and public reactions as of September 5, 2026. Superconductor's product availability, the manifesto's specifics, and cited research findings should be independently verified before being relied on for a decision — this is analysis and opinion, not a product review of a generally available tool.