The most important architectural decision in multi-agent systems is not which model to use or how to prompt it. It is whether the system was designed for concurrency from the start — or whether concurrency was added later. The game industry learned this decades ago; the AI agent ecosystem is only now encountering the same wall. This page traces the structural problem, the prior art from massively multiplayer games, and the interdisciplinary gap that remains unfilled.
The single-player problem
Today's AI agent tools — coding assistants, multi-agent frameworks, evaluation harnesses — were designed for a single agent solving a single task. Multi-agent capability, when it exists, is bolted on: agents take turns in a conversation loop, or run in parallel with shared memory that has no concurrency guarantees. This is the software-engineering equivalent of taking a single-player game and adding netcode: it works for 2–4 players in a controlled environment, and it under real concurrent load.
Consider the landscape. AutoGen routes messages between agents in a conversation graph — fundamentally sequential, with no formal mechanism for concurrent artifact modification. CrewAI assigns roles and runs tasks in sequence or parallel, but agents share state through unstructured memory with no conflict resolution. LangGraph adds stateful persistence, but each node in the graph is still a single-agent operation. SWE-bench evaluates one agent resolving one GitHub issue. Claude Code, Cursor, Copilot — all single-developer tools. Even “multi-agent” frameworks typically serialize agent interactions through message passing, which is fine for demos and breaks when 50 agents need to edit the same codebase simultaneously.
The missing abstractions are exactly the coordination primitives — CRDTs, Claims, Signals, Forum, Collective Brain — described on the architecture page. These are not optimizations on top of a single-agent architecture; they are the foundation of a system designed for concurrency from the start. You cannot bolt them on afterward any more than you can bolt multiplayer onto a game engine that assumes a single authoritative client.
What MMOs already know
The game industry solved the “design for massively multiplayer from the ground up” problem decades ago. Ultima Online (1997), EverQuest (1999), and World of Warcraft (2004) did not start as single-player games with networking added later — they were built around server architectures designed for thousands of concurrent participants from day one. EVE Online's single-shard architecture runs 30,000+ concurrent players in one universe through aggressive spatial partitioning and time dilation. Improbable's SpatialOS generalized spatial simulation into a distributed engine for arbitrary large-scale multiplayer worlds. Bernier's work at Valve on latency compensation formalized client prediction and server reconciliation as engineering disciplines. The patterns they developed are directly relevant to multi-agent coordination at scale, and most have no analogue in current AI agent frameworks:
- Sharding and instancing. No single server runs the whole world. The world is partitioned into zones with independent authority, and overflow is handled by spawning instances. The VAC analogue: pod-based hierarchy, where each pod has local authority over its domain and only aggregated summaries cross boundaries. No single orchestrator sees every agent's every action.
- Interest management. Players only receive updates about entities near them — not every event on the server. This is subsidiarityA design principle: decisions should be made at the most local level that can handle them. Only escalate when local resolution is insufficient. Reduces coordination load. and lazy coordination by another name: agents receive signals relevant to their current task, not a of every coordination event in the system.
- Optimistic local updates with guaranteed reconciliation. MMO clients predict locally and reconcile with a centralized authoritative server. CRDTsConflict-free Replicated Data Type — a data structure that multiple writers can update independently and still merge into a consistent result, with no central server required. solve the same problem — optimistic local writes with guaranteed convergence — but without a central server: authority is distributed, and the mathematical merge function ensures all replicas converge regardless of message ordering. The underlying principle is the same (act now, reconcile later); the mechanism differs (centralized authority vs. distributed merge). For multi-agent systems, CRDTs are the stronger primitive because they eliminate the single-server bottleneck that MMOs spend enormous effort working around.
- Raid design and role specialization. End-game content requires coordinated teams with distinct roles (tank, healer, DPS) executing a plan with hard failure modes. This maps directly to phase-based executionA structured agent work cycle: understand → plan → execute → verify → complete. Gate-chain validation between phases catches errors before they propagate to the next stage. with heterogeneous agent tiers: orchestrators (strategy), workers (execution), validators (checks). The failure modes are the same too — if the healer dies, the raid ; if the validator agent crashes, gating fails.
- Guild systems and governance. MMOs develop persistent organizational structures with ranks, permissions, shared banks, and governance disputes — exactly the institutional dynamics that persistent worlds are designed to study. Guild drama is emergent governance. DKP systems are coordination primitives for resource allocation. Guild banks are shared artifact stores with access control.
- Economy design. MMOs must prevent inflation, duplication exploits, and market manipulation across thousands of concurrent participants. Auction houses are cross-team coordination mechanisms. Gold sinks are anti-accumulation primitives. The Zhuge et al. Economies of MindAn NLSOM where agents pay each other for services in a shared currency, with natural-language contracts, bankruptcy for underperformers, and the ability to spawn child agents. Proposed by Zhuge et al. (2023) as a credit-assignment mechanism for multi-agent systems. warning about uncontrolled agent economies is a problem MMO designers have fought for 25 years.
- Anti-cheat as adversarial robustness. Any system with thousands of participants will have adversarial actors. MMO anti-cheat — server-side validation, behavioral analysis, rate limiting — maps to the adversarial evaluation the measurement page describes: Forum spam, Collective Brain poisoning, Claim squatting.
The deepest lesson from MMOs is architectural: the difference between a system that handles 10,000 concurrent participants and a system that is designed for 10,000 concurrent participants is a foundation. You cannot add sharding to a single-server architecture. You cannot add interest management to a broadcast-everything event bus. You cannot add authoritative reconciliation to an architecture that assumes a single writer. These are not features; they are load-bearing structural assumptions that permeate every layer of the system. The same is true for multi-agent coordination: you cannot bolt ClaimsAn exclusive lock on a resource (a file, function, or API endpoint). Only one agent can hold a Claim at a time. If the agent crashes, the lock expires automatically via its TTL. and CRDTsConflict-free Replicated Data Type — a data structure that multiple writers can update independently and still merge into a consistent result, with no central server required. onto a framework designed for serial agent conversations and expect it to hold at 140 agents, let alone 10,000.
Massively multiplayer artifact creation
If MMOs are the precedent for massively multiplayer interaction, the question is what massively multiplayer creation looks like — hundreds or thousands of humans and agents collaborating on shared artifacts (codebases, research programs, physical designs, institutional structures) in real time. This is just beginning to exist, and it is an extraordinarily interdisciplinary problem:
- Distributed systems — the open problem is not CRDTs themselves (the merge math is solved) but semantic merge: when two agents concurrently refactor the same module, syntactic convergence does not guarantee semantic correctness. No existing CRDT library handles code-level intent.
- Game design — interest management and instancing are well understood for spatial worlds, but creation artifacts (codebases, research papers, design specs) have non-spatial dependency graphs. The open problem is dependency-aware interest management: routing coordination events based on semantic impact, not proximity.
- Organizational theory — Brooks's law and Conway's law describe the pathologies; the open problem is adaptive organizational structure — teams that reshape themselves in response to the artifact's current needs rather than calcifying around initial assignments.
- HCI — the open problem is sensemaking at civilization scale: a human overseeing 10,000 agents cannot read every decision. What interface compresses system state without destroying the anomalies the human needs to see? (Ashby's law applies — see the HITL deep dive.)
- AI/ML — the open problem is not individual agent capability but coordination-aware planning: can an agent reason about the cost of acquiring a Claim, the expected wait for a Signal, and the probability of Forum approval when choosing its next action?
- Cybernetics — the open problem is recursive self-improvement under oversight: a system that modifies its own coordination layer can amplify errors as efficiently as it corrects them. Beer's VSM provides the framework; the engineering mechanism for safe meta-feedback is unsolved.
No single field has the full picture. Open-source development is the closest human analogue — the Linux kernel has thousands of contributors coordinating through mailing lists, maintainer hierarchies, and merge conventions — but its coordination mechanisms evolved organically over decades and resist formalization. Wikipedia is another: millions of editors, persistent artifacts, governance disputes, vandalism defense — but the coordination primitives (talk pages, edit wars, admin actions) are ad hoc rather than designed. Google Docs, Figma, and multiplayer IDEs demonstrate real-time co-editing of artifacts, but at team scale, not civilization scale, and without agent participants.
The gap: no existing system combines real-time concurrent editing, persistent institutional memory, formal coordination primitives, human and agent participants, and scale beyond a single team. Filling that gap requires treating the coordination layer as a first-class engineering discipline — not an afterthought, not a bolt-on, but the foundation on which everything else is built. That is what “designing for multiplayer from the ground up” means when the artifacts being created are not characters in a game world but codebases, research programs, and organizations.