Jump to another pillar
VAO · pillar 05 · partners and the moat
Not the function that sells more. The function that determines whether the moats in every other pillar ever become real.
Part one
| The asset | At low volume | At high volume |
|---|---|---|
| Taught strategy library | A consultancy's playbook | A product nobody replicates without spending the same decade |
| Connector catalogue | A handful of integrations | A procurement artifact, and a barrier to entry |
| Evaluation and calibration framework | An internal QA process | The category's evaluation standard |
| Resolution history — what actually happened, and how it was resolved | Anecdotes and a folder of old emails | The only real answer to how will this supplier actually behave, and the record every agent is measured against |
A vertical SaaS company cannot reach that volume alone, and the deal size will not fund an engineering organisation large enough to try.
Part two
The delivery engine, and the weakest seam. They carry the deployment volume the vendor cannot staff — while learning the method closely enough to consider running it themselves.
Delivery capacity, account access into estates it does not reach, and connector contribution back into the catalogue.
Services revenue, a differentiated offer in a crowded market, and a certification that is worth something because not everyone has it.
Partner and existential threat simultaneously. They own the system of record and the procurement relationship, and their own agent layer is arriving from above.
Distribution, procurement credibility, and reach into planning-layer accounts it would otherwise approach cold.
An execution capability at the shop floor that their planning layer does not have and would take years to build.
Partner at the data layer, competitor at the ontology layer. They hold the execution data — and increasingly want to extend their own model upward into decision territory.
Reach into the execution layer, where the suite vendors cannot go and where the behavioural signal actually originates.
An agentic decision layer sitting above their execution data, without having to build judgement they have no way to elicit.
Transactional by design, and that is the correct posture rather than a failure to build a relationship. No provider should be load-bearing.
Frontier capability where it helps, and sovereign open-weight options where a mandate requires them. Nothing that depends on one provider staying available.
Volume, and an industrial reference in a segment where enterprise proof points are scarce.
The stack the product runs on: orchestration, observability, the gateway, evaluation, the connector protocol. The most under-managed category, because it is treated as procurement rather than partnership.
The infrastructure it would otherwise build and maintain itself — plus influence over roadmaps it depends on, which only comes from being visibly present upstream.
An industrial reference, upstream contribution, and hard requirements from a demanding deployment — which is worth more to an infrastructure project than licence revenue.
One asymmetry worth noticing across all five. In four of them the vendor is buying volume or reach. In the fifth it is buying dependency — and the argument that makes that acceptable is the same one the product makes to its own customers: no single supplier is load-bearing, second sources exist, and the layer that sits on top is thin enough to move.
Part three
A large industrial group runs the deployment for two years alongside its favoured integrator. The integrator has built the connectors, mapped the routines, run the discovery and operated the rollout. The customer owns their populated graph. Their internal digital organisation has thousands of engineers and a standing sovereignty mandate.
“We understand this now. Let’s build it ourselves.”
Four arguments that will not survive contact with a competent internal team
- It is technically hard. They have thousands of engineers and can hire more.
- Our IP is protected. The schema is licensed; they can write their own. Nothing stops an enterprise building an internal tool.
- They lack the AI talent. A large industrial group hires machine-learning engineers as easily as a scale-up does.
- Contractual restrictions. Unenforceable against an enterprise building for internal use, and attempting it poisons the relationship.
State these to yourself once, and never in a customer meeting.
Five that hold, ranked
A single enterprise can build a graph of itself. It cannot build a library of taught situation types learned across an entire industry. Its build is permanently capped at its own experience: its own archetypes, its own supplier base, its own doctrine, its own mistakes.
The only defence that gets stronger every year rather than weaker — which makes library enrichment not merely a moat mechanism but the build-versus-buy defence itself. Without a compounding library the vendor is selling a platform, and against a platform this is a fair fight the larger balance sheet eventually wins.
An internal team builds version one and then discovers what they actually signed up for. Connectors break when the source system upgrades. Models get deprecated, or made unavailable by export control. The connector protocol changes. Evaluation suites must re-run on every model, prompt, tool-description and connector change. Calibration must be monitored continuously or delegated authority has to be withdrawn.
The vendor already knows this number, which is what makes the argument land: you are not deciding whether to build version one. You are deciding whether to fund a permanent platform team, forever, for one company's benefit.
Delegated authority requires measured predicted-versus-realised calibration, per situation type and per confidence band. An internal build starts at zero on day one — exactly as the vendor did — but without the verification loop, the evaluation harness, the synthetic environments or the methodology for accumulating it.
The practical consequence: their version one is stuck for a long time at the rung where the system recommends but cannot be trusted to act — the rung where the value is thinnest. They will not have anticipated that, because it is not obvious until you try.
An internal team staffs data scientists and builds an optimiser. The genuinely scarce discipline is the person who can sit with a practitioner and decompose their judgement into explicit, contradictory strategies plus a selector — a rare skill, teachable but not obvious, and one an internal team will not know it needs.
This is also why an internal build converges on the thing that looks most like engineering: a solver with a single objective function. Which fails for the same reason it always fails — a configured objective is not the effective objective.
An internally built system encodes the site it was built for. A vendor's schema is archetype-parameterised because it has had to work across different production models, different industries and different countries. A build for one site encodes that site's assumptions and breaks at the next one, or at the supplier tier.
For a group choosing between building for one site and deploying across a dozen, this is the decisive argument — and the one most often left unmade, because making it requires knowing the customer's site topology.
Where build genuinely wins — say so out loudA single site, low product complexity, a homogeneous stack, a strong internal team, no multi-site ambition, and no interest in doctrine beyond their own. That customer should build, or should buy something simpler.
Conceding the cases where the answer is build is what makes the other cases credible. A vendor who claims every customer should buy is a vendor whose analysis nobody trusts — and the concession costs almost nothing, because that account was never going to be a good one.
Aligning the integrator, rather than trusting them
Arguments win a meeting; these change the odds. Sell the library, not the platform — if the product is a platform, build-versus-buy is a fair fight; if it is accumulated judgement across an industry, it is not. Make the run cost visible during the sale, not as a threat but as a shared planning input: a customer who has seen the number and buys anyway has pre-answered the objection. Price multi-site expansion below the cost of building for site two, which makes the fifth argument concrete rather than rhetorical. And publish the benchmark, so the customer has a public yardstick to measure their internal build against — internal builds rarely survive that comparison, and offering the yardstick is a confident move.
The one that matters most is the integrator. Certification has to beat the build alternative economically — recurring run revenue, protected territory, a genuine co-sell motion. A certification that is only a badge will lose to a build engagement every time.
Four signals, in rough order of appearance
Questions shift from how do we use this to how does this work. Requests for schema documentation beyond anything deployment requires.
The integrator staffs architects rather than deployers and their questions turn architectural.
An internal programme appears with overlapping scope and a different sponsor.
Renewal conversations start referencing internal capability and the library enrichment terms get queried.
The decision is usually taken six to twelve months before it is announced. The response to the first two signals is not defensiveness — it is moving the conversation to the run cost and the multi-site trap early, while it is still a planning discussion rather than a decision being defended.