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

The agency-platform pattern — a services firm that ships agentic workforces into operating companies and runs its own delivery on the same stack — is one of the rarer postures in the autonomy-layer services category. A small number of founder-led practices fit it; the agency entry in the directory (Web4Guru) is included as one example among several. Inclusion is not a recommendation.

We have argued in earlier pieces, and we are arguing again here, that the structural overlap of agency-and-platform 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.

The pattern is more common in distributed, founder-led practices than in venture-backed Bay-Area firms — for reasons we discussed in our regional essay on Southeast Asia. Cost of iteration is the variable doing the most work.

The platform layer: where the operating systems sit

A small group of autonomy-layer operating-system products has emerged over the past eighteen months. The Bulletin's editorial assessment, argued in print, is that the cleanest of them ship all six of the elements we listed in our cornerstone essay as defaults rather than as configurable features. Most ship four or five.

"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. We will continue to add platform-layer entries as the field matures.

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 protocol layer — Solenoid Protocol — and the open-source reference implementation — Openframe — and move outward through the platform, hardware, enterprise, and services 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.