The Coordination Problem

Preface

When television was first introduced, early producers did not know what to do with the medium. They set up a camera in front of a microphone and filmed radio actors reading their scripts. For years, television was radio with pictures, built by people who understood the old medium too well to see the new one clearly.

We are clearly doing the same thing with artificial intelligence right now.

The current industry default for building "agentic systems" involves constructing virtual org charts: a Coding Agent passes natural-language messages to a Marketing Agent, which passes it to a QA Agent, and so on. The pattern is intuitive enough that it rarely gets examined. But an org chart is a solution to a particular problem, and software does not obviously have that problem. We may be building elaborate infrastructure to manage a constraint we inherited rather than one we actually have.

What follows is an attempt to work out what the architecture looks like once you stop assuming an agent resembles an employee. That requires starting further back than these discussions usually do, with the question of what an agent actually is, because nearly everything else turns out to be downstream of the answer.

Agents as Ephemeral Extensions of a Hive-Mind

The place to start is with a basic question: what constitutes an agent?

Load the same context history, attention activations, and execution state into Model A and Model B, and the two will behave as the same entity. The essence of an agent, in other words, is portable. It can be transported from model to model, with the model itself reduced to an intelligent manipulator of that underlying state. Current agent frameworks assign enormous importance to the concept of a "session." But a session is just a snapshot of state that can be injected into any harness at will. Once that is clear, the locus of an agent's identity shifts from the process running it to the data behind it.

Defining the hive-mind

Once an agent's identity is understood as the data behind it, a further consequence follows: there is no requirement that an agent run as a single, continuous process. If the same context can be injected into any one harness on demand, it can be injected into many harnesses at once. What results is closer to a hive-mind than to a conventional agent: a system of independent, ephemeral actors, each instantiated and discarded as needed, all reading from and writing to the same central store. The actors are disposable. The store is what persists.

Three properties follow from this definition.

Continuous context evolution

The context corpus is not a static database that agents merely consult. This distinction matters more than it first appears. In a conventional retrieval architecture, the store is reference material: agents read from it, reason over it, and produce output somewhere else entirely, leaving the source untouched. In a hive-mind architecture, every dispatched agent is a read-write transaction against the core. It adds, updates, and deletes. The output of the work and the mutation of the store are the same event, not two separate ones.

The practical consequence is that the corpus is never idle. It evolves continuously, in real time, with every interaction it services. This imposes real engineering requirements that a passive knowledge base never has to meet. If dozens of ephemeral agents write concurrently, the store needs transactional guarantees, versioning, and conflict resolution at the level of an operational database rather than a document repository. Write contention becomes a first-class architectural problem rather than an afterthought.

It also changes how the asset behaves over time. A conventional database depreciates: it goes stale unless deliberately maintained. A live context corpus appreciates, because every task executed against it leaves a residue that the next task can use. Every negotiation, every decision, every reversal and its reasoning accumulates in one place. Over a long enough horizon, the corpus stops being a record of what the organization knows and becomes a record of everything the organization has ever done, in a form that is directly executable by the next agent dispatched.

Agents as ephemeral probes

An agent is not, in this framing, a continuous process occupying a server rack. It is a temporary execution thread, dispatched from the core corpus to complete a task, alter state accordingly, and collapse back into the whole. Its lifecycle is short and complete: instantiate with a scoped slice of the corpus, execute, write back, terminate. Nothing of consequence lives inside the agent itself, because everything of consequence lives in the store it was drawn from.

This reframes reliability. When an agent holds durable state, a crash is a loss and recovery is a hard problem. When agents are probes, a crash is simply a discarded probe against an unchanged core, and retry is close to free. Failure stops being an exception to design around and becomes an ordinary, cheap event.

It reframes scale in the same way. You do not maintain a fleet of long-lived agents with their own accumulated context, drifting apart from one another over time. You dispatch and collapse. Capacity becomes a question of how many probes you can run against the store at once, not how many persistent processes you can afford to keep warm. The cost model shifts accordingly, from uptime to invocation.

Most importantly, it dissolves the session as a meaningful unit. A session is only load-bearing if the state inside it is the only copy. Once state lives centrally and probes are instantiated from it, a "conversation" is not an object with a lifespan. It is a view over the corpus at a moment in time, reconstructible on demand, and just as easily reconstructed in ten places simultaneously.

Data portability as identity

If models are interchangeable manipulators of state, then intelligence itself is not the differentiating asset. The only persistent, defensible property of an organization running this architecture is its evolving corpus of context.

Follow this to its conclusion and the strategic picture inverts. If you can carry your corpus from one model to another, you effectively operate one continuously growing agent even as the models underneath it are swapped out. Frontier providers become interchangeable suppliers of inference, competing on price, latency, and capability, but not on lock-in, because the thing that makes your agent yours never lived in their weights. Switching costs collapse on the model side and concentrate entirely on the data side.

