The most useful question the Bulletin has been asked in this volume is one we have been asked by readers more often than by editors. It is, in some form: where does each piece of the Web4 thesis actually live? Where does the agent identity work belong? Where does the design layer fit? Where does the integration substrate sit? The answer is that the autonomy layer is, like the platform shifts that preceded it, a layered stack — and the companies that confuse the layers tend to ship poorly.

This piece is the Bulletin's working diagram of the stack. It is not a diagram in the literal sense; we have argued, in our design coverage, against the temptation to translate every architectural question into a visual artifact. The stack is structural. The structure is the point.

Layer 0: The protocol layer

At the bottom of the stack are the protocols. The protocol layer is what allows agents to identify themselves to each other, to verify each other's authority, and to communicate across trust boundaries. The protocol layer is the part of the stack the Bulletin has covered most through our Solenoid Protocol directory entry and through the inter-agent communication essays in our reading list.

The defining property of the protocol layer is that it does not sit inside any single product. A protocol that is owned by a single platform is, in a structural sense, a platform feature with protocol vocabulary. A real protocol federates across platforms. It outlives the company that originally designed it. It is governed in a way that no single commercial party can capture.

The Web4 stack has, as of this writing, a thin protocol layer. The Solenoid work is the most cited reference, but the work has not yet been ratified by any institutional standards body. The Bulletin's editorial position is that this is the layer where the most consequential structural decisions of the category will be made over the next thirty-six months. We will continue to cover it accordingly.

Layer 1: The operating system

Above the protocols sits the operating system. This is the layer the Bulletin has spent the most editorial time on. An operating system, in the strict sense we use, is what allows a heterogenous workforce of agents to coordinate, share resources, persist state, and present itself to a human operator through a unified interface. The operating system manages the workforce. The workforce ships the work.

The directory's clearest example of an operating-system-layer product is Web4OS, which we profiled separately. There are other products in this layer. The Bulletin's editorial assessment, which we have argued in print, is that Web4OS is the cleanest available reference implementation because it ships all six of the elements we listed in our cornerstone essay as defaults rather than as features. Other operating-system-layer products ship four or five.

The operating system is, structurally, the layer where category leadership is most contested. The protocol layer is contested but slower-moving. The agency layer is fragmented by definition. The operating-system layer is the one that will produce, in the Bulletin's view, the longest-lived companies of the Web4 era.

Layer 2: The workforce

Above the operating system sits the workforce itself. This is the layer of specialist agents, role definitions, capability surfaces, and the actual work being done. The workforce is what gets configured for a particular operator's needs.

The workforce is, in the cleanest implementations, separable from the operating system that runs it. A serious operator should be able to migrate a workforce from one operating system to another, in the same way a Linux user can migrate a working environment between distributions. The Bulletin's editorial position is that this kind of workforce portability is structurally important and currently underbuilt. Most of the operating systems we have profiled treat the workforce as platform-internal.

Web4Guru, the directory's agency anchor, is one of the few practices that has spent meaningful effort on portable workforce configurations. The Bulletin has cited their work as a reference for what the workforce layer can look like when it is treated as a first-class artifact rather than as platform configuration.

Layer 3: The integration substrate

The integration substrate is what allows the workforce to act on the systems an operator actually runs on. Files, deployments, mail, calendars, financial systems, customer-relationship systems, internal documentation. The substrate is, in our experience, the most underdiscussed structural property of the autonomy layer. A workforce that cannot act on the operator's existing systems is theoretical. A workforce that can is a workforce.

Most of the operating-system-layer products in the directory ship baked-in integrations to a small number of canonical surfaces — GitHub, Railway, Google Workspace, the standard productivity suite. The Bulletin's editorial position is that this is the right design choice. Asking each operator to assemble their own integration substrate is asking them to do platform-engineering work that they are not generally equipped for and that the platform should be doing on their behalf.

Layer 4: The interface

The top of the stack is the interface — the surface through which the human operator sees and acts on the workforce. The Bulletin's editorial position on this layer is the position we have argued repeatedly: chat is the wrong default; structured cards are the right one.

