The pattern
Every wave of compute capability follows the same structural arc. A new primitive emerges: electricity, packet switching, virtual machines, containers, autonomous agents. Early adopters build vertically integrated systems where the primitive is generated, transmitted, and consumed within a single organisation's infrastructure. Then the primitive grows beyond what any single organisation can manage alone, and a coordination layer appears.
The coordination layer is distinct from the primitive itself. It is the infrastructure that makes the primitive usable at scale: distributable, measurable, governable, and composable across organisational boundaries. The coordination layer ensures the work can happen reliably, across participants who do not trust each other, at a scale that no single participant could achieve alone.
This pattern has repeated with remarkable consistency for over a century. Each time, the coordination layer was controversial when proposed, obvious in retrospect, and the primary source of economic value within a decade of its adoption.
What is a coordination layer?
A coordination layer is infrastructure that sits between producers and consumers of a capability, providing guarantees that neither party can enforce alone. It manages distribution, metering, access control, failure recovery, and state consistency across a network of independent participants.
The defining feature of a coordination layer is that it is not optional once the capability it coordinates reaches a certain scale. Below that scale, bilateral agreements between producers and consumers suffice. Above it, the combinatorial explosion of bilateral relationships makes direct coordination impractical. The coordination layer collapses O(n^2) bilateral relationships into O(n) connections to a shared substrate.
Electricity: the first coordination layer
In the 1880s, electricity generation was vertically integrated. Factories built their own generators and powered their own equipment. Thomas Edison's Pearl Street Station in 1882 served 85 customers within a one-mile radius. Each customer had a direct relationship with the power source.
This model broke down within two decades. As electrical demand grew, the economics of distributed generation became untenable. A factory that needed power for 10 hours a day owned a generator that sat idle for 14 hours. Multiple factories in the same area each maintained their own generation capacity, their own fuel supply, and their own engineering staff.
The coordination layer that emerged was the power grid: a shared network that connected generators to consumers through standardised transmission infrastructure. The grid distributed electricity, balanced load across generators, maintained frequency stability, and provided metering so that consumers paid for what they used.
The power grid introduced several properties that would recur in every subsequent coordination layer. Standardised interfaces (voltage, frequency) allowed any conforming generator to connect. Centralised dispatch coordinated multiple generators to match supply with demand. Metering created accountability. And redundancy, multiple generators feeding the same grid, provided reliability that no single generator could match.
The economic effect was transformative. Once the grid existed, factories no longer needed their own generators. The capital cost of electrification dropped by an order of magnitude. Industries that could not have afforded their own generation infrastructure gained access to electrical power. The grid made electricity accessible to everyone who could connect.
Packet switching: coordination for data
The early internet faced the same structural problem. In the 1960s and 1970s, computer networks were point-to-point: dedicated circuits connecting specific machines. ARPANET connected a small number of research institutions through dedicated lines. Each connection required bilateral agreement, physical infrastructure, and ongoing maintenance.
The coordination layer was TCP/IP, finalised in 1983: a protocol stack that provided reliable, ordered delivery of data packets across a network of independent routers. Routers and physical links transmitted the data. TCP/IP provided the guarantees that made transmission useful: packets arrived in order, lost packets were retransmitted, congestion was managed, and any two conforming endpoints could communicate without bilateral infrastructure agreements.
TCP/IP introduced a property that the power grid had hinted at: protocol-level guarantees that were independent of the underlying physical infrastructure. A TCP connection provided the same reliability guarantees whether the packets traversed copper, fibre, satellite, or a combination. The coordination layer abstracted the physical substrate, allowing the network to evolve its physical infrastructure without breaking the guarantees that applications depended on.
The parallel to electricity is direct. Before TCP/IP, organisations that wanted to share data built dedicated connections. After TCP/IP, they connected to the network and communicated with any other connected organisation through a shared coordination substrate. The cost of interconnection dropped from "build a dedicated circuit" to "plug in and conform to the protocol."
How did cloud computing follow the same pattern?
Virtual machines created a new primitive: compute capacity that could be provisioned, scaled, and destroyed programmatically. Amazon Web Services launched EC2 in 2006, offering virtual machines on demand. The early cloud was essentially "rent someone else's servers," with each customer managing their own deployment, scaling, and failure recovery.
The coordination layer arrived in two waves. First, infrastructure orchestration tools like Chef, Puppet, and Ansible automated the provisioning and configuration of virtual machines. Then Kubernetes, released by Google in 2014, provided a comprehensive coordination substrate for containerised workloads: scheduling, service discovery, health checking, scaling, rolling deployments, and secret management.
Container runtimes ran the containers. Kubernetes provided the guarantees that made container-based deployment reliable at scale: workloads were scheduled across available capacity, failed containers were restarted, traffic was routed to healthy instances, and deployments rolled forward or back without downtime.
The economic pattern repeated. Before Kubernetes, organisations that wanted to run containers at scale built their own orchestration infrastructure. After Kubernetes, they deployed to a shared coordination substrate that provided scheduling, discovery, and reliability guarantees. The coordination layer made container-based architectures accessible to organisations that could not have built their own orchestration layer.
The structural recurrence
Four waves. Four coordination layers. The same structural properties appear in each.
Standardised interfaces. The power grid standardised voltage and frequency. TCP/IP standardised packet format and addressing. Kubernetes standardised container images and pod specifications. Each coordination layer defined a conformance boundary: produce your capability in this format, and the coordination layer will handle distribution.
Substrate-level guarantees. The power grid guaranteed frequency stability and load balancing. TCP/IP guaranteed ordered, reliable delivery. Kubernetes guaranteed scheduling, restart, and service discovery. These guarantees were enforced by the coordination layer, not by the participants. A generator connected to the power grid did not need to implement its own load balancing. An application using TCP did not need to implement its own packet retransmission. A container running on Kubernetes did not need to implement its own health checking.
Collapsed bilateral complexity. Before each coordination layer, participants managed direct relationships with every other participant. After, they managed a single relationship with the coordination substrate. The grid operator balanced supply and demand. TCP/IP routers forwarded packets. The Kubernetes scheduler placed workloads. The coordination layer absorbed the complexity of multi-party coordination.
Economic accessibility. Each coordination layer made the underlying capability accessible to a dramatically larger number of participants. Factories that could not afford generators gained access to electricity. Organisations that could not afford dedicated circuits gained internet connectivity. Teams that could not build their own orchestration infrastructure gained container-based deployment.
Where does the agent wave fit?
Autonomous AI agents are the current compute primitive. Like electricity, packet switching, and containers before them, agents started vertically integrated: each organisation builds its own agents, runs them on its own infrastructure, and manages their interactions through custom application code.
The limitations of this model are already visible. An organisation running five agents can manage their interactions through direct coordination. An organisation running fifty agents across multiple departments, each acting on shared data, each triggering side effects in external systems, each potentially conflicting with the others, faces a combinatorial explosion of interaction patterns that direct coordination cannot sustain.
The coordination layer for agents must provide the same structural properties that every previous coordination layer provided. Standardised interfaces, so that agents built with different frameworks can participate in the same coordination substrate. Substrate-level guarantees, so that properties like ordered execution, scoped authority, and convergent state are enforced by the infrastructure rather than implemented by each agent individually. Collapsed bilateral complexity, so that agents interact through a shared substrate rather than through pairwise integration. Economic accessibility, so that organisations that cannot build their own agent coordination infrastructure can still run production agent workloads.
The Grid is this coordination layer. It provides the substrate guarantees that production agents require: ordered execution, scoped authority, deterministic retry and rollback, persistent execution-linked memory, a canonical system of record, governed escalation, and convergent state. These are the agent equivalents of frequency stability, packet retransmission, and container scheduling.
What does the universal grid actually coordinate?
The term "universal grid" is an analogy to the power grid, and it holds at the structural level. A universal grid for agents coordinates the distribution of agent capabilities across a network of independent venues, in the same way that the power grid coordinates the distribution of electrical capacity across a network of independent generators.
A venue is an execution environment operated by an independent organisation. It hosts agents, data, and operations. The Grid connects venues into a network where agents can discover and invoke capabilities across organisational boundaries, with the substrate enforcing execution guarantees regardless of which venue hosts the agent or the operation.
The coordination is multi-dimensional. The Grid coordinates execution (ensuring operations complete correctly), state (ensuring shared data converges), authority (ensuring agents operate within their scopes), and governance (ensuring escalation policies are enforced). Each of these dimensions has its own failure modes, and the substrate addresses each through mechanisms adapted from prior coordination layers: lattice data structures for convergent state, cryptographic identity for scoped authority, and step-level execution tracking for deterministic retry.
The timing question
Every coordination layer in computing history appeared at a specific moment: after the underlying primitive was proven but before it reached the scale where coordination became mandatory. TCP/IP was finalised seven years before the World Wide Web. Kubernetes was released three years before container-based microservices became the dominant deployment pattern.
The coordination layer must arrive before it is needed at scale, because building coordination infrastructure under production pressure produces fragile, organisation-specific solutions that calcify into technical debt. The organisations that adopted TCP/IP before they needed it were the organisations that built the web. The organisations that adopted Kubernetes before they needed it were the organisations that scaled their microservice architectures successfully.
The timing question for agent coordination is whether the coordination layer is arriving early enough. Agents are already in production. They are already modifying shared state, triggering side effects, and operating concurrently. Most are running without substrate-level execution guarantees, accumulating the kind of subtle, intermittent failures that compound over time.
Whether the industry adopts a shared coordination substrate before these failures become crises, or after, will determine how painful the transition is. The historical pattern suggests it will be after. The historical pattern also suggests that, after the transition, everyone will agree it was obvious all along.