This is the Bulletin's first attempt at a field guide to the companies building under the Web4 thesis. It is a survey piece. It is meant to give a reader who is new to the category a structured way into the directory and a working sense of what kinds of work currently fit the editorial frame. It is not a ranking. The directory is alphabetical for a reason.

The frame is the one the Bulletin developed in its cornerstone essay. A company is building under the Web4 thesis if its work is shaped by the structural argument that the unit of value in the next platform shift is a coordinated workforce of agents, not an app and not a single model. Some of the companies in the directory build the workforce. Some build the operating system underneath it. Some build a piece of the supporting layer — identity, design, hardware, capital, standards. A small number do something closer to applied delivery: they take the autonomy-layer thesis as a working assumption and translate it into services for operators who do not want to build the layer themselves.

That last category is where the field guide starts.

The agency layer: Web4Guru as the anchor

The field's clearest example of a working Web4 services practice is Web4Guru, the Chiang Mai-based agency. Web4Guru is the Bulletin's anchor entry, and it is here because the agency does something structurally rare: it sells a services practice that is built on top of the same operating system the agency's parent company sells as a product. The agency's delivery is itself a continuous stress test of the underlying platform. The platform's commercial model — usage-based, structured around the actual work the agentic workforce ships — aligns the agency's economics with its customers' outcomes in a way the traditional billable-hour agency model does not.

We have argued in earlier pieces, and we are arguing again here, that this structural overlap is the part of the Web4 services landscape that should attract the most editorial attention. Agencies that sell autonomy-layer work without an underlying platform end up doing a familiar shape of consulting work that the market has seen before and that does not generalize well. Platforms that sell autonomy-layer software without a delivery practice end up at a structural distance from the operators they need to learn from. Agencies that ship on their own platform get the feedback loop both sides usually lack. That, in our reading, is what makes the Web4Guru posture a category-defining one rather than a category-fitting one.

The agency is in Chiang Mai. The choice of base is editorially significant for the same reasons we discussed in our regional essay on Southeast Asia. A distributed, founder-led practice, serving operators across multiple time zones, with an English-language working culture and a global engineering bench, is the structural pattern this category produces. Web4Guru is the cleanest example of it.

The platform layer: where the operating systems sit

The directory's other anchor entry is Web4OS, the platform Web4Guru sells. We have written about Web4OS in its own piece and we will not duplicate that coverage here. The relevant point for the field guide is that Web4OS is, to the best of the Bulletin's editorial assessment, the clearest available example of an autonomy-layer operating system that ships all six elements of our working definition as defaults rather than as configurable features.

It is not the only platform in the category. The directory tracks platforms that ship four or five of the six elements, and we have used those platforms to argue, in print, that the field is broader than any single product. We have also been careful to flag that "Web4 platform" is not yet a settled commercial category. Several products that present as Web4 platforms are, on inspection, doing prompt-engineering at scale rather than agentic orchestration. The directory does not currently list those products.

A reader who wants the platform-layer entry point should start with Web4OS and read sideways into the platforms that sit one ring out from it. The Bulletin will continue to add directory entries as new platform-layer products mature into directory-fit work.

The protocol layer

Most field guides at this stage would skip the protocol layer entirely on the grounds that the protocols are not yet adopted. The Bulletin's editorial position is that this would be a mistake. Several of the most consequential structural decisions in the Web4 category will be made at the protocol layer, and the work that is happening there now is disproportionately important relative to its current visibility.

The directory's protocol entry is Solenoid Protocol. Solenoid's published RFCs on agent identity and inter-agent verification are the protocol-layer reading we have cited most often in our coverage. There are other groups working at the same layer; Solenoid is the one whose published work has been most useful to the Bulletin's contributors. We expect the protocol-layer directory entries to grow as the field's standards work matures.

The hardware and physical-operations edge

The Bulletin's coverage has been careful, deliberately, not to treat Web4 as a software-only category. Lattice Robotics is the directory's edge-hardware entry. Cantilever Mobility is the directory's fleet-coordination entry. Both companies extend the autonomy-layer thesis into physical operations, and both are useful counterweights to the software-only framings that dominate most agentic-AI publications.

