Build the moat, partner for the plumbing.

The number that retired "we build everything in-house"

For a decade, "we build it ourselves" was the default posture of any company that thought of itself as technical, and for most of that decade it was the right call — the differentiating software was the product, and owning it was the moat. The AI cycle quietly broke that reflex. The most-repeated production statistic of the last year is that programs run with a specialised partner cross to production at about twice the rate of programs built purely in-house, roughly two thirds versus one third. The exact split is argued about, as every headline number is, and the precise percentage matters less than the gap it describes, which nobody serious disputes: the team that tried to build the entire stack alone is the team most likely to still have a stalled pilot.

This is the same divide we wrote about from the other side in the pilot-to-production gap — most programs stall not on the model but on the three layers underneath it. The build-versus-partner number is simply that finding restated as a sourcing question: the teams that reach production are usually the ones who did not insist on discovering those three layers from scratch. So the interesting question is not "is partnering better" — the data already says it correlates with shipping — but "what exactly should be partnered, and what must stay yours". Get that wrong in either direction and you lose.

"Build it ourselves" and "outsource the whole thing" are the same mistake wearing different clothes. Both answer at the level of the program. The decision that ships answers at the level of the layer.

Why "outsource it" is the wrong lesson

The naïve reading of the doubling is "hand the program to a vendor and walk away". Companies that do this trade a stalled pilot for a worse outcome: a system that reaches production and then becomes a black box they cannot improve, cannot audit on their own terms, and cannot leave. They swapped the risk of never shipping for the risk of shipping something they do not own — and on a system that touches a control or a P&L line, the second risk is the one that compounds.

The reason a specialised partner correlates with production is worth stating precisely, because it is not "they have a better model". Everyone rents from the same handful of frontier providers, and the price of that inference keeps falling. What a good partner shows up with is the evaluation harness, the integration patterns, the failure library and the operating rituals already built — the exact scaffolding an internal team would otherwise spend 12 to 18 months discovering the hard way, usually after a first stalled attempt has burned its credibility with the board. The partner compresses the calendar. It does not, and should not, absorb the moat. Treating it as a way to avoid owning anything is how a sensible head-start turns into a decade of dependency.

The decision is layer by layer

The cleanest way to make this call is to stop arguing about the program and decompose the stack. A document AI system is not one thing you build or buy; it is a few layers with very different economics, and the right verb is different for each. The model layer is a commodity that gets cheaper and more interchangeable every quarter. The orchestration and evaluation layer is where production discipline lives — buyable as a platform, but the discipline has to be yours. The domain layer — your documents, your edge cases, your reviewers' corrections — is the only part a competitor cannot replicate by signing the same vendor, and it is the part you should never give away.

Read top to bottom, the table is also a warning about the two failure modes. The team that builds the top row out of engineering pride — standing up its own inference stack to save a margin it could have rented — burns months on a commodity. The team that outsources the bottom row — letting a vendor own the corrected flow because it was easier — gives away the only durable asset in the system. The programs that get this backwards lose twice: slow to ship and nothing to show for it that they own.

The moat moved, and most boards are guarding the old one

The reason this matters now is that the location of the moat changed under everyone's feet. In 2023 a credible answer to "what is defensible about your AI" was "we have a proprietary fine-tuned model". By 2026 that answer aged badly: inference prices collapsed, open-weight models reached near-parity on domain tasks, and a model edge that took a quarter to build evaporated in the next quarter's release. The durable moat moved down the stack — to the domain you understand, the proprietary data you accumulate, and the speed at which your system learns from being wrong in production.

That last one is the quiet centre of the whole argument. Every correction a reviewer makes — a field the system read wrong, a decision a human reversed, an exception that got reclassified — is a signal, and a system wired to learn from it gets measurably better without changing the model underneath. A competitor that signs into the same customer 6 months later starts that learning curve from zero and stays behind on it for as long as the curve keeps climbing. The defensible question stopped being "which model do you use" — a commodity answer with a 90-day shelf life — and became "how fast does your system learn our domain", which is defensible for years. A board still grading AI maturity by model choice or ML headcount is guarding a moat that already moved.

The model is the most interchangeable part of the stack and getting more so. The corrected flow is the least. A strategy that rents the first and owns the second is the one that compounds.

The clause that keeps a partnership from becoming lock-in

If partnering is the way to reach production faster, the obvious risk is that "faster to production" turns into "permanently dependent". The defence is not to avoid partnering; it is to write the partnership so that leaving is always possible, and to keep the moat-layer assets on your side of the contract from day one. The same discipline procurement now applies to frontier-provider due diligence applies to a platform partner, and the clauses are concrete:

• Data and correction portability — your documents, your ground-truth sets and the full history of reviewer corrections are exportable in an open format, on demand, at no penalty. If the corrected flow is the moat, the contract has to say the moat is yours.
• A real exit, not a theoretical one — a defined off-boarding window, a documented hand-back of configuration and schema, and no clause that makes the cost of leaving the thing that keeps you. An exit you cannot afford to use is not an exit.
• No prompt or schema lock-in — the way the system is configured against your documents is an artefact you can read and take with you, not a proprietary blob only the vendor can interpret.
• A minimum internal team that can operate it — partnering is not the same as having nobody who understands the system. Keep enough capability in-house to run, audit and, if needed, replace what the partner delivers. The partner accelerates your team; it should not be a substitute for having one.

