The Four Moats: Defensibility in an Agentic Economy

If everyone has the models, where does the moat live? In four very specific places — and only one of them is the data.

"In every commoditization, the commoditizers think they have killed defensibility, and the winners quietly build new moats the commoditizers cannot see."

A note on terms. This piece builds on From SaaS to SaaC and The Anatomy of a Capability. In short: a capability is a unit of software an AI agent can hire, described by a manifest and implemented by a kernel behind guardrails. Every call it serves leaves a signed receipt. Its OLA, the operational-level agreement declared in the manifest, is what each call is measured against. The registry is where agents find capabilities to hire.

The commoditization fear

The argument I hear most often against the agentic economy — and I hear it from capable, thoughtful engineers and executives who have followed the move from software as a service to software as a capability — is that it commoditizes everything. The logic is plausible. If every capability is a manifest, a surface, a kernel, and a guardrail; if every capability is discoverable through an open registry; if every capability is priced transparently and measured continuously; if every capability can be substituted at the next call by a competitor offering the same signature at a lower price; then no capability has a moat, no publisher has defensibility, and the entire economy collapses into a race-to-the-bottom commodity market in which only the lowest-margin operator survives. This, the argument concludes, is a terrible future for software vendors, investors, and employees; the SaaS-era economics, with their locked-in customers and their multi-year contracts and their defensible pricing power, were better.

The argument is wrong, but it is wrong in a specific way that deserves a careful answer rather than a dismissal. The commoditization fear is wrong because it mistakes substitution at the signature level for substitution at the value level. Two capabilities that implement claim.triage are substitutable only if the caller considers their OLA histories, their receipt provenance, their registry reputation, and their cross-industry routing to be equivalent. In practice, those four properties differentiate capabilities more sharply than pricing ever did in the SaaS era, and they differentiate along dimensions that are genuinely hard to commodify. The agentic economy does not abolish defensibility; it shifts it from switch-cost moats (the SaaS-era default) to trust moats (the agentic-era default), and trust moats compound while switch-cost moats erode.

There are four such moats, and they operate independently but reinforce each other when stacked. The rest of this article walks each in turn, then addresses what a moat is not in the agentic economy, and closes with a two-year simulation comparing a capability that stacked the moats against one that did not. The four moats are rendered together in the diagram.

Moat 1 — OLA history

A capability's OLA history is the signed record of every call it has ever served against its published commitments. For a young capability — two weeks in the registry, a few thousand receipts — the OLA history is thin; a single anomalous period can swing the aggregate statistics by several percentage points, and callers reasoning against the numbers are, correctly, cautious. For a mature capability — two years in the registry, tens or hundreds of millions of receipts — the OLA history is thick; aggregate statistics are stable, edge-case behaviour is well-characterized, and the capability's actual performance envelope is known to a degree the publisher's marketing could never communicate on its own.

A capability with two years of validated OLA history is not the same product as a capability with two weeks of OLA history, even if the two publish identical manifests. The first has been tested against adversarial inputs, edge-case inputs, long-tail inputs, and the specific weirdness of real production traffic from multiple caller contexts. It has been forced to respond to policy changes, to model upgrades, to infrastructure incidents, and to regulatory inquiries. Every one of those episodes left a trace in the receipt stream. A caller reasoning against the two-year history knows how the capability behaves not just in the happy path but in the dozen failure modes that have actually occurred. A caller reasoning against the two-week history has a manifest's worth of claims and little else.

This is the first moat, and it is durable because it cannot be manufactured. A two-year history takes two years to produce. A competitor who enters the market with a superior kernel but no history will be ranked below a mature incumbent even if the incumbent's kernel is slightly worse, because the OLA evaluator gives weight to sample size and recency. Over time, the competitor can close the gap — by attracting callers who are willing to accept the thinner history for the better kernel, by accumulating its own history, by eventually matching or surpassing the incumbent's thickness. But the gap is a real barrier, measured in calendar time that the competitor must spend in the market to overcome. That time is the moat.

