Your Agents Can't Share a Room. That's the Bug.

Look at GitHub's trending page today. mattpocock/skills sits at 312,000 stars — a curated folder of markdown files worth more than most SaaS products. claude-mem crosses 112,000 stars with persistent context across sessions. worktrunk has hit 10,900 stars managing git worktrees so multiple agents can code in parallel without stepping on each other. The agent-infrastructure wave has consolidated two hard problems: memory and parallelism. But there is a third primitive that none of these repos solve, and a dozen startups are now racing to build it.

📖 Read the full version with charts and embedded sources on AgentConn →

The shared session — multiple humans AND agents editing the same live context at the same time — is the genuinely unsolved problem in agent tooling. Not "run five Claude Code instances on separate branches" (worktrunk handles that). Not "remember what happened last session" (claude-mem handles that). The hard thing is: two developers and three agents, same codebase, same terminal, same conversation, right now. And Y Combinator's Fall 2026 Request for Startups says it plainly: "Agents are still mostly single-player even though serious work is collaborative."

View original post on X →

Parallel Is Not Multiplayer

To understand why the shared session is hard, you have to understand what the current parallel-fleet model actually buys you — and where it stops.

Worktrunk, the Rust CLI trending at +524 stars per day, is the poster child of the parallel approach. You run wt switch -x claude -c feature-auth, and it creates an isolated git worktree with its own branch, its own directory, and its own Claude Code instance. Five agents, five worktrees, five branches, zero conflicts. It is elegant and it works.

But it works by avoiding the hard problem. Each agent is isolated. No agent knows what any other agent is doing. There is no shared context, no real-time awareness, and no way for Agent A to say "I just refactored the auth module — don't touch it" to Agent B. When the branches merge, conflicts appear for the first time. Practitioners in Reddit discussions report the practical ceiling: "2-3 active sessions is the practical ceiling unless the tasks are very separated."

View on Hacker News →

Maggie Appleton, Staff Research Engineer at GitHub Next, put it best in her AI Engineer London talk: the "one man, two dozen Claudes" model does not produce team alignment. Scaling one person's output through isolated parallel agents does not coordinate a team. Her research prototype Ace puts teammates and coding agents into one shared workspace for planning, conversation, and code — because the alternative is a dozen agents with local plans that nobody else can see.

This is the gap. Parallel tools (worktrunk, Agent Teams) solve throughput. But real software engineering is collaborative: pair programming, live code reviews, cross-role handoffs between PMs and developers, debugging sessions where three people and an agent stare at the same stack trace. The current model forces you to choose between collaboration (single session, one agent, takes turns) and parallelism (many agents, zero coordination). The shared-session primitive is supposed to give you both.

The Tools Racing to Fill the Gap

A half-dozen tools launched in 2026 that each attack a different slice of the shared-session problem. None of them solve the whole thing.

Delta (Zed) — Session Sharing Across Machines

Delta, released by Zed Industries in August 2026, is arguably the most polished entry. The host runs /delta share inside Claude Code, gets an invite link, and the guest runs /delta join. Delta synchronizes the conversation transcript and the working copy across both machines. Both developers see what Claude tried, what failed, and what is uncommitted — without waiting for a commit.

View the full article on Zed Blog →

Zed's announcement describes Delta as "a multiplayer environment for coding with agents and reviewing what they build." It is still in private beta. Claude Code is the first third-party harness supported, with Pi planned next. The plugin is open source.

What it solves: Asynchronous context sharing between two humans working with the same agent. A developer picks up where their teammate left off without re-reading a branch history.

What it does not: Agent-to-agent coordination. Delta shares a human-readable transcript, not a machine-readable state. Two agents cannot negotiate file ownership through Delta.

Conductor (Melty Labs) — Multiplayer Cloud Workspaces

Conductor, from Melty Labs (YC-backed, $22M Series A), launched Conductor Cloud on July 30, 2026. It started as a Mac app for running parallel Claude Code sessions and evolved into multiplayer cloud workspaces. Teammates invite each other into the same workspace, prompt agents together, and watch progress from the desktop client.