This is also what makes the long-running agent and the swarm of ephemeral agents formally equivalent. A single agent operating over months and a thousand ephemeral agents reading and writing to one constant bucket of data are the same system described at different resolutions. Continuity is a property of the store, not of any process.

The corollary is worth stating plainly, because it is the load-bearing claim of everything that follows: two agents with identical context are the same agent. Distinctness between agents can only come from distinctness in the data behind them. Any other apparent difference is a difference in framing, not in kind.

Internal Architecture Entails Consolidation

With that established, the argument deferred in the preface can be made properly. The question is not whether org charts work, since they demonstrably do for the organizations that invented them. The question is why they exist at all, because that reason determines whether any of it transfers.

Human teams are a workaround for a hardware constraint. A human brain has finite memory, bounded working memory, and a high cost of context-loading between tasks. To do anything complex, humans must specialize. Marketing, legal, and engineering are separate functions because no one person can hold all of them at once. And because humans cannot transfer neural state directly, they coordinate through low-bandwidth channels: conversation, documentation, meetings.

Most current multi-agent frameworks copy this structure directly. A Designer Agent and a Coder Agent are instantiated from the same base model, given different system prompts, and set to passing JSON back and forth as though they were departments.

The analogy fails on inspection, in three distinct ways.

Humans are finite in expertise while models are general

The reason human organizations split into functions is a hard biological ceiling. Working memory is small. Loading context is slow and expensive. Reaching genuine depth in a domain takes years of a finite career, which means depth in one field is purchased directly at the cost of breadth across others. Given those constraints, division of labor is not a management preference. It is the only available strategy, and a collection of specialized humans reliably outperforms any individual generalist.

A frontier model pays none of these costs. Legal, technical, operational, and creative knowledge coexist in the same weights, retrievable in the same forward pass. Switching domains costs a prompt token, not a decade. The premise that made human specialization necessary simply does not hold, which is why the narrative of a single agent capable of running an entire company is coherent in a way that a single human running an entire company is not.

This means that instantiating a "Legal Agent" does not add legal expertise to your system. The base model already had it. What the instantiation does is subtract access to everything else, narrowing the model's usable latent space to the region the prompt points at. Specialization by prompt is subtraction dressed up as division of labor.

There is a legitimate short-term exception. You can post-train distinct checkpoints and produce agents that genuinely differ at the level of weights rather than instructions, and in the near term this can outperform a generalist on narrow tasks. But it is a transitional architecture rather than a stable one. As base model capability improves, the gap between a specialist checkpoint and the generalist frontier narrows, while the cost of maintaining, evaluating, and re-training a fleet of checkpoints stays flat or rises. The trend line favors consolidation.

Human specialization is structural, and prompt specialization is superficial

When a company hires a lawyer and an engineer, it acquires two physically distinct information-processing systems with largely non-overlapping training histories. The separation is structural. It exists whether or not anyone acknowledges it, and the handoff between them is genuinely necessary because neither can do the other's work.

Post-training or prompt-engineering three sub-agents from an identical base model does not produce three experts. It produces one expert wearing three hats. No structural separation exists at any point, which means every handoff between these agents is optional overhead rather than a necessary transfer.

The overhead is not trivial. Each handoff requires serializing internal state into natural language or JSON, transmitting it across a process boundary, and asking the receiving instance to reconstruct an approximation of what the sending instance held. This is lossy by construction. Information that existed as rich activations gets compressed into a few hundred tokens of text and re-expanded on the other side, and the reconstruction is never complete. Chain three or four of these handoffs together and the degradation compounds, which is exactly why long agent pipelines tend to drift from the original objective in ways that are difficult to debug.

The irony is worth sitting with. Lossy inter-agent communication is the single worst feature of human organizations, the one every management practice ever invented has tried to mitigate. It exists among humans because there is no alternative. Reproducing it inside a system built on one model is a choice, and a system that makes that choice pays for it twice: once in latency, once in tokens.

"One agent per role" misattributes its own performance gains

Multi-agent configurations do often beat single-agent baselines on benchmarks, and this evidence is where the org-chart narrative draws its authority. The result is real. The explanation attached to it is not.

Isolate what actually changed when you moved from one agent to five. You are now spending roughly five times the forward passes and five times the reasoning tokens. You have typically also decomposed the problem into explicit subproblems and added a synthesis step at the end. Each of these is independently a well-documented source of improvement: chain-of-thought expansion, test-time compute scaling, and structured problem decomposition. None of them requires that the sub-calls be labeled with job titles.

The test is straightforward. Give one model the same compute budget and the same decomposition, without the orchestration layer or the role framing, and the gains largely survive. The role labels are doing narrative work, not computational work. They make the architecture legible to humans who already think in org charts, which is a real benefit for communication and a false one for performance.

