Build the Platform, Not the Harness: Decoupling AI from the Vendor Who Rents It to You
A harness like Copilot bundles interface, orchestration and tokens, then rents all three back by the seat. A platform owns the first two and buys the third as a commodity — which is why it can run at roughly a tenth of the cost, and why changing model supplier becomes a procurement decision instead of a migration.
Every enterprise AI conversation I have eventually becomes a shopping conversation: which assistant, which copilot, which seat licence. It is the wrong conversation, and it is wrong in a specific way. The product being shopped for is a harness — one vendor's bundle of an interface your people learn, an orchestration layer that decides what the model sees and does, and the tokens themselves — rented back to you by the seat, per month, forever.
There is a different shape available, and it is the one I would argue for in any boardroom: build the platform, and let the harness be one of its interchangeable parts.
The three layers a harness bundles
Strip any enterprise AI assistant down and you find the same three layers:
- Experience — the interface, the channels, the habits. Where your people actually meet the AI: chat, documents, the tools they already live in.
- Orchestration — routing, retrieval, guardrails, agents, evals, audit. The layer that decides which model sees what, what it may touch, and whether its answer was any good.
- Tokens — raw model output, generated by somebody's GPU, priced per million and falling in price roughly every quarter.
A harness sells you all three as one SKU. That is genuinely convenient, and for a pilot it is often the right answer. But notice what the bundle does to you over time. Your people's habits form around the vendor's interface. Your organisation's knowledge — prompts, agents, evals, guardrails — accumulates inside the vendor's orchestration. And your bill is denominated in seats: a fixed rent on headcount, entirely disconnected from how much value, or even usage, sits underneath it. Each layer quietly raises the cost of leaving, until "we could switch" becomes a sentence nobody says in a planning meeting.
A platform inverts the ownership. The experience is yours, shaped around your work rather than a vendor's roadmap. The orchestration is yours, and it is where the compounding value lives — every agent your people build, every eval, every guardrail is an asset on your balance sheet of capability. And tokens become what they actually are: a commodity input, sourced.
Tokens are a supply chain, not a subscription
The moment tokens are a separate layer, they become a procurement problem — and procurement problems have levers that subscriptions do not.
- Route by task, not by loyalty. Frontier models for the heavy lifts — ambiguous, high-stakes, long-context work. Cheaper hosted models for volume. Free tiers and local models on hardware you already own for the long tail of drafting, classifying and summarising. I run exactly this hybrid on my own agent-built side projects, and measured it in the local-model benchmarks: the bottleneck is almost never raw generation speed, so most tasks are dramatically over-served by a flagship model.
- Cache like you mean it. A large fraction of enterprise prompts share most of their context. Prompt caching turns that repetition from a per-seat inevitability into a discount you engineer.
- Re-source on price, weekly if you like. Model prices fall and free tiers appear constantly. On a platform, taking advantage is a routing change. Inside a harness, it is a contract renegotiation.
- Measure cost per completed task. Not per seat, not per token — per resolved ticket, per drafted document, per answered question. It is the only unit a CFO and an engineer both understand, and it exposes the seat model's dirtiest secret: you pay in full for everyone who never logs in.
Where "a tenth of the cost" comes from
The arithmetic is not heroic; it is structural. Illustrative numbers, at workforce scale:
| | Per-seat harness | Decoupled platform | |---|---|---| | Unit of billing | Every employee, every month (~$20–30/seat typical) | Tokens actually consumed + modest fixed infrastructure | | 5,000-person annual bill | ~$1.2–1.8M in licences alone | Roughly a tenth of that, all-in | | Effect of a model price cut | Wait for the vendor's next pricing page | Change a routing rule | | Effect of a better model launching | Join the waitlist | Add an endpoint, run your evals, shift traffic | | What you own at the end | Familiarity with someone else's UI | The experience, the agents, the evals, the data paths |
Two forces do the work. First, seat billing charges for potential usage across the whole headcount; token billing charges for actual usage, which in every deployment I have seen concentrates heavily in a fraction of the workforce and a fraction of their day. Second, a platform's infrastructure cost scales sub-linearly while a licence bill scales exactly linearly — every hire is another seat, but they are not another platform. Put those together and a running cost around 10% of the equivalent harness bill is not an optimisation triumph. It is what falls out of refusing to rent the top two layers. (In our own case the platform serves a five-figure workforce for about the licence cost of a few hundred seats — I will leave the product itself there; this post is about the shape, not the case study.)
The principles, stated plainly
- Own the layer your users learn. Interfaces create habits, and habits are the real switching cost. If a vendor owns the glass, they own your change programme.
- Orchestration is the asset; treat it like one. Routing, guardrails in code rather than in prompts, evals on every model change, audit by default. This layer is also where safety actually lives — a model you can swap is a model whose failure you can route around.
- Buy tokens like electricity. Multiple suppliers, spot capacity where it exists (free and local tiers), no emotional attachment to a model name. Your supplier list should read like a panel, not a marriage.
- Placement is a decision, revisited. Exactly the rule from multi-cloud: the question is never "which vendor do you like?" but "where does this workload belong, this quarter, at this price?" Models are now workloads.
- Prove replaceability by replacing. Rotate a non-critical workload to a different model family at least quarterly. If the exercise is painful, you have found the coupling you didn't know you had — while it is still cheap to fix.
- Keep the harness — as a tenant. None of this forbids Copilot or its peers. Inside a platform they become one more routed destination, excellent for the commodity tasks they are built for, adopted and dropped on merit. The error is not using a harness. The error is letting the harness be the architecture.
When the harness wins anyway
Honesty section, because there are two real cases. If you are small, or piloting for a quarter, the bundle's convenience beats building anything — a platform has a fixed cost of seriousness that needs scale to amortise. And for genuinely commodity work inside the vendor's own suite, the integrated harness will usually be better integrated than anything you build; let it. The platform argument is about where your differentiation and your cost curve live, not about refusing good tools.
But if AI is going to be load-bearing — thousands of people, agents acting on real systems, a bill the CFO asks about — then the question to bring to the board is not which harness. It is whether you intend to own the two layers that compound, and rent only the one that commoditises. Build the platform. Let harnesses compete to sit on it.