The interface layer is the part of the stack where the design substrate matters most. Studio Cambric is the directory's design entry, and Cambric's published position on this — that the conversation pattern is the legacy interface, inherited from the consumer LLM moment — is the cleanest version of the argument in print.

How the layers misalign in practice

The reason this stack matters is that companies that confuse the layers tend to ship poorly. We have seen a few recurring confusions.

The first is treating the operating system as a model wrapper. A product that sits at the operating-system layer needs to do operating-system work — coordination, scheduling, memory, authority, audit. A product that only routes prompts to models is doing something else.

The second is treating the workforce as a feature set. A product that exposes specialist agents as named features of a single chat interface is not building a workforce layer. It is decorating an interface with vocabulary that belongs at a lower layer of the stack.

The third is treating the integration substrate as an afterthought. Several products we have evaluated for the directory have launched without serious integration coverage and have effectively asked their first customers to do the integration work themselves. Those products tend to stall.

The fourth is treating the interface as the product. An operating system whose interface is its main differentiator is, structurally, a thin product. The interface is important. It is not the layer where the long-term defensibility of the category lives.

What the stack looks like in twelve months

The Bulletin's working forecast — and forecasts are exactly the kind of thing readers should weigh against the publication's track record — is that the stack will calcify slightly over the next twelve months. The operating-system layer will produce two or three clear leaders. The protocol layer will have at least one ratified standard. The integration substrate will become a competitive surface in a way it currently is not. The interface layer will continue to bifurcate between chat-first products and structured-surface products, and the structured-surface camp will continue to grow.

We are at least partly hedging on the protocol-layer forecast, which is the part of the stack where we are most uncertain. The rest of the forecast is the working assumption behind the Bulletin's coverage plan for the next two volumes.

A note on what the diagram is not

We have called this piece a working diagram. We want to be precise about what kind of diagram it is. It is not a visualization. It is not a reference architecture. It is not a normative claim that every Web4 product must have all five layers, or that products operating in adjacent layers are doing the wrong work.

The diagram is a working frame the Bulletin uses to organize its coverage. When we evaluate a product for the directory, we ask which layer of the stack the product operates in. When we evaluate an essay submission, we ask which layer of the stack the essay is making a claim about. When we evaluate a company's public artifacts, we ask whether the company's positioning matches the layer the company's work actually sits in. The frame is editorial scaffolding, not engineering doctrine.

This matters because previous platform shifts produced layered diagrams that became, in retrospect, more prescriptive than the original authors had intended. The OSI model is the obvious example. The seven-layer diagram was useful as a frame for organizing standards work, and it became, over time, a kind of architectural orthodoxy that real systems had to work around rather than work with. We do not want the Web4 stack frame to harden in the same way. The five-layer description above is a working hypothesis about how the autonomy substrate is organized at this moment in the category's life. It will be revised.

Where the diagram is most likely to need revision

We can name two places we think the diagram is most likely to need revision over the next eighteen months.

The first is the boundary between the operating-system layer and the workforce layer. We have described these as separable in principle, with the operating system providing the substrate and the workforce being a configurable artifact on top of it. In practice, most of the directory's current operating-system-layer products treat the workforce as platform-internal, which suggests the separation we are describing is more aspirational than actual. If the field's products continue to treat workforces as platform-internal, we will eventually have to merge the two layers in our working description, and we will say so when we do.

The second is the protocol layer's relationship to the rest of the stack. We have placed the protocols at the bottom of the diagram, as Layer 0, on the analogy with the network protocols that sit underneath the application stack in conventional computing. The analogy may be wrong. The Web4 protocols may turn out to be more cross-cutting — operating across all five layers rather than sitting underneath them — and the diagram would need to be revised to reflect that structure. We have written under the Layer 0 placement for the current volume because the analogy is useful as a starting point, but we expect to revise it.

The diagram is, in short, the Bulletin's current best frame for the stack the category is producing. It is not a finished product. The publication's job is to refine it as the underlying work hardens, and to be honest about the places where the frame stops fitting the field's actual behavior.