Every_Agent_Spawn_Asks_the_Same_Question_First

Before any agent in my fleet runs, it has to answer one question: what tier is this work? Not which model, which tier. Code review, QA, research, brand strategy, ops audits run on one tier. Copy, social, content, design run on a cheaper one. Bulk mechanical typing runs on local models behind executable checks, never on judgement calls. The tier maps to a model name only at the last possible step, and the rule that enforces this is blunt on purpose: if a spawn doesn't explicitly name its tier, it silently inherits the most expensive model available, which is treated as a failure state, not a convenience. I catch that failure state in review, not in production, because the rule is written down and checked, not remembered.

I didn't write that rule because I was worried about a specific unreleased model. I wrote it because model lineups move faster than any architecture I could hand-tune around a specific model ID. My own top-tier designation for orchestration work has already changed once this year, superseding a prior default that had been standing for months. If the definition of "the good model" inside my own fleet isn't stable for more than a few months at a time, betting an architecture on a specific model existing, staying available, or staying the best option is a bet I'd lose on a schedule I don't control.

The_Same_Logic,_Pushed_Further_Than_One_Vendor

The tiering rule handles model churn inside a single provider's lineup. It doesn't handle the harder version: a provider deciding not to ship a capability at all, or shipping it to someone else first. For that, the routing logic has to span multiple vendors.

Three of my external agents run on three unrelated runtimes: one on OpenAI's Codex CLI, one on Google's Antigravity CLI, one on DeepSeek's model through the Codex harness. None of them are Anthropic. All three are treated as always-review, meaning nothing they produce ships without a human reading it first, which is a separate and deliberate trust decision, not a workaround for the routing. The point of running three completely different vendors isn't redundancy for its own sake. It's that if one vendor's frontier stalls, gets rate-limited, gets more expensive, or turns out to be sitting on a stronger model it isn't shipping, the fleet doesn't need rearchitecting. It needs re-routing, which is a config change, not a rebuild.

That's the part of the architecture that was already true before I read a word about Model 2.

What_Anthropic's_Own_Risk_Report_Confirmed

Anthropic's August 2026 Risk Report disclosed an internal model, code-named Model 2, that shows noticeable capability gains over its public line. The decision to hold it internally hinges partly on incomplete predeployment safety assessment, not commercial timing.

I'm not treating that as alarming. I'm treating it as confirmation of something the architecture already assumed: a provider can be sitting on a materially stronger model than you have access to, for reasons entirely outside your visibility, at any point in time. Anthropic's disclosure is unusually direct about it, which is itself notable, but the underlying condition isn't new. It's the permanent state of building against a frontier you don't own.

The_Gap,_and_How_the_Routing_Logic_Absorbs_It

The gap between the best model you can use and the best model that exists isn't a temporary information problem that better access or a bigger budget solves. It's structural. A frontier lab has every reason to hold a capability internally until its own safety review clears it or commercial timing says go, and neither clock runs on your build schedule. You will not know when the gap opens, how wide, or when it closes.

What you can control is whether your architecture absorbs that gap without a rewrite. Practically, in my fleet, the routing and tiering rules live in a layer entirely decoupled from any model's capabilities: a rule cascade mapping work type to tier, an override protocol making the tier explicit at every spawn point, and an external-agent layer spanning three vendors on the same always-review trust footing. None of these reference a specific model by name where it matters. They reference a job to be done and the trust required to do it. The model is the last thing resolved, not the first thing assumed.

That's what makes a disclosure like Model 2 a non-event for the architecture, even though it's genuinely interesting for the industry. If Anthropic ships Model 2 next quarter, my routing config changes. If it never ships, nothing changes. Either outcome is a config edit, because the architecture was never betting on which one it would be.

I_Don't_Need_to_Know_What_Model_2_Can_Do

I still don't know what Model 2 can actually do, and I'm not going to guess. That's not a knowledge gap blocking my build. It's the exact condition the architecture was built to absorb. The frontier tier I'm planning against was never going to be the actual frontier, and the fix was never going to be better information. It was decoupling the build from needing that information at all.