The Protocol Layer

The Coordination Problem

In the previous post we showed that network geometry determines how institutions scale — and that AI agents are shifting firms toward group-forming networks with Reed-scale potential.

But we ended with an unresolved tension:

Dense networks need coordination mechanisms that are not hierarchy.

A million possible groups means a million possible coordination failures. Hierarchies solved this by limiting connections — a manager decided who worked with whom. Group-forming networks cannot rely on that mechanism.

They need something else. Something between the participants and the infrastructure. Something that governs how interactions happen without a central authority managing each one.

The protocol layer.

From Managers to Protocols

Traditional firms coordinate work through hierarchy. Managers allocate work, sequence activities, and resolve conflicts. Communication flows through structured chains.

This structure reduces the number of possible interactions. Workers do not coordinate with everyone — they coordinate through the chain of command. Hierarchy scales stability, but it scales poorly across organisational boundaries.

Modern work increasingly happens across networks that include partner firms, contractors, platforms, open ecosystems, and autonomous systems. In these environments, hierarchy becomes insufficient. Participants cannot rely on supervision. They must coordinate through rules and interfaces.

A protocol is a standardised pattern of interaction. In computer networking, protocols define the rules governing how data is transmitted, formatted, and interpreted between systems. Applied to organisations, protocols answer four questions:

1. Who can participate?
2. What actions are possible?
3. What information must be exchanged?
4. How are outcomes validated?

Once a protocol exists, interactions do not need to be renegotiated each time. Participants follow the protocol.

What Protocols Change

Instead of participants coordinating directly — each pair negotiating how to interact — interactions are mediated through a shared interface.

Participants integrate with the protocol once. The protocol governs interaction. This changes the scaling dynamics: without protocols, coordination cost grows with the number of connections (Brooks’s Law). With protocols, each new participant bears a fixed integration cost rather than an incremental cost per relationship.

Protocols reduce negotiation overhead — but they are not free. They introduce integration cost, compliance cost, and the risk of lock-in. The standardisation that makes coordination easier also constrains what kinds of coordination are possible. Protocol design involves real tradeoffs: openness versus control, flexibility versus standardisation, composability versus coherence.

Protocols do not eliminate coordination cost. They restructure it — replacing per-interaction negotiation with one-time integration.

The Protocol Layer

The protocol layer sits between participants and infrastructure.

This layer includes:

• Protocols — the rules governing interaction (who, what, how)
• APIs — implementations of those rules as callable interfaces
• Workflows — sequences of protocol interactions that produce outcomes
• Event systems — asynchronous signals that trigger protocol-governed actions
• Data schemas — the shared vocabulary that makes interactions machine-readable

A protocol is the set of rules. An API is one implementation. The distinction matters: multiple APIs can implement the same protocol, and changing the API does not necessarily change the protocol. The protocol layer is the conceptual structure; the technical implementation is its expression.

Protocols turn interactions into structured transactions. The network becomes programmable.

Protocols in Practice

The power of the protocol layer becomes clearer with concrete examples.

Stripe defines a payment protocol. Who can participate (merchants, banks, cardholders). What actions are possible (charges, refunds, disputes). What data is exchanged (payment intents, webhook events). How outcomes are validated (confirmation callbacks, idempotency keys). A merchant integrates once with Stripe’s protocol. From that point, they can transact with any bank, any card network, any customer — without negotiating each relationship individually.

Slack defines a group-forming protocol. Workspaces define participation boundaries. Channels define interaction contexts. Integrations define how external services participate. The protocol governs how groups form, how information flows between them, and how interactions are structured — enabling Reed-scale group formation without the coordination collapse that unstructured group communication produces.

Uber defines a matching protocol. Riders and drivers participate through standardised request-and-accept interactions. Pricing, routing, and dispute resolution are protocol-governed. Neither party negotiates with the other directly. The protocol mediates.

In each case, the protocol layer is where value concentrates. The companies that scaled were not the ones with the best infrastructure — they were the ones that designed the best interaction rules.

The firms that scaled were not infrastructure providers. They were protocol governors.

Platforms as Protocol Governors

Digital platforms appear to provide infrastructure. But their real leverage lies elsewhere — they control interaction rules.

Platforms govern protocols that define:

• who can participate
• how transactions occur
• how value flows through the network
• how disputes are resolved

Control over the protocol means control over the network. Apple’s App Store rules determine what software reaches a billion users. Visa’s interchange protocols govern how value moves between merchants and banks. Uber’s matching algorithm decides which driver serves which rider.

Participants may be independent. But interaction is not.

This raises a governance question that the protocol layer does not automatically answer: who designs the protocol, and how does it evolve? Open protocols (like HTTP or email) are governed by standards bodies and evolve through consensus. Proprietary protocols (like Stripe’s or Uber’s) are governed by the platform owner and evolve through unilateral decision. The choice between open and proprietary protocols shapes the power dynamics of the entire network.

Protocols and Coordination Density

In Post 10 we introduced coordination density — the ratio of productive interactions to the cost of maintaining them.

