The next AI outage may look like a passport check

Last week, Anthropic disabled Fable 5 and Mythos 5 for all customers after a US export-control directive targeted access by foreign nationals.

Not because the models had become worse.

Access rules changed.

That is the part worth paying attention to.

If your agent system depends on one proprietary model for everything, you do not fully control the system.

You may control the prompts, the application, and where you store your own data. You do not control the provider, its access rules, retention policy, availability, or the next operational decision made several floors above your pay grade.

That does not make proprietary models bad.

It means they should be used deliberately.

The wrong first question

Most people still start with:

Which model is smartest?

Useful question. Wrong starting point.

The better one is:

Which model deserves to see this context?

Some work needs the strongest available reasoning model. Use it.

Some work only needs classification, routing, redaction, summarization, or a simple check. Some work should run locally. Some should receive only a cleaned summary. Some should not touch an LLM at all, because deterministic code can do the job without developing opinions.

If every task goes to the biggest proprietary model by default, that is not architecture.

That is a shortcut.

Shortcuts are harmless until the work becomes important. Then they become risk.

A region flag does not solve privacy

The obvious response is to use EU models, EU providers, and EU data storage.

Those can be valid requirements.

They are not the whole design.

Privacy is not solved by a region flag or a hosting checkbox. The practical questions come first:

• What context is being sent?
• Does the model need the full input?
• Can sensitive parts be removed or summarized first?
• What does the provider retain?
• What happens when that model is unavailable tomorrow?

The model itself may also change the privacy equation. Fable 5 and Mythos 5, for example, required 30-day API data retention and were unavailable under zero-data-retention arrangements.

So “use the best model” is not a neutral decision.

Capability, location, retention, access, and fallback all belong in the same routing decision.

Not every task deserves the same model. Not every model deserves the same context.

The platform is only part of the answer

There are several ways to solve this class of problem: orchestration frameworks, custom routers, workflow engines, or plain deterministic code.

OpenClaw and the deterministic control layer, internally called Core, are how we solve it for Clawblins.

OpenClaw gives the crew roles, tools, memory, continuity, and places to work. Core is deterministic code underneath the crew that validates inputs, enforces boundaries, records decisions, controls access, and checks whether the next step is allowed.

But the tools alone are not the architecture.

The configuration is the architecture.

Which role sees which context. Which task may use which model. What must be removed first. What can run locally. What needs approval. What happens when a provider disappears. What must never depend on a model response.

That is where reliability and privacy are actually designed.

Agents are good at language.

Language is not a safety system.

The model may reason, draft, summarize, or suggest.

Core does not improvise.

The useful order

For me, the order is becoming clear:

Task first. Minimum context second. Requirements third. Guardrails fourth. Model last.

The task determines what must be done.

Minimum context determines what the task actually needs to see.

Requirements cover privacy, region, retention, cost, latency, and availability.

Guardrails decide what is allowed before and after the model responds.

Only then should the system choose a model.

Frost does not need the same context as Vox. Vox does not need the same context as Senior. A public reply does not need the same context as private system recovery. A routing task does not need the same model as a difficult reasoning problem.

This is how I want AI agents to work: not as one giant brain in the cloud, but as a crew with different roles, different routes, and deterministic checks underneath.

You cannot control the provider

The next AI disruption may not look like an outage.

It may look like a model disappearing, an access rule changing, a retention policy becoming unacceptable, or one feature vanishing from the workflow that depended on it.

You cannot control all of that.

You can control your architecture.

So before asking which model is smartest, ask the question that matters first:

Which model deserves to see this context?

Privacy and resilience start with the same decision.

Continue

Architecture ReviewSee the relevant package →A real day with Clawblins, my AI crewRead a related article →Bring me the problemTell me what your team needs to decide →