None of these slows down the deal that should happen. They simply ensure the partnership stays a head-start rather than a leash — co-ownership of the learning curve, with the data flywheel governed as your asset rather than the vendor's. A partner confident in the value it adds signs these clauses without flinching; a partner that resists them is telling you where it intends the lock-in to be.

Who owns the customer's correction

The single most-skipped clause deserves its own paragraph, because it is where the moat is most often given away by accident. When a reviewer corrects an output, that correction has two lives: a personal one (this document, fixed) and a systemic one (the signal that improves every future document like it). A company that pays for outputs but never negotiates rights over the corrections is funding a flywheel it does not own — every fix it makes trains a system the vendor can carry to the next customer, including a competitor.

The governance that holds keeps the correction signal as the customer's asset, with clear separation between a personal correction and a systemic one, telemetry that captures the fix at the point it happens, and a contractual statement that the accumulated corrections belong to the tenant that produced them. This is the operational other half of an AI operating model that works: it is not enough to have a partner and a platform if the thing that makes the system better over time is leaking out the side. Own the correction, own the curve.

The four ways a partner program quietly goes wrong

Even teams that accept the layer-by-layer logic watch it fail in recognisable ways. Naming them is most of the defence:

• Building the commodity layer out of pride — the engineering team insists on standing up its own inference and model stack because building is what it does, and spends two quarters reproducing a rented capability that gets cheaper while they build it. The moat was never there; the calendar was the casualty.
• Outsourcing the moat for convenience — the domain data, the schema and the corrected flow end up owned by the vendor because that was the path of least resistance at signing. The system ships and the company has rented its own defensibility back from a third party.
• A partnership with no portability clause — everything works until the renewal, at which point the absence of a real exit is discovered as a price. The relationship was a head-start that was allowed to set into lock-in because nobody wrote the off-ramp while there was still leverage to write it.
• No internal team to operate what was delivered — the partner ships a working system into an organisation with nobody accountable for running it, so it drifts unwatched and the first real incident has no owner. Partnering removed the discovery cost, not the ownership cost — and the second was mistaken for the first.

The trade-off, stated honestly

There is a genuine tension here, and pretending otherwise is how the strategy gets oversold. Partnering buys speed and a higher probability of reaching production, and it costs some margin and some independence — a partner takes a cut, and a dependency you have to manage is a dependency. Building buys control and long-run margin, and it costs the 12-to-18-month calendar and the real chance of being in the one-third that never ships. Neither column is free; the honest framing is which cost you can afford given the window you are in.

For most companies in most document workflows, the window is the binding constraint. The competitor on the production learning curve is compounding an advantage every month, and a year and a half spent rebuilding rentable plumbing forfeits that window for a margin point that the falling price of inference is eroding anyway. So the default for the commodity and orchestration layers leans toward partner; the default for the domain and corrected-flow layers leans toward own. The exception is real and worth stating: a company whose document processing is its core product, at a scale where the rented margin is material, can rationally build deeper down the stack — but even then, only after it has shipped, and rarely at the model layer. Build the part that is the moat. Partner for the part that is the plumbing. The mistake is doing it the other way round.

What this means for the document layer

Document work is where this decision gets made most often and botched most expensively, because document tasks look buildable — an engineer can wire an extraction prototype in a week — and hide the production cost in exactly the layers that take 18 months to get right. The prototype reads an invoice; the part that decides whether it pays back is the evaluation harness, the integration to the ledger, the confidence routing and the corrected flow that learns. Three properties separate a document partner worth signing from one that becomes the lock-in you regret:

It accelerates the layers, it does not own your data. A document partner earns its place by handing you the evaluation harness, the extraction-to-decision orchestration and the failure library on day one — and by writing into the contract that your documents, your ground truth and your corrections remain yours, exportable, with a real exit. The head-start is the product; the lock-in is not.

The corrected flow trains your system, on your side of the line. Every low-confidence case a reviewer fixes should feed back as signal that improves your tenant's accuracy, governed as your asset — not pooled silently into a model that a competitor signs into next quarter. That is the data flywheel kept where it belongs.

An audit trail you can read without the vendor. A per-field audit trail — what was read, by which method, with what confidence, against which span of the source — is what lets you own the system in practice rather than on paper: hold a quality SLA, run a regression review that means something, and answer a regulator's "how do you know?" with a record rather than a request to the vendor.

Closing thought

The board conversation that ages well in 2026 is not "do we build or buy our AI". It is "which layer are we talking about". The model is rented and getting cheaper; the orchestration and evaluation are bought as discipline and configured as your own; the domain data and the corrected flow are the moat, and they stay yours under a contract that says so. A company that partners to reach production fast and keeps ownership of the learning curve gets the doubling without the dependency. A company that builds the commodity out of pride, or outsources the moat out of convenience, gets neither. The maturity metric that predicts which one you are is not the count of ML engineers on the org chart — it is how many flows reached production, and who owns the curve they are learning on.

At Cogneris we build the document layer to sit on the right side of every line in that table: the model stays a rented implementation detail the platform optimises against your numbers, the evaluation harness and the ReAct orchestration ship out of the box so you reach production in weeks rather than rebuilding them over quarters, and your documents, your ground truth, your per-field audit trail and every reviewer correction stay yours — exportable, governed as your asset, with a real exit in the contract. If you are weighing build against partner on a document workflow, talk to our team and bring the flow — we will help you draw the layer-by-layer line on your own documents, including the parts you should keep away from us.