Maggie Appleton's recent post, "One Developer, Two Dozen Agents, Zero Alignment", makes a strong case for collaborative AI engineering. Her example, Ace from GitHub Next, shows why single-player AI tools break down on teams. Software development depends on shared context, planning, and coordination. Most coding agents still hide that work inside one person's session.
I think that argument applies more broadly.
This is not only a problem for coding tools. It is becoming a problem for most AI apps.
AI already makes solo work feel collaborative
AI changes how one person works. You can ask for options, assign subtasks to multiple agents, compare outputs, and iterate in tight loops. Writing, research, analysis, coding, and planning start to feel less like using a tool and more like coordinating a team.
But most AI apps still package that experience as a private session.
You get one user, one thread, and one hidden context window. If you want to involve someone else, you usually share the result after the fact. That means the actual work stays trapped inside a private conversation.
The model supports collaboration. The product does not.
Shared workspaces are step one
Ace is interesting because it moves beyond private copilots. It treats agents, humans, plans, and implementation as part of one shared environment. That is much closer to how teams actually work.
If AI is going to participate in real workflows, its outputs cannot live only as text inside private sessions. They need to become first-class data in the application itself:
- messages
- tasks
- plans
- drafts
- decisions
- annotations
- approvals
- run history
- provenance
Once AI output becomes shared state, collaboration stops being something you do after the model responds. It becomes part of the product's core execution model.
Good AI apps already need the right infrastructure
This is also why multiplayer AI is less of a leap than it first appears.
If you are building a good AI app, you already need server-side infrastructure to make the single-player experience reliable. Long-running model calls need durable state. Streamed responses need to survive reconnects. Agent runs need to resume after disconnects, page refreshes, or mobile network drops. Background work needs a system of record outside the browser.
In practice, that usually means adding stateful infrastructure anyway. Maybe that is Redis. Maybe it is a database-backed job system. Maybe it is a sync engine.
Once you have that layer, you already have many of the pieces needed for multiplayer:
- durable run state
- resumable streams
- shared message history
- server-side coordination
- live updates across clients
- a consistent view of work in progress
At that point, making the app multiplayer is no longer about inventing a completely new architecture. It is about deciding that this state should be shared across participants instead of scoped to one user session.
That is why I think many AI apps will move in this direction. Reliability pushes you toward shared infrastructure first. Multiplayer becomes the natural next step.
This is bigger than coding
Coding is the clearest example, which is why Ace is useful. But the same pattern shows up in every category.
- Research tools help one analyst, but the team still reviews findings elsewhere.
- Writing tools help one author draft, but review and approval still happen in docs and chat.
- Support and operations tools help one person act faster, but handoffs still happen outside the system.
AI makes solo work feel multiplayer. Human collaboration still happens around the product instead of inside it. That separation creates friction.
What collaborative AI apps actually need
Good prompt UX is not enough. If humans and agents are going to work in the same system, the app needs live, durable, shared state that every participant can inspect and update safely.
That means handling:
- presence
- shared memory
- provenance
- permissions
- handoffs
- conflict resolution
- sync across users, agents, and devices
These are product requirements, but they are also infrastructure requirements. A collaborative AI app is not just a model wrapped in chat UI. It is a system where humans and agents coordinate around shared state.
Small example: PowerChat
I have been experimenting with this in a demo app called PowerChat.
In PowerChat, you do not message an agent in a private sidebar. You @mention an agent in a shared channel. That message is written locally first, synced immediately, and then turned into agent runs on the server. Placeholder responses appear quickly, streamed output lands back in the shared thread, and everyone in the channel sees the same state update live.
That is a small UI change, but a bigger architectural change.
The agent output is not a response returned to one user. It is a state change synced to the workspace.
That is the direction I think more AI apps need to move toward.
Shared-state AI is where this goes
Maggie's post is right to focus on alignment. Faster agents make poor coordination more expensive.
The next step is to apply the same thinking to AI apps more broadly.
If we want AI apps that are truly multiplayer, we need to build them like collaborative software from the start. Not as single-user chat products with sharing added later, but as shared systems where humans and agents work on the same underlying state.
The future of AI apps is where collaboration with AI and collaboration with other people happen in the same loop.