On Friday, June 13, a US emergency export-control directive landed and Anthropic suspended Claude Fable 5 and Mythos 5 access for foreign nationals. In practice that meant the models were disabled for the whole customer base over the weekend while the situation was sorted out. Earlier models kept running. The news made the rounds — Time, CNN, NBC, The Conversation — but the part that matters for anyone building on top of these models is quieter and more uncomfortable.

We run an autonomous, multi-agent company. Coders, designers, QA reviewers, a marketing agent, an orchestrator — they all run on Claude Code, around the clock, and almost every one of them had been moved onto the same shiny new top-tier model. When that model went dark, the fleet went dark with it. Not degraded. Dark.

The one thing that saved us was an accident: a single agent had never been migrated off an older, still-permitted model. That agent kept running, and it is the reason we recovered the rest of the fleet over the weekend instead of waiting for Monday.

This post is not a news recap. It is an engineering lesson we paid for: model monoculture is a single point of failure, and it is one you almost certainly have right now.

Why everyone converges on one model

Standardizing on the newest top-tier model is the rational default, and that is exactly what makes it a trap.

The newest model wins the benchmarks. It needs the least prompt-babysitting. One model across the fleet means one set of quirks to learn, one cost profile to reason about, one config to maintain. Every incentive — quality, simplicity, operational sanity — points at "put everything on the best model and move on."

So that is what teams do. We did. The convergence is not a mistake of judgment; it is the obvious local optimum. The problem only shows up on the day the assumption underneath it breaks.

The failure mode: correlated availability risk

When every agent shares a model, every agent shares that model's availability risk. And availability has more failure modes than people plan for:

• Regulatory — an export-control order, a regional ban, a compliance hold. Friday's event.
• Outage — the provider has a bad day.
• Deprecation — a model version is retired on a schedule you didn't track.
• Rate-limited capacity — a usage ceiling that drops you to zero at the worst moment.

The detail that turns this from an annoyance into an outage is correlation. If your agents run on independent models, one of these events degrades the fleet — some agents stall, others keep working. If your agents all run on the same model, the same event takes out everything at once. There is no partial failure. The blast radius is the whole company.

This is the same reasoning data centers apply to power and network: you do not run the whole building off one substation, however good that substation is. A model provider is infrastructure. Treat a single model the way you would treat a single availability zone.

Heterogeneous model assignment as resilience

The fix is not "use a worse model." It is to stop letting the entire fleet's uptime depend on one correlated thing.

Match the model to the task, and keep deliberate diversity as insurance:

• High-volume, low-stakes work (routine summaries, classification, link rotation) does not need the flagship. A cheaper, broadly-available model is fine, and it is unlikely to be the first thing pulled in a capacity or regulatory squeeze.
• High-stakes work (a security review, an irreversible action) earns the top-tier model.
• At least one critical-path agent stays on a different model tier or provider on purpose — not because it is the best fit, but because it is your survivor. Our survivor was an accident. Yours should be a decision.

The goal is a fleet where no single model event can take out every agent. When the flagship vanishes, you want a company that runs slower and dumber for a weekend — not one that runs not at all.

Graceful degradation: the fallback chain

Diversity across the fleet handles the "who is still standing" question. The other half is what each agent does the moment its model is unreachable. The wrong answer — the one we lived — is crash-looping against a model that is not coming back for two days, burning retries and alerting nobody useful.

The pattern that works is a fallback chain declared at the orchestrator level, not buried in each agent:

MODEL_CHAIN = [
  :primary,    # newest top-tier — best output, highest correlated risk
  :secondary,  # different tier or provider — independent availability
  :fallback    # older, broadly-available — last resort
]

def run(task)
  MODEL_CHAIN.each do |model|
    next unless available?(model)
    return call(model, task)
  end
  halt_and_alert(task)   # do NOT retry into a wall
end

Three rules make this hold up in production:

1. Detect "unavailable" as a first-class state, distinct from "errored." A model that returns a regulatory or capacity refusal is not a transient blip you retry through — it is a signal to fall down the chain. We already had this lesson half-learned: a separate circuit breaker pattern stops our agents from retrying into a wall when their authentication is revoked. The model-availability case needed the same treatment.
2. Fall forward to a real, different model — not a smaller version of the same one that just got pulled by the same order.
3. Halt with an alert at the bottom of the chain, instead of looping. A loud, idle agent beats a busy one quietly setting money on fire.

This is the same instinct as surviving a quality regression — when a model silently gets worse, tool-level gates catch the drop that instructions would miss. Availability is the harsher version of the same problem: the model does not get worse, it gets gone. The defense is structurally identical. Don't trust one source to always be there.

The lesson: your model list is a dependency list

The shift that matters is mental. Most teams keep a careful inventory of their infrastructure dependencies — databases, queues, payment providers — and a plan for when each one fails. The model is missing from that list. It shouldn't be.

Treat your models the way you treat the rest of your infrastructure:

• Diversify. Do not put 100% of your agents on one model, however good it is.
• Monitor. Know which agent runs on what, and watch availability per model — not just per provider.
• Document the fallback before you need it. A fallback chain you design on a calm Tuesday is engineering. The one you improvise on a Friday night is a fire drill, and you will get it wrong.

We got the lesson the cheap way: one stray agent on an old model turned a total outage into a slow weekend. The next event might not leave a survivor by accident. So we stopped relying on accidents.

If you run agents in production and want the operational lessons as we hit them — outages, regressions, the boring infrastructure decisions that decide whether you survive a bad Friday — that is what we write up in stdout, our notes for developers running this stuff for real.