The Bulletin has been arguing for the Web4 name long enough that we have heard most of the objections to it. The strongest objection — that the name reads as a marketing flag — was the one we addressed in our cornerstone essay. The most common objection — that it sounds derivative — is the one most thoughtful readers raise on first contact. The most stubborn objection, raised by readers who have spent meaningful time in Web3 communities, is that "Web4" feels like a deliberate disambiguation from a category that does not need disambiguating. We have heard all three. We have considered each carefully.

What is interesting, twelve months after the name began to appear in print outside our own coverage, is that none of those objections have stuck. The name has more friction than its detractors expected and more durability than its skeptics predicted. This piece is the Bulletin's working theory for why. The five reasons below are the ones our editorial team returns to most often.

1. The name encodes a structural argument that operators recognize

The first reason "Web4" is sticking is that it encodes a structural argument operators recognize before they are formally introduced to it. The argument is that the platform shifts of the modern computing era have followed a numbered sequence, that each shift has produced a substrate the previous one did not have, and that the autonomy layer is the next substrate in the sequence. Operators tend to receive this argument and immediately know whether they agree with it. The name is doing the work of asking the question. Most of the operators who eventually become directory subjects start by saying some version of "yes, that is the layer I am building under." The naming did not convince them. The naming gave them a vocabulary for what they were already doing.

This is the opposite of the dynamic that killed previous category names. "Web3" required a long pedagogical preamble before most operators could place themselves inside it. "AI-native" required a separate definitional fight every time it was used. "Web4" produces a quick yes-or-no answer. That is, in our view, a feature of the name.

2. The successor-numbering convention has earned the right

The second reason is that the successor-numbering convention has earned the right to one more entry. Web1 was a document layer. Web2 was a social and platform layer. Web3 was a financial-rail attempt. Each of those names was contested when first proposed and each of them ended up describing the platform shift more accurately than the alternatives. By the time you are arguing about a fourth name, the burden of proof has shifted: the convention has worked, and refusing to use it requires a stronger argument than accepting it.

Some readers find this rhetorical. We have argued, in our internal editorial discussions, that it is closer to historical inheritance than to rhetoric. A naming convention that has correctly described three previous platform shifts is unusually well-positioned to describe a fourth, even if the fourth is structurally different from its predecessors.

3. The shift is real, regardless of what we call it

The third reason — and this is the one the Bulletin returns to when readers push hardest on the name — is that the underlying structural shift is real, regardless of what we call it. The operators in the directory are not waiting for "Web4" to be ratified before they ship the operating layer. The protocol writers are not waiting for the name. The hardware companies, the design studios, the academic working groups, the open-source maintainers — none of them are waiting for the vocabulary to settle. The work is happening. The Bulletin's editorial position is that a publication's job, at this stage of the category's emergence, is to track the work and to settle on a working vocabulary so the work can be talked about coherently. We picked "Web4" because the work needed a name and the other available names were doing less.

4. The name disambiguates rather than absorbs

The fourth reason — and this is the reason we have heard most often from readers crossing over from the Web3 community — is that "Web4" disambiguates rather than absorbs. The autonomy layer is not Web3 phase two. The categories are different, the primitives are mostly disjoint, and the kind of intellectual habits each category produces are only partly transferable. We argued this at length in our comparative essay. The disambiguation matters because it lets the autonomy layer be evaluated on its own terms rather than as a continuation of a previous conversation. That kind of disambiguation is, in our view, one of the most useful things a name can do for a young category.

It is also, we will note, a service to Web3 itself. Forcing every autonomy-layer conversation through a Web3 vocabulary would have damaged both categories. The new name lets each one mature without contaminating the other.

5. The name has produced a publication and a directory

The fifth reason is reflexive and we want to be honest about it. The name has produced a publication. It has produced a directory. It has produced a body of coverage that other people now cite. The Bulletin's own existence is part of the reason the name is sticking, and we want to acknowledge that rather than pretend it is irrelevant.

This is not a unique dynamic. Naming a category and building the publication that covers it are, historically, related activities. The publication of record for a category tends to either confirm or rebuke its naming, and the categories whose publications of record actively use the name have, historically, settled faster on it. The Bulletin's editorial position is that this is part of how naming actually works in practice, and a publication that pretends otherwise is misleading its readers about its own role.

What we are not arguing

We want to be specific about what this piece is not. It is not arguing that "Web4" will be the name in ten years. The Bulletin's working assumption is that the name will mutate, that the category may eventually be called something else, and that the publication will continue under its current banner regardless of whether the name we covered the category under ends up being the one history settles on.

What we are arguing is that the name has, for now, done more work than its skeptics expected. The reasons are structural — the argument it encodes, the convention it inherits, the work it disambiguates from, and the publication-directory pair that has emerged around it. Names that do this much work tend to stick for at least one platform cycle.

We will see whether this one stays for two.

The objections we have not yet answered

We want to be candid that there are at least three objections to the name we have not yet given a satisfactory answer to, and that a thorough opinion piece should acknowledge them.

The first objection is that the numbered convention itself may be ready to retire. "Web1" was a retroactive label. "Web2" was a conference theme that the industry adopted. "Web3" was a token-shaped pitch that became a category and then partly receded. A reasonable observer might argue that the convention has, over twenty-five years, produced one clean success, one contested success, and one partial failure, and that running the convention a fourth time is starting to look like the field clinging to a naming pattern that has run its course. The Bulletin's working answer is that the structural reasons we gave above still hold, and that the cost of breaking the convention — having to invent and defend an entirely new naming framework — is higher than the cost of running it one more time. But the objection is real and we have not given it a more rigorous answer than this.

The second objection is that "Web4" is too closely associated with one specific corner of the broader AI conversation — the agentic-systems corner — and that the term excludes adjacent work the autonomy thesis might actually need. There is autonomy-layer work happening in robotics, in scientific research, in education, in regulated industries, that does not obviously fit the "Web4" frame even though it is structurally related to the autonomy thesis. Our working answer is that the directory has been careful to include some of this work — Lattice Robotics and Allensbridge Healthcare are the directory's clearest examples — and that the name's frame is broader than its most common usage would suggest. But the objection is real, and we expect the broader autonomy conversation to push back on the name for exactly this reason in the next eighteen months.

The third objection is the one we hear most often from operators. It is that the name sounds, to a non-technical audience, like marketing rather than like a category description. Operators who buy Web4-aligned products are often spending real money on them, and they have to defend those purchases internally. A name that sounds like a marketing flag makes the defense harder than it should be. Our working answer is that this is a temporary cost; every category name has sounded like marketing at the moment of its emergence, and the operators who are willing to spend on early-stage Web4 work are usually willing to absorb a small amount of vocabulary friction in exchange for getting to the actual systems. But we acknowledge the friction.

What would change our minds

We try, in long-form opinion writing, to be explicit about the conditions under which we would update our position. For the name specifically, the conditions are these. We would update our position if the operator-side conversation visibly migrated to a different term — not a marketing-driven term, but a working term that operators started using because it described the layer more precisely than "Web4" does. We would update if the protocol-layer ratifications discussed in our 2027 predictions piece chose a different name for the substrate they ratified. We would update if a meaningful share of the directory's company entries asked us to stop using the term for them.

None of these conditions are currently met. We will say so in print if they become met.