The moat is also self-reinforcing. A capability with a thick OLA history attracts more callers; more callers produce more receipts; more receipts thicken the history further; a thicker history attracts more callers. This is the classic flywheel shape, which SaaS-era vendors also enjoyed but less durably — SaaS flywheels turned on seat growth, which could be reversed by a competitor's better pitch or a buyer's budget cut; OLA flywheels turn on receipt volume, which is anchored in the contractual reality of callers who have chosen the capability for its measured behaviour.

Moat 2 — Receipt provenance

Receipt provenance is the depth and character of the trust-chain attached to a capability's receipts. A capability whose receipts have been accepted as audit evidence by one regulator — say, the European Data Protection Board, in a GDPR inquiry — has an implicit endorsement that a capability whose receipts have never been tested does not. A capability whose receipts have cleared audits in five regulated sectors — banking, insurance, healthcare, telecoms, government — has a provenance that no new entrant can match in a single-sector launch. Receipt provenance is, in effect, the capability's regulatory résumé, and it is assembled one audit at a time, over calendar years.

Why does this matter commercially? Because the callers who pay the highest prices for capabilities — banks, insurers, health systems, government agencies — will not hire a capability without provenance. They cannot. Their own compliance officers, their own auditors, their own risk committees require evidence that the capability has been used successfully in analogous contexts, that its receipts have been queried and verified, that its policy-decision traces have held up under adversarial examination. A capability without provenance, no matter how good its kernel or how cheap its price, is not a candidate for these callers. A capability with provenance is; and these callers pay considerably more than unregulated callers, because their value at stake per call is far higher.

Receipt provenance is also path-dependent. It accumulates in a specific sequence — a capability that serves a regulated sector early, produces receipts that survive that sector's scrutiny, and then extends into adjacent sectors carrying the prior provenance, has a different trajectory than a capability that chases the largest unregulated market first and tries to enter regulated sectors later. The first trajectory compounds; the second hits a wall. The same pattern is familiar from regulated software generally: a product trusted in one demanding sector finds the next one easier to enter, and that trust is earned over years, not quarters.

There is a subtler point here worth naming. Provenance is transferable across callers within a trust regime, but non-transferable across trust regimes. A capability with extensive provenance in the EU data-protection regime has, for a US-based caller operating under state-level AI regulations, a reduced but non-zero asset — the receipts are not automatically accepted but they lower the caller's due-diligence burden. A capability with provenance in a specific sector's regime (FDA-equivalent, for instance) has high value to callers in that sector and approximately zero value to callers outside it. Publishers of capabilities should be explicit about which provenance trees they are cultivating; the economic return on each provenance tree is different, and the costs are incurred sector by sector. The strategic choice of which regulatory frontier to clear first is one of the most important decisions a capability publisher makes, and it is a decision the SaaS era did not force vendors to make so explicitly.

Moat 3 — Registry reputation

The third moat is registry reputation — the capability's rank, endorsements, and social proof within the registry. This is the Yelp-effect for capabilities, but with signed receipts replacing subjective star ratings, and with structured endorsements replacing unstructured reviews. A capability's rank in the registry is a function of three things: call volume (how often it has been hired), satisfaction (how often callers have continued using it after the first call, as measured by repeat-hire rates), and longevity (how long it has been in the registry and how stable its behaviour has been over that time).

Registry reputation matters because discovery is the first step of HIRE, and the registry's ranking is what callers see first. A capability ranked third for its signature is discovered by every caller searching for that signature; a capability ranked fourteenth is effectively invisible unless a caller specifically seeks it out. The difference between third and fourteenth is, in commercial terms, an order of magnitude in potential call volume. And the rank is not static — it is updated on every receipt, every caller decision, every period of observed performance. A capability can rise in rank by performing well against competitors; it can fall in rank by underperforming or by failing to accumulate new callers.

The Yelp analogy is useful and also limited. Yelp's ratings are gameable — fake reviews, review bombing, paid endorsements — and the gaming is a chronic problem. Registry reputation is far harder to game because the inputs are signed. A fake receipt would require forging a signing key and fooling the registry's validation chain; the cryptographic cost is prohibitive for all but state-level adversaries, and any successful forgery would be detected when the receipt was cross-referenced against the capability's own telemetry. The ranking is, in this sense, audit-resistant. It cannot be bought; it cannot be fabricated; it can only be earned through actual calls, actual satisfaction, and actual longevity.

