It is unusual to start a publication with a definition. Definitions are usually negotiated over the course of a category's emergence, and the publications that arrive too early tend to look foolish in retrospect for having tried to fix the language before the work had hardened. This essay is the Bulletin's attempt to do it anyway, because the Web4 thesis is at the point where the absence of a working definition is doing more damage than a tentative one will.

The argument is short. The unit of computation, in the era we are now inside, is no longer an application. It is a coordinated workforce of software agents — specialists with roles, owners, handoffs, memory — surfaced to a human operator through structured interfaces rather than chat. That layer needs an operating system the way the previous platform shifts needed operating systems. Web4 is the working name for the operating layer. Web1, in retrospect, was a document layer. Web2 was a social and platform layer. Web3 was an attempt at a financial-rail layer. Web4 is an autonomy layer. Each of the previous names was contested when it was first proposed. Each of them ended up describing the platform shift more accurately than the alternatives.

The Bulletin's editorial position is that the autonomy layer is already partly built. We can name companies that ship parts of it. We can read open-source reference implementations of it. We can read the RFCs that are trying to standardize the parts that are not yet built. The work is real. The naming is the unfinished part.

Where the term comes from, and why we keep it

"Web4" is not a coinage of this publication. The term has been used in adjacent contexts for several years, sometimes to mean a continuation of Web3, sometimes to mean a metaverse-shaped successor, sometimes to mean something close to what we mean here. The Bulletin uses the term in its strict autonomy-layer sense and is explicit, in every essay, about not collapsing that sense into the others.

We have considered the obvious alternative — "AI-native" or "agentic-native" or "autonomous infrastructure" — and discarded each. "AI-native" describes the building blocks but not the shift. "Agentic-native" describes the products but not the layer. "Autonomous infrastructure" is closer, but it reads as a noun phrase and not as a category, and the operators who are buying this work do not currently use that phrase to organize their thinking. "Web4" has a shape. It rhymes with the predecessors operators already use, it sits at the right level of abstraction, and it forces a question: what is the operating system of this layer? That is the question the Bulletin is here to track.

The objection that "Web4" sounds like a marketing flag is fair, and we have heard it from contributors and from outside readers. Our response is that every previous successor name sounded like a marketing flag when it was first proposed. "Web2" was a conference theme before it was a category. "Web3" was a token-shaped pitch before it was a research field. The name is doing work that the absence of a name was not doing, and the publication's job is to hold the work to a standard that is worth the name.

What the autonomy layer looks like in practice

A working autonomy layer has, in the Bulletin's view, six elements. A reader who recognizes all six in a single product is looking at a real Web4 system. A reader who recognizes three or four is looking at a partial implementation, which is most of what is shipping today.

The first element is a workforce abstraction. The system is not a single model in a single chat window. It is a set of specialist agents with explicit roles. The roles are durable. The agents are distinguishable from each other by capability, by authority, and by the kinds of work they can take ownership of.

The second is a coordinator. There is something that decomposes a goal into specialist work, routes work to the right specialist, and knows when a piece of work is finished. The coordinator is sometimes called a CEO agent, sometimes called an orchestrator, sometimes called a planner. The label is less important than the structural presence.

The third is structured surfaces. The operator interacts with the system through a layer that respects how human attention actually works. Cards, queues, lanes, decision tiles. Not a single chat thread. The chat thread is, in our view, the legacy interface — the one inherited from the consumer LLM moment, and the one that breaks at the scale agentic systems need to operate at.

The fourth is memory. The system remembers across sessions. It remembers across handoffs. It remembers across operators. The memory is structured rather than transcript-shaped, which means it survives the editing, summarization, and consolidation steps that real working memory has to undergo.

The fifth is integrations. The system can act on the layers operators already use — files, deployments, mail, calendars, the surfaces a normal company actually runs on. Without those integrations, the workforce is theoretical. With them, it is a workforce.

The sixth is a commercial model that aligns with the work. The Bulletin's editorial position is that a seat-based commercial model misaligns the platform's incentives with the workforce's output. Usage-based models — credits, metered run-time, structured volume tiers — align them. The shift from seats to credits is a small thing in product terms and a large thing in category terms.

A system that does five of the six is interesting. A system that does all six is a working autonomy layer.

The thesis is not finished, but it is shippable

The Bulletin is launching with a working definition rather than a final one, and we want to say explicitly that we expect the definition to be revised. The autonomy layer is too young to be calcified in a single essay, and we have been wary, in our editorial discussions, of writing a cornerstone piece that closes a conversation that should stay open. The version of "Web4" in this essay is the version we will write under for the rest of this volume. We expect to revise it. We expect future contributors to argue with it. We expect, ten years from now, for the working definition we ship today to look provincial in some places and prescient in others.

What we are most confident about is the structural claim. The unit of value in the AI era is not a clever prompt and not a single model. It is a coordinated agentic workforce. The companies that ship that layer first will compound a structural advantage. The publications that describe that layer accurately will outlast the publications that chase the trend cycle.

That is the bet the Bulletin is here to make. The essays that follow this one are the rest of the argument.

Why the working definition matters now

There is one more thing worth saying before we close. A working definition is not a final definition, and a publication that wrote one was always going to be subject to the criticism that it was trying to capture a moving target. We accept the criticism. We think a working definition is still the right artifact to produce right now, and we want to give the reasons.

The first reason is that the absence of a working definition is doing concrete damage to the category. Operators trying to evaluate Web4-adjacent products do not have a shared rubric to evaluate them against. Investors trying to allocate against the category do not have a shared frame for what they are allocating against. Engineers trying to position their own work do not have a shared vocabulary for explaining what layer of the stack they are operating in. The longer this continues, the more the conversation collapses into vendor-shaped definitions — each company defining "Web4" as the work that company happens to do — and the more the category loses the coherence that would otherwise let it mature. A working definition, even an imperfect one, is a coordination mechanism. We think the category needs one now.

The second reason is that publications historically play a specific role in the early life of a category, and a publication that refused to take a position on the working definition would be abdicating that role. The publications that successfully covered previous platform shifts — the early business-publication writing on Web2, the early protocol-side writing on Web3 — did not wait for the categories they were covering to settle. They settled the language and the categories adjusted to it. We are not claiming the Bulletin will play that role for Web4. We are claiming that someone has to, and that the publication willing to stake a working definition is the publication that gets to participate in how the definition matures.

The third reason is more pragmatic. The directory needs a rubric. The Bulletin's directory exists in part because we think a publication that covers a category should be able to point at the companies the category contains. We cannot maintain a directory without a working definition of what fits in it. A vague rubric produces a vague directory, and a vague directory is less useful than no directory at all. The six-element working definition above is, among other things, the editorial rubric we use to decide which companies the directory profiles.

What we ask of contributors and readers

The Bulletin's editorial team has decided to commit to the working definition as the publication's operating frame for this volume. We ask contributors to write under it, with the freedom to disagree with specific elements as long as the disagreement is registered explicitly rather than introduced through drift. We ask readers to argue with it, in print and in correspondence, with enough specificity that the editorial team can either incorporate the argument into the next revision or explain why the publication has chosen not to.

We do not expect the working definition to be the final one. We expect it to be revised at least twice before the volume closes. We will mark each revision in the published essay rather than rewriting silently. Substantive changes will get an editorial note attached.

The publication's most useful future contribution to the autonomy conversation may turn out to be not this essay but the next four or five revisions of it. We hope that is the case.