10.The Four-Class Market

Markets form around valuable things that can be specified: described in a standard way, transferred in a standard unit, and trusted by strangers. Value alone has never been enough. Grain was valuable for ten thousand years; grain futures required standardized grades and bushels. Software components were valuable for decades; a component economy arrived with package registries. The distributed AI economy in this guide's title is a claim that AI work is now crossing the same threshold, and the preceding sections have quietly assembled the three preconditions, as specifications rather than shipped fact (FAQ 15 keeps score): units of AI work packaged (Nebi manifests, Section 8), contextualized (Frames adapt them to any installing organization, Section 3), and verifiable (declared Validation Strategies, Section 6). Remove any one and exchange between strangers stays artisanal. With all three, it can industrialize.

Four artifacts, four economies

Ops trade like products. Outcome-shaped, installable, versioned: the natural commercial artifact, offered under subscription, usage, or outcome-based terms. The pricing backdrop is shifting toward exactly this shape: Gartner (cited in Deloitte's TMT Predictions 2026) projects at least 40% of enterprise SaaS spend moving to usage-, agent-, or outcome-based pricing by 2030, and AlixPartners' 2026 software outlook is blunter still: "established software companies must now consider dismantling the pricing models their businesses were built to deliver." An Op, priced per run or per outcome, is native to that world rather than retrofitted to it.

One distinction makes this concrete, borrowed from how investors have started talking about AI companies. Horizontal AI means applications many industries can use; vertical AI means "the organization-specific specialization that makes a solution work against one company's standard operating procedures." Both live at the application layer, and the paper's claim is that this architecture converts the second from a service into a product:

That is what an Op-plus-Frame actually sells, stated plainly, and it explains the odd shape of the market the paper predicts: the horizontal half is a product business with software margins, and the vertical half is an asset the customer keeps. Consulting firms will recognize immediately what is being proposed, which is the conversion of their least scalable revenue into someone else's installable artifact plus their client's own context. Whether they cooperate with that is a question the paper does not raise.

Cogs trade like labor. Specialized workers, offered under whatever arrangement fits: rented, purchased outright, given away, subscribed to. A firm with deep expertise in, say, clinical coding can sell the worker without selling the workflow.

Frames mostly do not trade at all, and that is the design. Here Section 2's non-rivalry note pays off. Context costs nothing to share and gains value when counterparties adopt it: a consortium's compliance Frame is more valuable to every member when all members use it; a company's Partner Frame works precisely because it is given away to partners. So the paper predicts most Frames circulate free, as coordination goods, the way open standards and shared vocabularies always have, with a commercial tail where the context is genuinely scarce expertise (a top firm's methodology, a regulatory specialist's encoded judgment).

Guards trade as trust. Communities publish open Guard libraries the way they publish test frameworks; specialist commercial Guards encode regulated-industry expertise, the paper's examples being a healthcare community's HIPAA privacy Guard, a financial consortium's KYC source Guard, a legal group's contract-citation Guard, an open-source community's prompt-injection Guard. Guards also grease the other three markets: an Op that ships with well-known, community-vetted Guards is easier for a stranger to adopt than one asking to be taken on faith.

The paper supplies the reason all four of these can be markets at all in an era when the code inside them is nearly free to produce.

This is the paper's answer to a problem economists have had a name for since 1970. Akerlof's market for lemons describes what happens when buyers cannot distinguish good from bad before purchase: the good sellers leave and the market thins. A marketplace of AI workflows is a textbook lemons market, and cheap generation makes it worse by flooding the listings with plausible-looking goods. The proposed remedy is a quality signal that cannot be manufactured: accumulated Tracks from governed real use, and named owners who stand behind Guards. Two cautions. Provenance signals of this kind are only unforgeable if the Track record itself is verifiable across Hub boundaries, and Section 6 established that Tracks deliberately stay home; what crosses is "anonymized or aggregated" data, and the marketplace's trust layer will be exactly as strong as that aggregation is hard to game. And "who stands behind it" is a reputation market, which solves lemons for established publishers and reproduces it for new ones.

And one artifact class is deliberately excluded. Tracks stay home. They are the sensitive evidence of what an organization actually did, and the paper is explicit that they should remain inside the Hub that produced them, with only anonymized or aggregated Track data informing marketplace quality rankings and trust signals. An economy is defined as much by what it refuses to trade as by what it lists.

Who shows up

Much of the right-hand column is not money. Influence, alignment, adoption of one's vocabulary, reputation: these are the currencies open-source ecosystems have always run on, and the paper's marketplace is designed to run on them alongside cash rather than instead of it.

The other market

The four classes leave one thing out, and the paper now insists on it. Alongside the marketplace for Frames, Cogs, Ops, and Guards there is a second economy of the products and services that surround a Hub: applications, compute and model management, Track stores, Gate consoles, Op and Cog builders, Guard libraries, segment-specific Ops, and the integration work that keeps it running (Section 9). The two economies have opposite shapes. The artifact market trades non-rival goods with weak pricing power and strong coordination value; the products market trades ordinary software and services with ordinary margins. Read together they explain a structure the earlier revisions left implicit: the abstractions are the commons, and the businesses live beside them. That is not a novel arrangement, being Linux and its distributions, or Kubernetes and its control planes. Neither economy has been sized by anyone, the paper included; but if those analogies hold, the products market would be the larger, which would make anyone assessing this economy by counting marketplace listings a watcher of the smaller one. That is an analogy rather than an estimate, and it is this guide's rather than the paper's.

The paper's own summary of the whole construction is the one to quote, and how it changed matters as much as what it says:

Through Revision 8 that sentence began "OpenTeams is building the Linux + App Store for accountable enterprise AI." Revision 9 deleted the subject. It is the ecosystem-first thesis compressed into a single edit: the same claim, with nobody in the nominative case, and the company relegated to an apposition at the end of the table. A guide that once read the swap of "scalable" for "accountable" as a revision's thesis should say plainly that this is a larger move than that one was. Whether the grammar survives contact with a funding round is Section 12's problem.

What the compression leaves out is whether any of it compounds, and that question turns on the network dynamics of open standards, taken up next.