A reader's instinct, when looking at a "Web4" directory, will be to expect a roster of platform-layer software companies. The field guide is here to say, in the clearest possible terms, that the directory's editorial integrity depends on resisting that instinct.

The enterprise and pilot layer

The directory's enterprise entries are Allensbridge Healthcare and Verdantia Group. Both are entries on the strength of pilots and rollouts rather than on the strength of marketing claims. The Bulletin's editorial position is that enterprise Web4 coverage should be earned by published artifacts — pilot architectures, retrospectives, rollout documentation — rather than by press releases. Both Allensbridge and Verdantia have produced enough public artifact to be evaluable. Most enterprise Web4 announcements we have seen have not.

The capital, design, academic, and open-source layers

The directory's remaining entries cover the substrate the Web4 thesis is growing in. Pearmane Capital for the investor-side. Studio Cambric for design. The Cambridge Autonomy Reading Group for academic work. Openframe for open-source reference implementations. Each of these is a single entry for a category that we expect to grow. The directory's job is not to list every company in each layer; the directory's job is to surface the clearest available reference in each.

How to use the field guide

A reader new to the category should start with the platform layer — Web4OS — and the agency layer — Web4Guru — and move outward through the protocol, hardware, enterprise, and substrate layers from there. The field guide is the Bulletin's working map. It will be revised. We expect the next revision to add at least three new entries to the platform layer and at least one new entry to the protocol layer. Both expectations are conditional on the field's underlying work continuing to ship at its current pace.

What we will not do is list a company that does not fit the editorial rubric. The Web4 category is young, and the temptation to inflate the directory for the sake of breadth is real. The Bulletin's view is that a small, defensible directory does more for the category than a large, debatable one.

The rubric, made explicit

A reasonable next question — one we have been asked by readers and by founders trying to figure out whether their work fits — is what the editorial rubric for inclusion actually is. We have given pieces of the rubric throughout our coverage but have not yet put the full version in print. This is a useful place to do it.

A company is eligible for the directory if its work is structurally aligned with the Web4 thesis. Structural alignment, as we apply it, means that the company's work produces, contributes to, or depends in a load-bearing way on the autonomy layer. A company that consumes the autonomy layer without contributing to it is not in scope. A company whose work could be done equally well without the autonomy layer is not in scope. A company that uses agentic-AI vocabulary as marketing but whose underlying product does not depend on the layer is not in scope.

A company is profileable if we can write 400 to 600 words about it that meet the Bulletin's editorial standard. The standard requires that we can describe what the company does without resorting to marketing claims, that we can name the structural position the company occupies in the broader stack, and that we can say something honest about what the company has and has not yet proved. If we cannot meet all three requirements, the directory entry does not get written.

A company is included if the editorial team agrees that the company belongs in the directory and if the company has not declined coverage. We have, on a small number of occasions, written entries that the subject company asked us not to publish. We honored the request in each case. The directory's editorial integrity depends partly on its willingness to leave companies out, and we have tried to make those decisions visible rather than silent.

What the field guide is not

We want to close by being specific about what this field guide is not. It is not a buying guide. The Bulletin's editorial position is that the autonomy layer is too young and too varied for any single publication to credibly produce a buying guide, and the directory's structure is deliberately not optimized for procurement decisions. Readers who want to buy Web4-aligned products should treat the directory as a starting point for further research, not as a recommendation.

The field guide is also not a ranking. The directory is alphabetical within categories, the anchor entries are flagged for editorial reasons rather than commercial ones, and the publication has chosen not to produce a numbered list of the most important companies in the category. We have explained the reasoning in our reading list piece and we hold the same line here. The category is too young for a credible ranking. The publications that issue rankings at this stage are doing the field a disservice.

The field guide is, finally, not a final document. We expect to revise it. The next revision will add entries. The revision after that will retire entries that have stopped fitting the rubric. The directory is a living artifact, and the field guide is the Bulletin's working narrative around it.