View the full changelog on Conductor →

Each cloud workspace runs in an isolated microVM (built on Vercel Sandboxes) with the repo and dependencies preinstalled. Agents keep running when you close the app. The model-agnostic design supports Claude Code, Codex, Cursor, and OpenCode.

What it solves: Persistent, cloud-native multiplayer. A teammate joins your workspace and both can prompt agents. The workspace outlives your laptop lid.

What it does not: Real-time co-editing. Conductor's multiplayer is more "shared workspace" than "shared cursor." Two people can prompt different agents in the same workspace, but they are not editing the same file in real time with conflict resolution.

vibelive — Figma-Style Cursors in the Terminal

vibelive takes a different approach entirely. It wraps any agentic coding terminal — Claude Code, Codex, Gemini — and adds live Figma-style cursors, presence indicators, and in-terminal chat. You run vibelive host -- claude, get a join URL, and collaborators see your terminal in real time.

What it solves: Real-time presence and awareness. You know who is watching, who is typing, and where their attention is. It is the closest thing to "Google Docs for terminals."

What it does not: Conflict resolution or agent awareness. vibelive shares the terminal stream, but the agents inside it have no idea other participants exist. It is a collaboration layer around the agent, not inside it.

Mosaic (YC S26) — Shared Memory, Not Shared Sessions

Mosaic, a YC Summer 2026 company, started as a real-time coding environment and pivoted toward shared memory. Its current product (Ocean) syncs every AI session your team runs — Claude Code, Codex, Cursor — into one shared knowledge base that any agent can query. The thesis: if every agent knows what every other agent decided and why, you do not need them in the same room.

View the full review on Wavect →

A third-party review of Mosaic warns: "Do not assume concurrent edits are conflict-free. Collaboration and conflict-handling questions are treated as open." The review notes that Mosaic reports approximately 2,000 installs and 37 organizations actively syncing, though these are company-disclosed figures.

What it solves: Asynchronous context continuity. Agent B knows what Agent A decided yesterday without being in the same session.

What it does not: Real-time collaboration. Mosaic's value is in memory, not presence.

Agor (Preset) — The Spatial Canvas

Agor, from the team behind Apache Superset, is the most ambitious entry. It provides a visual canvas where Claude Code, Codex, and Gemini sessions run side-by-side on isolated git worktrees — but with live cursors, a facepile, scoped comments, and a shared multiplayer terminal. Drop a worktree into a spatial zone and it fires a templated prompt. An MCP server lets agents introspect and spawn other agents. Slack and GitHub threads act as portals into agent sessions.

What it solves: The orchestration UX. Agor gives you a visual overview of what every agent is doing, plus collaboration tools to coordinate between them.

What it does not: The isolation is still per-worktree. The agents themselves are not sharing a live session — they are running independently in adjacent boxes, with a human-facing collaboration layer on top.

Why Shared Sessions Are Harder Than Parallel Fleet

The reason every tool solves a different slice is that the full problem is genuinely difficult. Parallel fleet (worktrunk-style) succeeds by making a simplifying assumption: agents do not need to coordinate in real time. Shared sessions throw that assumption out, and three hard sub-problems fall in.

1. Conflict Resolution Is Not Git Merge

When two agents edit the same file in a worktree model, you get a git merge conflict at PR time. Painful, but tractable — a human resolves it. In a shared session, the conflict happens in real time. Agent A writes line 42 while Agent B deletes lines 40-45. Who wins? Git's three-way merge does not help here because there is no "commit" boundary — edits are streaming. This is the same problem that Google Docs solved for text with Operational Transformation (OT) and CRDTs, but no one has applied it to agent code edits at the semantic level. Character-level OT does not understand that a renamed function changes every call site.

2. Context Pollution