This is the third moat, and it operates at the market-visibility level rather than at the individual-caller level. OLA history and receipt provenance matter to the caller reasoning about hiring decisions. Registry reputation matters to whether the caller ever considers the capability at all. A capability with great OLA history but poor registry reputation — because it is new, because its discoverability metadata is weak, because its manifest does not describe itself clearly enough — will struggle to break through. A capability with moderate OLA history but excellent registry reputation — because it was published early, because its manifest is exemplary, because its accumulated calls span many caller types — will continue to attract new hires even when competitors with better kernels emerge. Registry reputation is the top of the funnel; the other moats operate further down.

Moat 4 — Cross-industry routing

The fourth moat is the most strategic and the slowest to build. A capability that has served callers in multiple industries — banking, insurance, healthcare, logistics, telecoms, manufacturing, government — has accumulated polysemantic edge-case knowledge that a single-industry competitor has not. The knowledge is literal: the capability's OLA history contains receipts from each sector's distinctive failure modes, its regulatory peculiarities, its data distributions, its adversarial patterns. Over time, the capability's kernel is refined against all of these, and its guardrails are hardened against the union of all of their threat models. A cross-industry capability is, in effect, a capability that has had many more distinct training signals than its single-industry counterpart — not training signals in the narrow ML sense, but behavioural signals that inform which manifests are accurate, which kernels generalize, and which guardrails matter.

The commercial value of cross-industry routing is visible in pricing power. A capability that has demonstrated competence in banking and healthcare simultaneously can charge more than a capability that has demonstrated competence in only one of them, because the buyer in either sector is gaining implicit assurance that the capability can handle the rigour of the other. A healthcare buyer hiring a capability with banking provenance knows the capability has survived PCI-DSS audits and SOX-equivalent scrutiny; the fact that the current hire is for a HIPAA-adjacent use case is reassuring precisely because the capability has already cleared a different, equally stringent bar. This is why cross-industry routing compounds: each new sector the capability serves adds a multiplicative factor to its attractiveness in the others.

The barrier to cross-industry routing is non-trivial. Each industry has its own regulatory regime, its own data-residency requirements, its own sector-specific schema conventions, and its own risk-committee culture. A capability designed narrowly for one sector — tightly coupled to that sector's schemas, optimized for that sector's OLA profile, certified against that sector's regulatory frame — cannot be trivially redeployed into another sector. The architectural discipline required to build a cross-industry capability from day one — manifest-first, schema-agnostic, multi-region, multi-regulatory-regime — is real engineering cost, paid upfront, in exchange for optionality that pays off years later. This is why the cross-industry moat is slow: it is the product of a strategic choice made at capability design time, honoured through years of engineering discipline, and realized only after the capability has accumulated the sector-by-sector provenance to prove the generalization works.

What a moat is NOT

A moat, in the agentic economy, is explicitly not a switch-cost mechanism. In the SaaS era, vendors built moats by making it painful to leave: proprietary data formats, multi-year contracts with punitive exit clauses, deep integrations that took quarters to unwind, training investments that could not be transferred to a competitor. These switch-cost moats worked; they produced the high-retention, high-gross-margin economics that SaaS investors came to love. They are incompatible with the agentic economy, and any capability publisher who attempts to reproduce them will find their capability rapidly marginalized.

Specifically, a moat in the agentic economy is not:

Lock-in. A caller who hired a capability today should be able to release it at the next call boundary and re-hire a competitor without penalty. A capability that punishes release — by holding caller data hostage, by making the hire-token non-transferable across receipts, by requiring exit-fee negotiations — will be flagged by the registry's policy engine and demoted. Callers route around locked-in capabilities. Competitors exploit the friction. The switch-cost moat, if it could be imposed at all, would cost the publisher more in registry reputation than it would gain in retained callers.

Proprietary protocol. A capability that exposes itself only through a vendor-specific protocol, rather than MCP or its successors, excludes itself from the open registry ecosystem. It may build a niche business with callers willing to tolerate the proprietary surface, but it will not participate in the cross-industry routing moat, and its registry reputation will be capped by the narrowness of its caller base. The open-MCP era punishes protocol isolation; it rewards interoperability.