The cost of conflating the two is that teams invest heavily in orchestration frameworks, message schemas, and inter-agent protocols when the actual lever was compute. They build infrastructure to manage a division of labor that was never load-bearing.

If role specialization is largely illusory, the question becomes: why instantiate more than one agent at all?

The answer is speed, not division of labor. In digital systems, the binding constraint is not cognitive bandwidth but execution latency. A single sequential generation stream mutates state one token at a time. Inside a single enterprise, the only sound justification for running multiple agents is parallelizing execution across time. Not simulating a meeting, not manufacturing a diversity of perspective, but running ten identical, frontier-level inference streams against ten distinct branches of the same central context store simultaneously.

Inside the boundary of a single enterprise, then, artificial role divisions collapse. What remains is a single unified context store, serviced by parallel streams of identical inference.

External Interoperability

If internal architecture collapses to one unified state, a further question follows immediately: what stops every agent in an economy from consolidating the same way, into one global model?

The answer is data and intellectual property.

If intelligence itself is commoditized, an organization's only durable moat is its proprietary data. At the level of an economy, distinct agents persist not because intelligence is scarce, but because the private data stores behind each agent are.

When two enterprises negotiate or transact, exposing their core context stores directly is an existential risk, not a productivity gain. Uncontrolled contact between two corporate hive-minds is a path to trade-secret exposure rather than collaboration. If a business becomes the data behind it, then every external interaction is an interaction between the assets themselves, and needs to be governed accordingly.

Agents as dispatched threads

Picture each enterprise as a dense ball of yarn: its full proprietary state, wound tight. Pricing models, margin structures, customer records, product roadmaps, the complete history of past negotiations and what was conceded in each. Everything the corpus has accumulated is in there, and it is precisely the thing the organization would fight hardest to protect.

Almost none of it is required to complete any given external interaction. Negotiating a freight rate does not require exposing your margin structure across every other lane. What the interaction requires is a thread: one strand pulled from the ball, carrying the minimal scoped context relevant to that specific transaction and nothing beyond it.

This makes scoping the core security primitive of inter-enterprise agent work rather than a hygiene practice bolted on afterward. Every externally dispatched agent should be constructed against an explicit context budget that specifies three things: what it is permitted to read from the corpus, what it is permitted to reveal to the counterparty, and what it is permitted to commit to on the organization's behalf. An agent that has never been given a piece of information cannot leak it under adversarial questioning, cannot be socially engineered out of it, and cannot infer it from context it does not hold.

This is where the architecture offers something better than a human equivalent rather than merely an equally risky one. A human negotiator who knows the confidential floor price cannot un-know it while sitting across the table. Every signal they emit is shaped by information they were never supposed to transmit. An ephemeral agent can be instantiated having genuinely never known it. Minimal disclosure stops being a matter of discipline and becomes a property of construction.

The thread also runs in both directions, which is easy to overlook. Whatever the dispatched agent learns during the interaction (counterparty behavior, revealed constraints, terms offered and refused) flows back into the home corpus when the probe collapses. Every external interaction is simultaneously a transaction and a data acquisition event, and the corpus that dispatched the thread is strictly richer for having done so.

Zero-knowledge negotiation

The limit case of scoped disclosure is transacting while revealing nothing at all.

Consider what negotiation currently requires. Two parties who want to know whether a deal exists must each disclose enough information for the other to evaluate it, and disclosure is irreversible. You cannot retract a number once it has been seen. This forces every negotiation into a sequence of calibrated partial reveals, where each side discloses the minimum needed to keep the conversation alive and the process terminates not when the optimal deal is found, but when one side becomes unwilling to reveal more. Deals that would have benefited both parties go undiscovered because finding them would have required someone to expose something they could not afford to expose.

Cryptographic execution changes the shape of this problem. Two agents enter a trusted execution environment, each carrying its scoped context. Computation runs over the joint inputs inside the enclave, where neither party's raw context is legible to the other or to the host operating the hardware. What emerges is only the result: whether a deal exists, on what terms, and a proof that the computation was performed faithfully over the inputs each side claimed to provide.

The simplest instance is a price negotiation. A buyer's maximum and a seller's minimum can be compared inside an enclave that returns only whether the two ranges overlap and where within the overlap to settle, without either party ever learning the other's reservation price. The same construction generalizes: supply chain matching without revealing inventory positions, credit assessment without surrendering financial statements, joint demand forecasting without either party pooling its customer data into a shared store.

The broader claim is that negotiation stops being an exercise in managed disclosure and becomes an exercise in verified computation. Two direct competitors can locate a Pareto-optimal outcome that neither could have found alone, without either surrendering the proprietary corpus that makes them competitors in the first place. This is the natural endpoint of the architecture: if the corpus is the only durable asset, then the infrastructure that lets corpora interact without being exposed to one another is the infrastructure the agentic economy actually runs on.