Multiplayer AI: Competing Architectures for Human-Agent Collaboration

Multiplayer AI is starting to show up everywhere. Anthropic is bringing Claude into shared Slack channels with Claude Tag. Dust is building shared spaces for humans and agents. Asana is putting agents into its Work Graph. Superconductor and AQ are making agent sessions and harnesses collaborative, while Cognee is building shared memory across agents.

There are now enough different approaches in the wild that it’s possible to ask a more useful question: when we make AI multiplayer, what exactly needs to be shared?

The answers are surprisingly different. Depending on the product, the multiplayer layer might be the conversation, the agent session, the harness, the work graph, the workspace, memory, or the work itself. Coding systems sometimes go in the opposite direction, giving every agent an isolated environment and only bringing their work together afterward.

These are more than different product interfaces. They represent different architectural approaches for how humans and agents should work together, which state belongs to execution and which belongs to the collaboration, where shared state should live, and what needs to persist as workers come and go.

There is no agreement yet on the right human-agent architecture, and unsurprisingly each company’s answer often starts from the part of the stack it already owns.

Looking across the products being built today, seven architectural patterns for multiplayer AI stand out. These patterns are not mutually exclusive. A single product can combine several of them.

Share the conversation

The most straightforward approach is to put the agent somewhere everyone can talk to it. Claude Tag does this inside Slack. Instead of every employee having a private Claude conversation, Claude can participate in a shared channel. It sees the surrounding channel context, multiple people can interact with it, and its work is visible to the team.

Microsoft is taking a similar approach with agents in Teams. Its Channel Agent belongs to a particular channel and can participate in the conversations, meetings, and work happening around it. In both cases, the existing communication system becomes the multiplayer layer.

Architecturally, the conversation itself is the shared state. The underlying agent execution can remain mostly unchanged, while the context stream surrounding it is what's shared and persisted. For a lot of collaborative work, this architecture is enough.

Share the agent session

Superconductor goes a layer deeper by sharing the actual agent session. Multiple people can participate in the same running agent environment, see what is happening, steer the work, review it, and continue from the same state.

AQ brings a similar idea into the coding harness. A task gets an isolated worktree, while the terminal, editor, preview, and agent environment around it can be shared with the team. HumanLayer is exploring related territory around coding-agent sessions, plans, diffs, and tasks.

In these architectures, the collaboration is centered around the agent and its execution environment, making the session or harness itself the multiplayer layer. In other words, the shared state moves down the stack to the live execution state itself.

There is a meaningful difference between this and sharing a conversation. The team isn’t just communicating with the same agent. It is sharing more of the environment in which the agent is actually doing the work.

Share the work graph

Asana and Linear start from a different place because they already have multiplayer systems. Their shared objects are already projects, tasks, issues, owners, dependencies, comments, status, and approvals. They can make agents participants in that existing model instead of inventing a new collaboration layer.

Asana is particularly explicit about this. Its AI Teammates operate against the same Work Graph as people. Agents work against shared organizational context and participate in workflows with visibility, governance, and checkpoints.

Linear has been moving agents into its issue model. A human can remain accountable for an issue while delegating work to an agent. Patchwork pushes the idea further toward agents as visible coworkers that can own tasks, have conversations, work on schedules, and pull humans in when needed.

In these architectures, the existing domain model remains the system of record. Agents are just new actors operating on these same durable objects and relationships as humans.

One key property of this approach: the agent doesn’t need to be durable. It can show up, read the task and context, do the work, and disappear. The project, task, and dependencies are still there when a different agent or human connects.

Create a shared workspace

Dust is tackling the problem by creating a new container for the team. Its Pods combine people, agents, conversations, files, tasks, and context around a shared goal. Agents can work against the state of the Pod, create conversations and tasks, work with files, and hand work between participants.

QM is another interesting version of this approach. It gives people and shared rooms durable environments containing memory, files, credentials, permissions, scheduled work, apps, and sandboxes, while allowing different agent harnesses to operate against them.

Here the architecture is more about creating a new shared-state container around the collaboration itself. A shared workspace can bring several necessary parts of multiplayer work together in one place and make it all available to agents.

There is a good argument for building a workspace architecture because human-agent teams have requirements our existing collaboration products weren’t designed for.

Share the memory

Cognee has a different answer. One developer can work with Claude Code while another uses Codex. Their agents remain separate, but useful context from docs, chats, tickets, code, and agent runs becomes a shared company brain, allowing one person’s agent to benefit from something another person’s agent learned earlier.

Several agent-memory companies are approaching adjacent versions of this problem, including Mem0, Zep, and Letta. They differ in how they represent and retrieve memory, but the common architectural approach is separating memory from the individual worker so that agents can remain independent without starting from scratch every time.

Shared memory gives otherwise independent agents a common layer of accumulated knowledge. The agents can use different models, harnesses, and interfaces while still benefiting from what the rest of the team has already learned.

The system of record here is not the execution or even necessarily the work. It is the accumulated context about the work, persisted independently of the workers that produced it.

Keep execution isolated

Coding agents also demonstrate an almost opposite approach to multiplayer: don’t share the execution state at all.

Codex, Cursor, Warp, and other coding systems increasingly let many agents operate in parallel, but they generally don’t let every agent mutate one shared environment. Workers get separate worktrees, branches, sandboxes, or cloud machines, and their contributions are reconciled later.

There is a reason software development evolved this way. Shared mutable state is hard, and two intelligent workers editing the same thing at the same time can create more coordination problems than they solve. Git gives each worker private working state and provides a well-defined way to bring the contributions back together.

That idea may extend well beyond coding. Each agent can get the context required for its job, work independently, leave behind well-defined outputs, and rely on a shared system to coordinate those outputs. Multiplayer in this architecture comes from coordinating independent workers rather than putting them all into the same execution environment.

Separate the work from the execution

Honeycomb Canvas takes another approach. During an investigation, humans and agents operate on the same canvas, producing findings, queries, visualizations, hypotheses, and other intermediate work that everyone else can see and use.

What’s interesting here is the possibility of treating the artifacts, relationships, and state transitions that constitute the work as durable state in their own right, independent of the execution producing them.

I think there is a bigger architectural opportunity here, and one we are exploring at ThruWire: separate the work itself from the execution doing it. The agent session, harness, model, and runtime can form an execution plane, while a separate work plane holds the durable objects, relationships, state, history, and checkpoints that define the work.

Once the work lives separately from the execution, humans and agents can come and go without taking the work with them. They don’t need to share a brain, a harness, or even the same model. The work itself provides the durable state through which they collaborate.

So where should multiplayer live?

There is a reason no one agrees on the architecture. Each company’s definition of multiplayer tends to follow the layer of the stack it already owns.

These patterns solve different parts of the problem, and a real human-agent team will probably combine several of them at once. A project might have ten humans and fifty agents moving through it over several months. They won’t all share one conversation, run in one harness, use the same model, or even be around at the same time.

The architectural question is therefore not simply what humans and agents should share. It is which state must be durable, where that state should live, and which parts of the system should be allowed to remain ephemeral and isolated.

Whatever architecture we end up with has to survive all of them. At minimum, the shared state needs to survive any one human or agent doing the work.