A frontier model can vanish in four days. If your core work depends on one provider, that is a risk you are quietly carrying.
Don’t Build Your Business on a Borrowed Brain
Why using one AI provider as both the model and the system around it is now your biggest hidden risk
Author: David Brain
The day a model vanished
Earlier this month, Anthropic launched Fable 5 on a Tuesday and was forced to switch it off the following Friday. Four days from launch to being switched off. These things happen all the time, but this one is particularly interesting because it was switched off by a US government directive for everyone with no restoration date. If you had wired a core process to that model, your stack did not break. It was turned off, on a timeline you did not choose.
It would be easy to file this under geopolitics and move on. The useful reading is simpler and more uncomfortable. There are two things in any AI deployment, and leaders routinely collapse them into one. There is the model, the large language model itself, the raw intelligence. And there is the harness, the system you build around it, the workflow wrapper that tells the AI what to do, that turns that intelligence into reliable, repeatable, accountable work. When you let a single provider be both, when Claude, ChatGPT or Gemini is simultaneously the brain and the entire body of how a core process runs, you have made one thing you do not control load-bearing for work you cannot afford to lose.
That is the risk. Not that any one model is bad. They are remarkable. The risk is structural: you have, in essence, outsourced how the work gets done without the control, the SLAs, or the accountability you would demand from any other supplier. You have built your business on a brain you are only borrowing, and the lender can turn it off at any time.
It would be comforting to assume regulation will eventually make this safe. The evidence suggests otherwise. The clearest analysis of why points to the same conclusion from the other direction: binding global rules for this technology are not coming, so the rules that actually affect you get written unpredictably, in different places, at different speeds. Which means the only control you genuinely hold is the one you build yourself. This is an architecture problem, and architecture is the one part of it you own.
What the show taught us
We have circled this across the first season of The magentIQ Show. Three conversations in particular cut straight to it. Here is what each one tells you about keeping the off-switch in your own hands.
Episode 2, David Brain: your business logic is not where you think it is
Early in the season, my co-founder Ian Barkin and I dug into why so many AI deployments stall. Our conversation kept landing in the same place: the obstacle is rarely the model’s intelligence. It is that the model gets dropped into a process nobody has fully written down. As I put it, organizations understand their business roles, “but that knowledge tends to be within the heads of the operators still, and very rarely in the documentation that is available to these forward deployed operators and engineers.”
That matters the moment you build directly inside one provider’s environment, because the undocumented logic, the prompts, the configuration, the particular way you have coaxed one model into doing the work, becomes the only place your process actually lives. You have rented a system rather than built one, and left the instruction manual inside it. The harness is the answer: your process logic, data and workflow captured in something you control, versioned and portable, so the model is a component you slot in rather than the filing cabinet for how your business runs.
Episode 7, Andreas Welsch: nobody is buying your model choice
A few episodes later, Ian sat down with Andreas Welsch, a well-known AI advisor and author, for a conversation about giving teams access to AI tools and the training to use them well. Andreas put the commercial reality plainly: “Nobody will care if you used AI to crank out information in minutes instead of days, but they will judge you by the quality of that information and of that work product.”
That single observation dismantles the case for single-provider dependency. Your customers do not care which model sits behind your service. They care whether the work is right and whether it keeps arriving. The frontier model is not the prize you are protecting. It is one interchangeable input into an outcome you are accountable for. Organize your business around owning a particular model and you have optimized for the wrong asset, one whose availability is now a political variable. Organize it around owning the outcome, and the model becomes exactly what it should be: swappable, the moment you need it to be.
Episode 8, David Brain: build it so you can switch it out
In our most recent founder discussion, Ian and I got into how teams actually adopt these tools, the idea that you prototype and tinker inside something like a chatbot or an artifact, but you do not run your enterprise through it. The fix is not to fear the tools or wait for someone to regulate them safely. It is to build past them. As I put it, “you’ve got to take it out of those tools. You’ve got to build it into a model which is more robust, more end-to-end. You’re gonna then have the ability to switch in and out models or deploy your own in the future.” And the future is more varied than one giant model doing everything: “I think we’re gonna start seeing the growth of the small language model. You don’t need the one that’s detecting which invoice is which to also have the killer cupcake recipe.”
That is the whole thesis in two moves. Decouple the harness from any single model, so the system is yours, and the model is a part. Match the model to the task rather than forcing one frontier provider to carry your entire operation. Do both, and a directive, an outage, a price rise, or a better option launching next Tuesday stops being an existential event and becomes a configuration change.
The risk that creeps up on you
There is a second, quieter version of this risk, and it is the one that creeps up on you. As AI agents move into the tools where teams actually work, Claude Tag in Slack, and a fast-growing field of rivals doing the same across Slack and Teams, they stop being something you query and start being something that remembers. The longer one works alongside your team, the more it quietly becomes a map of how your work actually happens: where the real checklist lives, who reviews what, which convention nobody ever wrote down. That accumulated context is enormously useful, and that is exactly the problem. Losing an all-knowing coworker is hard. Losing the ability to control the workflow underneath it is harder. If that institutional memory lives inside one provider’s product, you have not just rented the intelligence, you have handed over the operating memory of your business, and you cannot take it with you when you leave.
Get the blueprint
If you want the full blueprint for this, we have written it down. Our Executive’s Guide to the Multi-Agent Workforce sets out why organizations need AI, why AI needs people, and how to build an operating model where the system is yours, and the model is a swappable part. It is the practical version of everything above: governance, handoffs, and a step-by-step path from fragmented pilots to a workforce that performs in live operations.
Building AI the right way
You do not need to take a side in anyone’s regulatory or political fight. You need to treat access to a frontier model as what it has become: a variable you do not control, behaving on your risk register like currency exposure or key-person risk. Three moves follow.
First, separate the harness from the model. Keep your process logic, your data, your workflow, and the working memory of how your team operates in something you own, so the provider is a replaceable component rather than the foundation you stand on. The most valuable instructions belong in your own runbooks and repositories, not locked inside a vendor’s product. Second, keep a tested fallback ready, people who can do the work, not just more technology, because the cheapest, best and most available model will keep changing, and a portable architecture turns that churn into good news instead of a crisis. Third, match the model to the task. Not every job needs the largest frontier system, and a spread of fit-for-purpose models is harder to hold hostage than a single point of dependency.
AI plus people is the only architecture that holds up under real-world complexity, and the technology should be a suite of best-in-class tools you can swap as the field evolves, never a single brain you have borrowed and quietly made indispensable, handed to a provider you do not control and who carries no accountability for your outcomes.
Related content
What Cognitive Offloading Is, and How to Keep Your Team Sharp While Using AI
Cognitive offloading is the delegation of mental work to something outside your own head, and generative AI extends it from arithmetic and directions to analysis and judgment. What the research establishes, what it does not, and five practices that keep your team sharp.
WHITEPAPER: Designing the modern Accounting Firm with Agentic AI
Preparing your firm for the shift to an agentic operating model.
WHITEPAPER: The Map Before The Machine
How mapping the work before choosing the technology enables leaders to build an agentic operating model that delivers measurable returns.
Why Teams Stop Trusting AI: 5 Ways to Earn It Back
McKinsey found that 80% of respondents report personal productivity gains from AI, while 37% can point to any EBIT impact. Part of that distance is trust. Five patterns that break a team’s confidence in AI at work, and the design decision that rebuilds each one.