Jump to another pillar
VAO · pillar 05 · partners and the moat
Five kinds of partner — the systems you connect to, the integrators who deploy, the platforms that hold the data, the model providers, and the infrastructure underneath.
Part one
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.
Planning, procurement, the system of record.
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.
The shop floor, and the data on what actually happened rather than what was planned.
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 two
A single enterprise can build a graph of itself. It cannot build a library learned across an industry — its build is permanently capped at its own experience.
Connectors break when the source system upgrades. Models get deprecated. Every change means re-running the tests. The decision is not whether to build it — it is whether to fund a permanent team to keep it running, forever, for one company.
Before a system acts on its own, you need a record of it being right — what it predicted, what actually happened, and how often the two matched. That record takes years to accumulate. An internal build starts with none of it and no method for gathering it, so it stays stuck recommending rather than acting.
A build for one site encodes that site's assumptions. For a group choosing between one site and a dozen, this is decisive.
Each of these is also why a partner is necessary: the volume, the maintenance, the calibration and the multi-site reach are all things a single vendor cannot reach alone.