Protocols increase coordination density by reducing negotiation overhead, standardising interactions, and making them machine-readable. Once interactions are structured, they can be logged, verified, automated, and optimised. Software begins to coordinate work.

This is the mechanism that resolves the tension between Metcalfe’s Law and Brooks’s Law. Metcalfe tells us that potential value grows with connections. Brooks warns that coordination cost grows too. Protocols change the cost structure — they make each additional connection cheaper to maintain, allowing the network to capture more of its Metcalfe potential before Brooks-scale overhead overwhelms it.

The Protocol Firm

Historically, firms controlled assets — factories, distribution networks, supply chains. Digital firms increasingly control interaction surfaces — APIs, workflows, event streams, data schemas.

This produces three distinct organisational models:

The industrial firm manages workers. The platform firm manages infrastructure. The protocol firm manages how participants interact.

In Coasean terms, the protocol firm exists because it reduces transaction costs at the interaction layer. It does not need to employ the participants or own the infrastructure. It needs to define the rules by which participants coordinate — and those rules must be good enough that participants prefer following them to negotiating bilaterally.

Executable Coordination

Protocols do something subtle. They turn coordination into software.

Interactions become events. Events trigger workflows. Workflows produce outcomes.

Once coordination becomes executable, the network begins to behave like a computational system. Work flows through it. Tasks trigger processes. Results propagate through the network.

This is not metaphor. A Stripe charge event triggers a webhook, which triggers a fulfilment workflow, which triggers a shipping notification, which triggers a delivery tracking process. The entire sequence is protocol-governed, event-driven, and machine-executable. No human coordinates the flow. The protocol layer does.

Toward the Agentic Firm

Protocols make something new possible: participants no longer need to be human.

Software services have followed protocols for decades — that is what APIs are. But traditional services are rigid. They execute predefined operations in predefined sequences. They cannot handle ambiguity, negotiate within protocol boundaries, or adapt when the protocol encounters an edge case.

AI agents are different. They can:

• Interpret protocol semantics, not just execute them — understanding what an interaction is meant to achieve, not just how it is formatted
• Negotiate within protocol boundaries — choosing between valid actions based on context, not just following a fixed script
• Adapt to novel situations — handling edge cases that the protocol designer did not anticipate, escalating to human anchors when necessary
• Compose protocol interactions — chaining multiple protocol steps into complex workflows without explicit orchestration

The distinction matters. A microservice following Stripe’s API executes a charge. An agent following Stripe’s protocol can evaluate whether to charge, how much, when, and under what conditions — within the rules the protocol defines.

This is not simply a matter of capability. It is a matter of delegation. Tomašev, Franklin, and Osindero’s work on intelligent AI delegation formalises what this requires: authority transfer (the agent is empowered to act), accountability chains (the human anchor retains responsibility), trust assessment (the protocol defines what the agent is trusted to do), and escalation procedures (the agent knows when to defer). Delegation through protocols is what distinguishes an agentic firm from a collection of automated scripts.

For agents to participate in firm-level protocols, they need their own infrastructure protocols. Anthropic’s MCP (Model Context Protocol) standardises how agents connect to tools and data sources. Google’s A2A standardises how agents discover and communicate with each other. These are the HTTP and TCP/IP of the agentic layer — they make agent participation possible, but they do not define what agents coordinate around. That remains the job of the firm’s protocol layer.

The scale of this shift is worth noting. Google’s A2A launch included over fifty partner companies — Salesforce, SAP, Intuit, PayPal, ServiceNow, alongside every major consulting firm from McKinsey to Deloitte. Salesforce describes the goal as turning “disconnected capabilities into orchestrated solutions.” TCS calls it “semantic interoperability.” These are not research projects. They are engineering commitments to protocol-governed agent coordination at enterprise scale.

The network becomes an execution environment. The firm begins to resemble a distributed computing system — not in the metaphorical sense of “it’s like a computer,” but in the literal sense that work flows through protocol-governed event streams, executed by autonomous agents, validated by protocol rules, and anchored by human intent.

The Next Transformation

Hierarchy coordinated labour.

Platforms coordinated markets.

Protocols coordinate networks.

The next transformation follows naturally. When protocols define how work flows through a network, software can begin to participate in that flow. The firm becomes programmable.

But defining rules is not enough. When work actually flows through these protocol-governed networks — arriving, waiting, being processed, moving on — a deeper set of dynamics emerges. Dynamics that determine whether the network stays responsive or collapses under its own coordination weight.

Protocols define the rules. The question is: what happens when those rules execute under load?

References & Intellectual Lineage

• Metcalfe, R. (1980). Network value and telecommunications economics.
• Conway, M. (1968). “How Do Committees Invent?”
• Brooks, F. (1975). The Mythical Man-Month.
• Coase, R. (1937). “The Nature of the Firm.”
• Williamson, O. (1985). The Economic Institutions of Capitalism.
• Tomašev, N., Franklin, M. & Osindero, S. (2026). “Intelligent AI Delegation.” arXiv:2602.11865.
• Post 10 in this series: Coordination density and the three laws.
• Post 11 in this series: The Geometry of Networks — network scaling laws.