In a shared session, every participant's actions become part of every other participant's context window. If Agent A is debugging a CSS layout while Agent B is writing database migrations, Agent B's context now includes CSS debugging noise. This is the "open office problem" for agents — proximity breeds distraction. Source control for multi-agent repos is hard enough when agents work sequentially; real-time shared context makes it exponentially worse.

3. Permission Scoping

Who can approve what? If Agent A and Human B are in the same session, and Agent A wants to delete a file, does it need Human B's approval? What about Human C who just joined? The approval model in current agent harnesses assumes one human, one agent, one permission scope. Shared sessions blow that up.

View the Multiplayer AI Manifesto →

The Multiplayer AI Manifesto by Sergey Karayev explicitly lists "permissions, privacy, accountability, and governance" as open problems, and notes that no platform meets the entire manifesto today.

The Contrarian Take: Shared sessions might be an anti-pattern. The reason agents work well on isolated worktrees is precisely because they cannot step on each other. Introducing real-time collaboration multiplies the failure surface — merge conflicts, context pollution, permission escalation. The 2-3 concurrent agent ceiling that practitioners report may be fundamental, not a tooling gap. "Multiplayer" might be a VC pitch that sounds great and ships badly. Before adopting any shared-session tool, ask: is my bottleneck actually coordination, or is it throughput?

The Landscape Map

Here is how the current tools map against the three hard problems:

The pattern is clear: every tool has presence OR isolation, never both with conflict resolution. The cell that says "Yes" for all four columns is empty. That is the product that does not exist yet.

View original post on X →

What Practitioners Should Do Now

If you are building with multi-agent setups today, the honest advice is: do not chase the shared-session dream yet. Here is what the maturity ladder looks like:

Step 1 — File Collisions: If your agents trip over each other's files, you need isolation, not collaboration. Use worktrunk or Claude Code's built-in worktree support. The problem is separation, not togetherness.

Step 2 — Lost Context: If Agent B does not know what Agent A decided yesterday, you need shared memory, not a shared session. Mosaic, claude-mem, or even a well-structured MEMORY.md file solve this without real-time overhead.

Step 3 — Pair Programming: If you pair-program with an agent and want a colleague to jump in, Delta is the most mature option for session sharing between humans. It works, it is in beta, and it does not try to be more than it is.

Step 4 — Agents Prompting Agents: If you need agents prompting agents in a shared workspace, Conductor's cloud workspaces are the closest to this, but expect to manage coordination yourself. The agents do not coordinate automatically.

Step 5 — The Full Vision: If you want multiple humans and agents, real-time, conflict-aware — it does not exist yet. Build accordingly. The agent swarms still cannot coordinate, and adding humans to the mix makes coordination harder, not easier.

The Demand Signal Is Real: YC's Fall 2026 RFS explicitly asks for "a workspace where a whole team works with agents in real time." The Multiplayer AI Manifesto defines five principles for what this should look like and admits no platform meets them. GitHub Next is researching it (Ace). The gap is recognized. But recognized gaps and shipped products are different things.

The Prediction

Within 12 months, one of these tools will ship real-time conflict resolution for agent code edits — probably using a CRDT-based approach adapted from collaborative editors like Yjs. The winner will not be the tool that ships the most features but the one that solves the conflict-resolution problem at the semantic level (understanding that a function rename affects all call sites) rather than the character level.

When that happens, the agent-of-agents pattern will shift from orchestrating isolated fleet members to coordinating collaborators who share a live codebase. The abstraction layer will move from "launch N agents on N branches" to "invite N agents into one session with scoped permissions."

Until then, the honest answer is: your agents cannot share a room. And for most workflows, that is fine. The tools you need — isolation, memory, parallelism — already exist and already work. The shared session is the next primitive, not the current one. Build for what ships today, and watch this space for what ships tomorrow.

The multiplayer agent tooling landscape is moving fast. For the parallel-fleet approach, see our coverage of source control for multi-agent repos. For why memory matters more than models, see Memory Is the New Moat.

Originally published at AgentConn