Rent the Model. Own the System.
The best AI model will keep changing. Your company should not lose its memory, rules, or ability to operate every time it does.
Every AI demo makes the model look like the asset.
In real work, the expensive part is everything the company has to teach it: where the data lives, what the rules mean, what is already in motion, when a person has to approve, and how anyone knows the job is done.
A better model can help. I am not pretending models are interchangeable. But the model is still an input the company buys. Pricing changes. Rules change. Product surfaces change. The workflow should survive when that input changes.
If your company gets amnesia every time it does, you did not build a system. You rented one.
The valuable part is everything around the model
Think about a capable new employee joining your company. Their raw intelligence matters. It is not enough.
They still need to know how you qualify a lead, what a good customer looks like, which promises sales is allowed to make, what happened with the last shipment, where a case gets escalated, what "done" means, and which mistake the company already paid to learn from.
AI is the same. The model brings general capability. Your system makes that capability useful inside your business.
That system is:
- the source data the work depends on;
- the context that explains what the data means;
- the workflow definition that says what happens next;
- the rules and permissions that constrain action;
- the current state of work already in motion;
- the verification that proves the result is acceptable;
- the feedback that makes the next run less wrong.
Those pieces are where your organization is learning. They are also where most of the actual work is.
The model can draft a customer reply. Your system knows that this customer already received a replacement, that the order came through a marketplace with a different refund policy, that anything over $500 needs approval, and that the reply is not done until the case is updated and the shipment is confirmed.
The model can score a lead. Your system knows which attributes predicted a real sale, which territories belong to which person, why the team rejected three apparently perfect accounts last month, and whether the handoff produced revenue or just a prettier CRM.
The model can read an invoice. Your system knows the approval thresholds, the recurring exceptions, the vendor history, the purchase order, and how to prove the payment record matches the accounting record.
That knowledge should not live only inside one vendor's chat history or one employee's habit of prompting it correctly.
Your chat history will not run the business
A lot of what gets sold as AI memory is really convenience. It remembers a preference. It can continue a conversation. It may retrieve an old file. Useful. Not the same thing as an owned operating record.
Organizational memory needs to survive the conversation.
It needs explicit facts, dates, owners, sources, decisions, exceptions, and current status. It needs to distinguish a rule from a suggestion and a completed action from somebody saying they completed it. It needs to be usable by another employee, another automation, and another model without reconstructing six months of conversation archaeology.
A PDF export of old chats is not a system. Neither is a giant prompt nobody understands anymore.
If the AI flags that your largest customer may use a special return window, verify it against the contract or an owner before it enters the customer record. If an automation misclassifies distributors, confirm the pattern before the correction becomes a test or a rule. If a person approves an exception, the reason should travel with the decision. The next run should inherit confirmed learning without inheriting the entire mess that produced it.
This is the same basic lesson we learned at Go2 from years of measuring and coaching work. Observation by itself was never the product. The value came from turning real work into evidence, evidence into feedback, and feedback into a better process. The person, manager, or customer could change. The record still had to make the next decision better.
AI does not repeal that rule. It makes the rule more important because the machine can move faster than the organization's ability to notice what it is doing.
The Friday portability test
Here is the cleanest test I know.
Imagine your primary AI vendor disappears on Friday. Not forever. Just long enough that you have to move the workflow to another capable model on Monday.
Do not ask whether the new model will produce the exact same sentences. It won't, and that is not the point. Ask whether the business can preserve the job.
Can the replacement model:
- Reach the source data in a useful, documented format?
- Read the current rules without mining old chat threads?
- See what work is open, finished, failed, or waiting for approval?
- Use the tools the workflow depends on through replaceable connections?
- Apply the same permissions and escalation boundaries?
- Run against the same examples and pass-fail checks?
- Produce a receipt showing what it did and why?
- Feed corrections back into a record the next run can use?
Do not average those answers into one reassuring score. Five are gates: source data, current rules, work state and history, permissions and escalation, and pass-fail verification. If any of those is trapped, the workflow is trapped.
The other three tell you how painful the move will be. Replaceable tool connections reduce rewiring. Receipts reduce guesswork. A portable feedback record preserves the learning. Missing one may not stop the move, but it tells you what you will have to rebuild.
Fail one gate and you are not switching a model on Monday. You are rebuilding part of a company process from memory. Fail three and you are rebuilding the company process.
Run the same test at a smaller scale before you buy anything important. Pick one actual workflow and ask the vendor to show you the exit, not just the demo. Can you export the records with their relationships intact? Are instructions and evaluation cases available outside the product? Can your team see the current state without asking the vendor's assistant to summarize itself? Can you keep a canonical copy of outcomes in the system where the work already lives?
"We have an export" is not a complete answer. A pile of flattened text may satisfy a checkbox while destroying the structure that made the data useful. Portability means another system can understand the record, not merely that you can download it.
What ownership looks like in a normal business
Take a customer asking for a second replacement on a marketplace order.
The rented version looks great in a demo. A model reads the message, drafts a friendly answer, and maybe even issues a refund. Over time, agents correct its mistakes inside the vendor's interface. Six months later, nobody can say whether the model learned the actual policy, copied one good rep, or simply got better at sounding certain. The vendor's model, feedback history, action layer, and state are one box. Leaving means starting over.
The owned version can still use that vendor's model. It can even use the vendor's interface. But the order and prior replacement live in the commerce or customer system. The marketplace policy has a source and effective date. Refund limits and approval boundaries live in a readable rule. A small set of ugly cases shows what an accepted resolution looks like. The action and evidence are logged, and a confirmed correction updates the rule or test outside the model.
Now another capable model can pick up the case. It may write a different sentence. It still sees that one replacement already went out, the order is inside the special marketplace window, refunds above the threshold need approval, and the case is not done until the customer record and transaction agree.
The same pattern works in accounts payable. Let the model read the invoice. Keep the vendor history, purchase order, approval rule, exception, and payment receipt in systems the company can inspect. The intelligence is rented. The evidence and decision stay put.
The point is not to turn a small business into an infrastructure company. It is to keep the business knowledge on the business side of the line.
Use open formats where they help. Keep canonical data in systems you control. Write down the repeated logic. Separate model instructions from source facts. Put verification outside the same black box that takes the action. Log enough to reconstruct what happened. Design one safe human stop for the cases the system should not decide.
That is not glamorous. It is also the part that compounds.
I have separate guides on the building blocks shared across AI platforms and on building a closed-loop automation. This is the ownership question underneath both: after the tools are connected and the workflow runs, who keeps the learning?
Portability is not purity
There is a stupid version of this advice where every company decides it needs to self-host a model, rebuild its own database, and reject any useful managed product because dependence is bad.
Do not do that.
Rent aggressively at the commodity layer. Rent compute. Rent frontier intelligence. Rent transcription, hosting, search, and specialized software when the economics make sense. A well-run platform-native workflow may be the right answer when your team already lives in that platform, the process is low-risk, and the cost of leaving is smaller than the cost of pretending to be a software company.
Some capabilities really are vendor-specific. If one model is uniquely good at a job, use it. Just do not bury the job's rules, state, and proof inside that capability if the job matters to the business.
Some workflows are too small or temporary to deserve portability work. If an AI writes a one-time event description, use the best tool and move on. Ownership has a carrying cost. Pay it where the process is repeated, regulated, revenue-bearing, customer-facing, or full of knowledge you cannot afford to relearn.
There are also legitimate cases where compliance, data residency, or a long enterprise contract makes a single ecosystem the safest practical choice. Fine. Vendor concentration—lock-in, if you want the ugly word—can be a conscious risk decision. It should not be an accidental result of nobody asking where the memory went.
And if you actually train or own model weights, the math changes at the model layer. You still need the rest of the system. A model without current data, operating rules, state, verification, and feedback is a smart employee locked outside the building.
Own the layer where your company gets smarter
The next generation of AI products will be better than the current one. That is good news if your system is ready to use them.
When your context, data, workflows, rules, state, tests, and feedback are yours, every model improvement becomes a possible upgrade instead of a migration crisis. You can plug in a stronger reasoner, a cheaper classifier, or a better tool user and let it work against the same accumulated understanding of your company.
When those things belong to the vendor, every model improvement comes with a negotiation. Maybe the price goes up. Maybe the feature moves tiers. Maybe the vendor decides your workflow is no longer part of the roadmap. Maybe you simply find a better model and discover the switching cost is not the model at all. It is everything you accidentally taught the old one in private.
That is not an anti-vendor position. Let model companies compete to provide better intelligence. Keep the source data, rules, work state, approvals, tests, and feedback where your business can inspect and move them.
If changing the model means relearning the process, the switching cost was never the model. It was the operating knowledge you failed to keep.