Hiding the manifest. A capability whose manifest is incomplete, obscured, or missing — whose semantics are described only in marketing prose and whose actual behaviour must be discovered by trial and error — cannot be reasoned about by agent callers. Agents cannot hire what they cannot parse. The publisher who believes the manifest is a competitive vulnerability — that revealing too much lets competitors copy the capability — has misunderstood where the value lives. The value is not in the manifest (which describes what the capability does); the value is in the kernel (which does it), the OLA history (which proves it), the provenance (which trusts it), and the cross-industry reach (which generalizes it). Hiding the manifest hurts all four moats; it helps none of them.

The general principle is that the agentic economy rewards transparency and penalizes opacity. This is the opposite of the SaaS-era intuition, which rewarded opacity (proprietary formats, hidden roadmaps, locked-in customers) and penalized transparency (open standards, portable data, easy exits). The economic physics has inverted. A publisher that has internalized this inversion designs differently from a publisher who has not, and the difference shows up in registry ranking within the first two or three quarters of operation.

How each moat compounds

The four moats are not independent; they interact, and the interaction compounds. OLA history feeds receipt provenance (a thicker history means more receipts available for audit). Receipt provenance feeds registry reputation (a capability that has cleared regulatory scrutiny ranks higher in the registry's trust weightings). Registry reputation feeds cross-industry routing (a top-ranked capability is more likely to be discovered by callers in adjacent sectors). Cross-industry routing feeds OLA history (a broader caller base produces more diverse receipts). The four moats are a cycle, and the cycle accelerates.

Consider a two-year simulation comparing two capabilities, X and Y, with identical day-one kernels. X is built with the four moats in mind — manifest-first, receipt-archived, multi-sector-ready, transparency-biased. Y is built with a SaaS-era mindset — proprietary features, hidden manifest, single-sector launch, switch-cost-reliant. Both publish in month zero. Both start with zero receipts and zero reputation.

By month three, X has attracted a small pilot base in its primary sector; Y has attracted a similar pilot base. X's receipt archive is growing; Y's is growing too, but only in its single sector. Month six: X has opened a second sector (the multi-region, manifest-first architecture made the expansion straightforward); Y is still single-sector. X's registry reputation ticks up as cross-sector receipts accumulate; Y's registry reputation is flat. Month twelve: X has three sectors active, a twelve-month OLA history in its first sector, and a growing provenance tree; Y has one sector, a strong OLA history in that sector, and a reputation capped by its narrow caller base. Month eighteen: the regulatory frontier arrives. A major regulator in X's first sector audits both capabilities. X's receipt archive answers the audit in a day; Y's receipt archive answers too, because Y also used signed receipts (this is not the SaaS era), but Y's sector concentration makes it a single-point-of-failure in the regulator's risk model. X receives a clean audit opinion; Y receives a caveat. Month twenty-four: X is the default candidate for new callers in all three sectors; Y is the default only in its one sector and is considered a niche specialist in the others. The kernels are still identical. The moat differential is entirely downstream of architectural and strategic choices made at day zero.

The simulation is stylized, but the dynamics are real. I have watched versions of it play out in narrower SaaS-to-SaaC transitions. The capabilities that were designed for cross-industry routing from day one — even when, at day one, there was only one industry to serve — are the capabilities that, by month twenty-four, had accumulated moats that their more narrowly-scoped competitors could not close. The design choice precedes the compounding. The compounding is downstream of the discipline.

Synthesis

The commoditization fear is wrong because it mistakes signature-level substitutability for value-level substitutability. Four moats structure defensibility in the agentic economy: OLA history, receipt provenance, registry reputation, and cross-industry routing. Each compounds individually; the four together compound multiplicatively. The moats are trust moats, not switch-cost moats, which means they reward transparency rather than opacity. A capability publisher who has internalized this inversion designs architecturally differently from one who has not, and the difference shows up in measurable commercial outcomes within the first two years. The question is not whether defensibility exists in the agentic economy; it is whether publishers are willing to build the slower, more disciplined defensibility the new economy requires. There is a regulatory side to all of this, because receipts are not just commercial artefacts; they are evidence, and evidence has legal weight.

Designing capabilities that can earn these four moats is the architecture work behind our software architecture and AI engineering practice.

---

← Back to The Software Lens library