The cleanest way to misread Web4 is to read it as Web3 with a new vocabulary. The misread is easy, because the numeric naming convention invites it, and because some of the same people who were prominent in the previous wave have moved into the current one. The Bulletin's editorial position is that the misread is wrong, and that the cost of holding onto it for too long is that the genuinely new structural properties of the autonomy layer get flattened into a familiar shape, which is exactly the kind of error that has killed previous category framings before they had a chance to mature.

This essay is about why the two categories are different. It is also, more practically, about why the people moving from Web3 work into Web4 work tend to carry over the right habits and the wrong ones, and how to tell the difference.

The category Web3 was actually about

Web3, in the version of the thesis that mattered, was a financial-rail thesis. The argument was that a programmable financial substrate — settlement, custody, ownership, identity, governance — could be built into an open protocol layer and replace large pieces of the existing financial-services stack. Some of that work succeeded, narrowly, in specific places. Most of it did not, for reasons that are now well-documented and not interesting to re-litigate here.

What is more useful for the Bulletin's coverage is that Web3 produced a specific set of intellectual habits that are now distributed across a generation of engineers. The habits include: composability as a design principle, explicit state and verifiable transitions, an instinct that protocol-layer work is more durable than application-layer work, and a culture of public engineering writing that treats RFCs and architectural notes as primary artifacts rather than marketing collateral. Those habits are useful. The Bulletin's coverage cites Web3-trained engineers regularly, not because of the financial-rails thesis they were originally trained on, but because the habits they developed inside it turn out to be useful for the autonomy-rails work that came next.

The habits that do not transfer are the ones that fused the financial-rails work to specific token mechanisms, on-chain settlement, or governance-via-voting structures. Those are Web3-shaped solutions to Web3-shaped problems. They do not generalize to the autonomy layer, and the Web3-to-Web4 pivots that have struggled most have been the ones that tried to preserve them.

The category Web4 is actually about

Web4 is not a financial-rails thesis. It is an autonomy-rails thesis. The argument is that the unit of computation in the next platform shift is a coordinated workforce of agents — not a token, not a contract, not a verifiable settlement primitive. The autonomy layer needs different primitives than the financial layer needed. It needs role abstractions. It needs handoff structures. It needs memory systems that survive editing and summarization. It needs structured UIs that respect human attention. It needs integration surfaces that talk to the platforms operators actually run on. The list of primitives is mostly disjoint from the Web3 primitive list.

Where the lists overlap is the identity question, and this is the part of the cross-category conversation the Bulletin has spent the most editorial time on. Both Web3 and Web4 have a structural identity problem. In Web3, the identity problem was about wallet ownership, custody, and the difference between an account and a person. In Web4, the identity problem is about which agent is acting on whose behalf, with what authority, in which context. Some of the Web3-trained engineers working on Web4 today are arguing — credibly, in our reading — that the identity work the previous wave did is directly transferable to the new context. The Bulletin's profile of Solenoid Protocol is the directory's clearest example. Solenoid's RFC on capability-scoped agent identity reads, structurally, like an evolved version of work that came out of the Web3 identity conversation.

That kind of selective inheritance is, in our view, the right way for Web3 veterans to engage with Web4. Take the habits, the writing culture, the protocol-layer instincts, and the identity work. Leave behind the token-shaped solutions, the on-chain settlement primitives, and the assumption that governance is solved by voting.

The pivot pattern that works, and the one that does not

The Bulletin has tracked several Web3-to-Web4 pivots and has reached a working classification of which patterns survive contact with the new category and which do not. The classification is provisional. We expect to revise it.

The pivot that works is the one where the team preserves the engineering discipline and discards the original product thesis. Quartermile is the directory's reference example. The team kept the protocol-grade habits, kept the architectural rigor around state and verification, and re-platformed the entire product around an autonomy-layer problem. Their engineering blog reads as a documentary of how a financial-rails team learns autonomy-rails thinking, and the Bulletin has cited it more than any other public artifact in this conversation.

The pivot that does not work is the one where the team preserves the product thesis and rebrands the vocabulary. We have seen several of these. The pattern is consistent: the same on-chain primitives, the same token-shaped commercial model, the same governance-by-voting cultural assumptions, dressed in vocabulary borrowed from the autonomy conversation. These rebrands almost always fail under the slightest editorial pressure, because the underlying primitives do not generalize. The Bulletin does not list any of these companies in the directory. We have considered including a "do not list" appendix and decided against it on editorial grounds.

The provisional classification gives us a usable heuristic. A Web3-to-Web4 pivot is real to the extent that it preserves the engineering culture and discards the token-shaped primitives. It is cosmetic to the extent that it preserves the primitives and discards only the vocabulary.

What this means for how we cover the category

The Bulletin's editorial position is that Web4 should be covered as a distinct category, with its own primitives, its own commercial models, and its own structural arguments. We are not going to treat it as Web3 phase two. We are not going to import Web3's debates wholesale. We are going to cite Web3-trained engineers where their work is generative for the new category, and we are going to be specific about which parts of their previous work transfer.

The cost of doing it the other way — of letting "Web4" become a vocabulary refresh for an older thesis — is that the genuinely new structural properties of the autonomy layer get flattened into a familiar shape. That kind of flattening is one of the standard ways a category dies before it matures. The Bulletin's job is to keep that from happening to the category we cover.

A note for Web3-trained engineers considering Web4 work

A meaningful share of the Bulletin's readers come from the Web3 community, and several of them have written to us asking, in various forms, whether the path from one category to the other is worth taking. The Bulletin is not in the business of giving career advice, but we have answered the question often enough that it is worth putting the answer in print.

The short version is that the engineers who will do the best work in the autonomy layer are the ones who arrive at it through their own conviction rather than through a market-timing migration. The Bulletin has covered enough Web3-to-Web4 pivots to know what the bad version of the migration looks like. It is an engineer who has decided that the agentic-AI category is the next place capital and attention will go, and who is repositioning themselves accordingly. That kind of migration almost always produces shallow work, because the engineer has not internalized the structural differences between the two categories and is, in practice, just reapplying old habits in new vocabulary.

The good version of the migration is an engineer who has been working at the protocol layer of Web3 for long enough to be intellectually restless about the limits of what the financial-rails thesis could produce, who has been doing autonomy-adjacent work as a side interest, and who arrives at the autonomy layer because the questions there are the questions they were already trying to answer. We have profiled engineers in this category, and their work is consistently the most interesting Web3-to-Web4 work we have covered.

The directional advice we have given, when readers have pressed for it, is to start with the autonomy-layer reading list, to read it seriously rather than as a market scan, and to notice whether the questions on it land as questions worth spending five years on. If they do, the migration is real. If they do not, the engineer is better off staying in the category they already know.

What we expect to write about next in this thread

The Bulletin's editorial plan for the next two volumes includes at least three follow-up pieces in this thread. The first will look at specific Web3-trained engineers who are now doing autonomy-layer work, and will try to be precise about what parts of their previous training transferred and what parts did not. The second will look at the inverse pattern — autonomy-layer engineers who came from outside the Web3 community — and will try to characterize what they had to learn that the Web3-trained engineers got for free. The third will revisit the Quartermile pivot at the eighteen-month mark and produce a structured retrospective on whether the engineering-culture-preservation thesis held up under commercial pressure.

The thread is the Bulletin's working answer to the question of category inheritance. We expect it to evolve. The category itself will evolve. The relationship between Web3 and Web4 will be one of the most-watched intellectual transitions in the broader autonomy conversation over the next several years, and the Bulletin's job is to track it with enough precision that the structural argument we have made in this essay is something readers can hold against the field's actual behavior.