Vendor lock-in is an architecture decision
What you keep when you walk away: weights, graph, traces, and the right to run them without us
What happens to us if this does not work out? The question arrives somewhere in the second or third conversation with a regulated enterprise, after the data residency questions and before pricing. We have heard it for as long as we have been selling to large companies, worded a hundred ways.
It deserves a better answer than it usually gets. Most vendors respond with reassurance. The buyer asking about lock-in is asking a contract question, and contract questions deserve a specification.
The reassurance also skips a step. Lock-in is not a clause your lawyers failed to strike. It is an architecture decision the vendor made years before you signed, and the paper you are redlining can only document it.
How the lock gets built
In the standard multi-tenant shape, your records flow to the vendor's cloud. Fine-tuning happens on the vendor's infrastructure. The model that gets smarter on your outcomes is an asset on the vendor's balance sheet. At termination you receive a data export: clean CSVs of records you already held in your own systems. Everything your usage created (the calibrated model and the learned pattern of what your top performers look like) stays behind, because it never lived anywhere else.
None of this requires bad intent. That is the default shape of SaaS economics, and it produces a lock as a byproduct. Which means the lock can be removed the same way it was installed: by design.
The exit specification
Our resolution was to write down, artifact by artifact, what a customer holds on the day the relationship ends. Procurement teams have asked for it often enough that writing it down stopped being optional. The full deployment model is documented at /architecture; the exit view of it looks like this.
The model weights. Nodes fine-tunes open-source foundation models inside the customer's VPC. The weights sit in the customer's cloud account, under the customer's keys, and the master agreement states they remain the customer's property at termination. Customer-owned weights is the load-bearing phrase in this entire specification. If a vendor cannot say it, everything below is decoration.
The graph. The context graph joins what the silos never shared: call transcripts in the CRM, performance data in the HRIS, candidate records in the ATS, and the rest of the ten to fifteen systems a Fortune 500 typically runs. It is built from your data and stored in your environment. You keep it because it never left.
The Decision Traces. Every score and every action carries a signed, queryable trace: what happened, where, why, what the reasoning was, what input any human gave. Traces write to storage you control. Years after an exit, when a regulator asks how a long-settled hiring decision was made, you answer from your own records without calling a vendor you no longer pay.
The embeddings. Derived data is where exit negotiations usually go to die: the vendor concedes the records and keeps every useful representation computed from them. Our embeddings live next to the records they were computed from, in your account, covered by the same ownership clause as the weights.
The runbooks. Ownership fails quietly when nobody on your side can operate the thing owned. The customer holds the operating documentation and the schema glossary that maps their systems' fields into the graph, current as of the last release.
The re-deployment rights. The contract grants the right to load the weights onto your own inference stack and serve them without Nodes software, under the open-source licenses of the foundation models they were tuned from. This is the item most often missing from vendor paper. A model you are not licensed to run is a souvenir.
The day after you walk
An exit list that only says what you keep is a brochure, so here are both directions, stated at design level.
What runs: the model serves scores the day after termination the same way it served them the day before, because inference never depended on anything outside your cloud. The graph and the traces stay queryable. There is no repatriation project.
What degrades: the loop. The thirteen agents that read across your systems and draft cross-system workflows with the cost of action and the cost of inaction attached are licensed software, and the license ends with the relationship. Fine-tuning stops, which freezes the model at its last calibration; how fast a frozen calibration decays depends on how fast your labor market moves. Connector maintenance stops, which lets schema drift accumulate: in our design a renamed field stops flowing rather than being guessed at, a choice that protects correctness and narrows coverage month by month until your team updates the glossary.
There is a planning consequence here that evaluation teams reach late. The right time to price the day after is during diligence, while you still have negotiating power and the vendor still wants the signature. Ask for the degradation schedule in writing, in the agreement itself, and treat a refusal to write it down as the answer to a different question.
A vendor who claims nothing degrades at exit is misdescribing either what you keep or what they were doing all along.
Seven questions for any vendor, including us
Procurement leads have lifted pieces of this list from our calls over the years, so the whole list might as well be printed. Ask every AI vendor in your evaluation. Ask us.
- Where do the fine-tuned weights physically live today, and whose cloud account pays for the compute that trains them?
- At termination, do we keep the weights? Show the clause in the master agreement, carrying the same force as the payment terms. A slide in a sales deck does not count.
- Do we hold the right to run inference on those weights without your software, and do the licenses of the underlying foundation models permit it?
- Has our data improved a model your other customers benefit from? If improvements pool, what crosses our boundary, how is PII removed and verified before it does, and who on our side reviews the export?
- What format are the decision logs in, where do they live, and can we query them after the contract ends?
- Write down what stops working on day one after termination and what degrades over the following year. A vendor with a ready answer has thought about your exit. A long pause means they have only planned for your renewal.
- Does the pricing model punish a shrinking footprint? Per-seat fees turn every evaluation of alternatives into a hostage negotiation. Ours is outcome-based at 2% of validated impact with no per-seat fee, so the bill follows the outcome wherever your headcount goes.
Our own answer to the fourth question, since it is the one with the most room for hand-waving: the model is fine-tuned inside your cloud and evaluated in shadow against the incumbent before promotion. Improvements pool by industry, insurance with insurance, banking with banking. What crosses the boundary is weights, after one agent layer strips PII, a second layer verifies the strip, and your team reviews the export. Everything is validated on synthetic data before it ships back as an upgrade.
This list has survived contact with a hard audience. The Fortune 500 insurance carrier we deployed at had rejected six AI hiring vendors in eighteen months before us, every one of them on architecture. Legal approved us in 17 days, and contract to production took 34. Part of why the review moved at that speed: the exit terms gave counsel nothing to fight over. The study behind that deployment covers four years of production data and 10,765 agents, and the methodology, including the trace logging those lawyers reviewed, is public: Decision Traces.
Two arguments that live elsewhere
The cost case for owning instead of renting, the five-year ledger of subscription fees set against an asset that appreciates, is already made in full in the hidden cost of renting AI models. This piece holds the contract end of the question; that one holds the ledger.
The sibling question is which improvements made during the relationship are yours to keep when you leave: the calibration learned from your outcomes, the Performance Genome extracted from your top performers. That chain is traced in intelligence compounds, data stays. The short version: anything derived from your data carries your data's ownership.
Where the exit right belongs
We do not open first meetings with any of this. The first meeting belongs to what the system does: it reads across every system of record, drafts the workflow, attaches the cost of action against the cost of inaction, and waits for a human to approve, edit, or decline. The exit specification surfaces later, in diligence, and it lands differently there. A vendor willing to specify your departure in contract language is a vendor confident you will stay.
Deployed in your cloud. You own the model. The intelligence stays if the relationship ends. The strongest answer to the vendor-lock-in objection is that there is no lock.
Saad Bin Shafiq is the founder of Nodes. Anchor pilot: Fortune 500 insurance carrier, four years of production data, 10,765 agents. Methodology: Decision Traces.