When the model changes, does the company keep learning?

A post from Jon W. on LinkedIn captured something a lot of engineering teams are starting to feel.

His team has been using Claude Code heavily for six months. Real usage. Daily workflows. Several thousand dollars a month across the team.

Then, for a day, things broke.

Models started behaving worse. Usage limits were hit much faster than normal. Anthropic had issues. Jon tried Codex as a fallback, paid for the $70 plan, and hit the cap after about 15 minutes.

His takeaway was simple: if you are redesigning your organization around AI workflows, you need to know what happens when the dependency breaks.

He is right.

The comments were almost more interesting than the post. People were not really arguing about whether the dependency is real. They were arguing about the response.

Run multiple providers. Use OpenRouter. Self-host open models. Standardize hooks and skills. Treat AI vendors like critical infrastructure. Build local fallback. Move more of the stack in-house.

That is the signal.

The answer is not going to be one model. It is going to be many models, many harnesses, many coding tools, and more local infrastructure over time.

I think that is right.

But it also creates a second problem that most teams have not really dealt with yet.

Continuity.

Most of the conversation around AI dependency is focused on model access:

What if Claude is down? What if OpenAI changes limits? What if costs double? What if Cursor or Windsurf changes pricing? What if we need to run Qwen, Kimi, DeepSeek, Llama or something local?

Those are real questions. They matter.

But they are mostly about where the next token comes from.

The deeper question is: what happens to everything the team already learned?

If your team moves from Claude Code to Codex, from Cursor to Windsurf, from a frontier model to a local model, what carries forward?

The fixes. The failed attempts. The repo-specific gotchas. The debugging paths. The architectural decisions. The corrections that only exist because someone learned them the hard way.

Today, most of that learning is trapped inside the tool where the work happened.

Claude may know what happened in Claude. Cursor may know what happened in Cursor. A local agent may know what happened in its own run.

But the organization still does not have a trusted place where that learning accumulates across tools.

That is the part people underestimate.

A fallback model helps you keep working. It does not automatically preserve what your team has learned.

And the problem is not always a clean outage.

Sometimes the model just gets worse.

A prompt cache changes. A limit moves. A workflow that worked yesterday starts burning tokens or producing sloppy output. The team feels it before the system measures it.

That is a very different operating problem.

If AI is becoming part of the production workflow, then "it felt dumber today" is not enough of an operating model. Teams will need evals, audit trails, fallback paths, governance, and memory that survives tool changes.

Self-hosting may be the right move for many teams. Multi-provider routing probably will be too. I would not bet against either.

But those are execution-layer answers.

They decide where the next model call goes.

They do not answer the memory question.

If the organization moves from Claude to Codex to Qwen to a local model, does the next agent inherit what the last one learned?

That is the missing layer.

Every app will have its own memory. That is inevitable. Claude, OpenAI, Cursor, Windsurf, GitHub and internal tools will all remember more over time.

But app-native memory is local state.

Companies need something closer to a system of record for what the organization learns: a neutral memory layer that survives across models, tools, agents, repos and workflows.

This matters most in coding-agent teams because the pain is already obvious.

Agents repeat mistakes. Developers reconstruct context. Brownfield codebases remain opaque. Migrations re-open solved problems. Tribal knowledge stays trapped in people's heads, Slack threads, PR comments and one-off sessions.

As AI work scales, this gets worse, not better.

More agents means more attempts. More tools means more fragmentation. More generated work means more chances to rediscover the same thing twice.

So yes, teams should think hard about vendor dependency, usage caps, cost spikes, local models and fallback infrastructure.

But the real question is bigger:

When the model changes, does the company keep learning?

The old version of the problem was: agents have no memory.

The sharper version is: AI work is not yet cumulative at the organizational level.

If a team spends six months learning how to use coding agents against its own codebase, that learning should not disappear because a provider has a bad day, a usage cap changes, or the team decides to move part of the workflow in-house.

The model is rented. The learning should be owned.

That is the real fallback plan.