Two attorneys found out this week. Here is how to make sure the answer is "nothing much" instead of "I don't know."
Nine upvotes. No drama. Just a person, posting this:
"A project that contained probably 100 plus chats disappeared today. I can see some chats when I search. I am so upset. Does anyone know what could have gone wrong? I didn't delete it."
Then an edit, which is worse: "It's not visible anywhere and there are projects I never created."
The only genuinely useful reply in that whole thread was a question, and it is the question this article answers. "Hopefully you export your data on a semi regular basis ?"
Here is the short answer. What happens to your work when an AI company changes its product depends entirely on one thing: whether the irreplaceable part of your setup lives in a file you control or in a feature somebody else can rename. Your models are rented and always were. Your accumulated context, your standing instructions, your client files, the hundred corrections you have made that the AI now gets right, those are the asset. Get them into plain portable files this week, keep the compute on somebody else's bill, and a Tuesday redesign becomes an inconvenience instead of a crisis.
Key Takeaways
- The container your AI work lives in is a product feature, and product features get renamed, replaced or removed on a schedule you do not control.
- Your accumulated instructions and corrections are the actual asset, and in most businesses they currently exist only inside a vendor's interface.
- Exports are frequently partial, so verifying that an export contains something usable matters as much as running it.
- Thirteen of twenty-nine AI product launches on a single day shipped no model at all and ran on the subscription the user already paid for, which tells you where the market thinks the durable layer sits.
- Owning your context is not the same as owning your compute, and the published arithmetic on buying hardware to escape this is unkind.
The Problem: You Built on a Primitive
The bigger version of that story came from an attorney, at 377 upvotes, and it is worth reading his description of what he had built because it is good practice, not bad.
"Max 20x subscriber here, and I'm an attorney. Projects was the reason I pay for Claude. It was simple: a folder for each case. Persistent files every chat could read, standing instructions, and a clean list of separate chats. One for the demand letter, one for discovery, one for a motion, all drawing on the same case file."
That is a well-designed system. He did what the product invited him to do, and he did it thoughtfully. Then he wrote the sentence: "The only thing this shares with Projects is the name."
A commenter reported the identical pattern elsewhere: "And replaced gems with Notebooks, apparently. Which is a confusing name since they have another product called NotebookLM that is a separate tool." Followed by the most human line of the week: "I just want a project :|"
I want to be fair about this, because the reflexive outrage is the least useful response available. The replacement may genuinely be more capable. The top comment in that thread conceded exactly that and then said the thing that actually matters: "I understand most of the proposed 'workarounds' in this thread and why they're better/more powerful, but I also think there's something to be said for not changing how your users fundamentally use your product every 6 months."
Another commenter named the business cost with uncomfortable precision: "Imagine that change hitting a team up against a deadline. The new software has a direct negative impact on them, and they internalize that against the company. Rightfully."
A better product that arrives on a Tuesday you did not pick is still a cost you did not budget. And here is the part I got wrong for a long time: I treated these events as vendor problems. They are not. They are architecture problems, and the architecture is mine.
The Evidence: The Market Has Already Picked a Side
One. Lock-in research is thinner than you would expect, and the honest version is useful. I went looking for peer-reviewed or survey data on switching costs specific to small businesses and found almost nothing. The one figure that surfaced came through a secondary blog citing Statista, that over 60 percent of enterprises worry about vendor lock-in risk, and I could not verify the original. An academic study of UK cloud migration covering both large corporations and SMEs found that data portability and interoperability concerns were the most discussed theme in relation to lock-in, but the available snippet gave no percentages.
So I am going to tell you plainly: the quantitative case here is weak, and most of what is written about lock-in is law-firm and vendor marketing. What is strong is the mechanism, which those same sources describe consistently and which matches what happened to those two attorneys.
Two. The mechanism is that exports are usually partial. This is the detail that catches people who thought they were covered. Most tools offer some export function, but the export often contains incomplete data or a format that is not readily usable elsewhere. The example used repeatedly in the literature is a CRM that will export contact details but not the full relationship history, custom fields, or automation rules. You can run a successful export and still lose the metadata, the relationships, the schema and the custom structure that made the thing valuable.
Translate that to your situation. Exporting your chat history is not the same as exporting your system. The chats are transcripts. The system was your standing instructions plus your reference files plus the structure you organized them in.
Three. Thirteen of twenty-nine AI launches on a single day shipped no model at all. This is the strongest signal I have seen all year about where the durable layer sits, and it came from reading a Product Hunt board rather than an analyst report. Those thirteen products are harnesses. They run on whichever AI subscription you already pay for. Two of them say so in the pitch as a feature rather than an apology. Rushilo, a video editor: "We ship no AI, so there are no credits: your subscription or key." Atticus, which drives a Mac by voice: "Simple asks run instantly with no AI, and the rest run on your own Claude plan."
Seven more launches on the same board led their pitch with local-first privacy as the first line rather than a compliance footnote. CodeCrab: "100% client-side, your code never leaves your machine." And a product called SuperLocalMemory exists specifically because people now run several agents from different vendors and need one context layer underneath that none of those vendors control.
Read all of that as a market telling you something. The model is becoming infrastructure, like bandwidth. The thing that is actually yours is the context.
Four. Practitioners outside the AI world arrived at the same conclusion from the marketing side. Dan Sanchez put the structural version in one line: "The old digital marketer primarily bought tools. The AI-driven marketer increasingly builds them." Molly Mahoney is circling it from the creator side, calling her version an "AI Soul System," an operating system that pulls conversations together across Claude and ChatGPT so good outputs can be found and reused. Different vocabularies, same instinct: the layer worth investing in is the one you carry between tools.
The Fix: Own the Context, Rent the Horsepower
Here is the reframe that made this manageable for me, and I arrived at it the slow way after rebuilding a workflow twice.
Separate your AI setup into two categories. Replaceable and mine.
Replaceable: the model, the interface, the specific product's organizational features, the chat history, the particular tool you happen to prefer this quarter. All of it will change, some of it will get much better, and none of it is worth defending.
Mine: the standing instructions that took eighteen months of corrections to get right. The client facts that stop you re-explaining the same background every session. The brand voice guidance. The pricing logic. The list of things the AI always gets wrong about your business that you now preemptively correct. The folder structure that lets you find anything in ten seconds.
Every hour you spend improving something in the first column is rented. Every hour in the second column compounds, and compounds across every tool you will ever use.
The practical test is one question: if this product disappeared tomorrow, could I be running at eighty percent in a different tool by Friday? If the answer is no, you have not been building an AI system. You have been furnishing someone else's house.
And now the overcorrection I want to head off, because every time I make this argument somebody decides the answer is to buy a server. Jeff J Hunter published the arithmetic yesterday, and he is the last person who can be accused of being anti-hardware since he discloses over 95,000 dollars of it and six DGX Spark clusters. A 128 GB Mac Studio at 5,099 dollars. Twenty-five to thirty-five dollars a month in electricity under continuous load. Nearly three years to break even against a 200 dollar monthly subscription. And the best local coding model that fits in that memory scoring 30.9 percent on Terminal Bench 2.0 against 53.9 percent for the hosted alternative. His verdict: "You're paying more upfront for weaker output." And the sentence every small team should read twice: "It's that you're turning yourself into a one-person IT department to save $20 a month in API costs."
Own your files. Rent the horsepower. Those are not in tension.
Practical Steps
1. Export this week, and verify the export. Whatever holds your real work, pull it down to a folder on a disk you own. Then open the export and check that it actually contains something usable, because partial exports are the norm rather than the exception. Put a recurring reminder on the calendar. The attorney with a hundred chats did not lose his work to a bad model. He lost it to not having a copy.
2. Move your standing instructions into a plain text file. Markdown or plain text, nothing proprietary. A file survives every interface change, works in every tool, and can be read by a human being. A "project" is a feature somebody can rename. This is the single highest-return move in the article and it takes under an hour.
3. Write reasons beside rules, not just rules. This is the refinement most people skip and it doubles the value of the file. "Never promise a ship date" covers ship dates. "Never promise a ship date, because a failed print restarts the job" also covers "can I have it by Friday?" and every variant you have not thought of. A rule covers the case you imagined. A reason covers the ones you did not.
4. Rebuild the structure in folders you own. If the vendor gave you a project per client and you liked it, build a folder per client. Inside each one: a facts file, an instructions file, and the source documents. Boring, portable, permanent. Then feed the folder into whatever session you are running.
5. Test portability for real, before you need it. Take your context file to a different AI tool and run the task that matters most. Compare the output. You will learn one of two things, and both are worth an hour: either you are genuinely portable, or you found out on a Wednesday of your choosing rather than a Tuesday of theirs.
6. Date-stamp your facts so staleness is visible. The most common complaint in the agent communities this week was an agent confidently applying a decision that changed weeks ago. One person described it exactly: "the retry budget was 3 and then became 8, but the agent still says 3." Put a last-reviewed date beside anything that changes, especially prices, offers, team and policies.
7. Put a quarterly review on the calendar. Twenty minutes, four times a year. What lives only in a vendor's interface, when did I last export, what changed under me, and do I still have a working alternative. The thing that caught those two attorneys out was not a bad vendor. It was a change on a date nobody picked.
Here is the prompt to start with. It follows the Perfect Prompt Framework 2.0.
[The Job]
Create the single portable context file my business would hand to any AI tool.
This is for: [YOUR BUSINESS], usable in any tool, by anyone on my team.
It matters because: this file is the asset, and everything else is rented.
[The Background]
Here is what you need to know: my business is [DESCRIBE], my customers are [DESCRIBE], my offers and prices are [LIST], my voice is [DESCRIBE], the facts an AI always gets wrong about me are [LIST THEM], and the things I never want said are [LIST THEM].
Do not use: anything I have not told you; mark any gap as a gap for me to fill.
[The Deliverable]
Return: one file under 1,200 words, organized into labelled sections I can edit independently, written so a new team member could also read it as an orientation document.
Optimize for: accuracy and reuse.
[The Questions]
Ask me any questions you have.
Frequently Asked Questions
How do I back up my AI chat history and project files?
Most providers offer a data export in account settings, usually producing a downloadable archive. Run it, then open it and confirm the contents are usable, because exports frequently omit custom fields, structure or relationships. Treat the export as a safety net for transcripts and treat your standing instructions and reference documents as separate files you maintain deliberately outside the tool.
What is vendor lock-in and does it apply to AI tools?
Lock-in is when the cost of switching providers is high enough that you stay by default. With AI tools the trap is rarely the model, which is increasingly interchangeable, and almost always the accumulated context: instructions, files, structure and integrations that exist in one product's format. Keeping that material in plain files is what converts switching from a project into an afternoon.
Should I keep my AI instructions in the tool or in a separate file?
Keep the authoritative version in a separate plain-text file you own, and paste or attach it into whichever tool you are using. In-tool instruction features are convenient and fine as a copy, but they are product features subject to redesign, and they do not travel. The file is the source of truth.
Does running AI locally solve the lock-in problem?
Partly, and at a cost most small businesses should decline. Local models remove the dependency on a hosted provider but introduce hardware expense, maintenance labour and a measurable capability gap, with published break-even analysis running close to three years. The better split is to own your context and your data handling policy while continuing to rent compute.
How often should I review my AI tool dependencies?
Quarterly is enough for most small businesses, and it should take under half an hour. Check what lives only inside a vendor interface, when you last ran and verified an export, what changed in your tools since the last review, and whether your backup tool still works for your most critical task.
The Close
Think about what you have actually built over the last eighteen months. Every time you told the AI no, that is wrong, do it this way, you added a line to something. That accumulation is why it finally sounds like you, finally knows your pricing, finally stops making the one mistake that used to drive you crazy.
That is not a chat history. That is institutional memory, and it is the most valuable thing in your AI setup by a wide margin.
Right now, for most people reading this, it lives in a container owned by a company that will redesign it on a schedule you have no input into, for reasons that are probably good, on a Tuesday you will not choose. The person who lost a hundred chats this week did not do anything stupid. They did what the product invited them to do, which is exactly what the attorney did, and exactly what I did.
So do the boring thing. Write it down in a file with your name on the folder. Rent the horsepower from whoever is cheapest and smartest this quarter, and let them fight over that. What you own is the context, and nobody can ship an update to your hard drive.
About the author
Jonathan Mast is the founder of White Beard Strategies, where he helps entrepreneurs build AI systems that outlive the tools they were built in. He created the Perfect Prompt Framework 2.0, speaks on practical AI adoption for small and mid-sized businesses, and serves a community of more than 100,000 entrepreneurs. He has rebuilt the same workflow after a vendor redesign more than once, which is why the first thing he tells anyone to do is export.
