Platform
Use the right model for the right workload
Choose a model by what the task actually needs rather than by what someone hardcoded, and make that choice a governed decision the organization can change.
A model retires
Rules to edit
1
Agents to redeploy
2
The same migration, priced two ways. One of these numbers is a rule change and the other is a pull request per repository.
Why this is not a code question
Somebody typed a model name into a repository, and now it is policy.
Every agent names the model it calls. That works exactly until the organization needs to change it — a model retires, a provider's terms move, a residency requirement lands — and then the only way forward is a pull request per agent, scheduled against every team's sprint.
This estate runs 11 agents against 7 models. One model is being moved off right now, and 2 agents have that model's name written into them.
Nothing about that is a technical problem. It is a governance problem wearing a technical costume: a decision the organization owns is stored somewhere only engineers can reach, in a form nobody can review and no auditor can read.
In flight now
CRM record hygiene and duplicate detection
Rule crm.hygiene selects a retiring model. Editing one rule moves it. Editing 2 repositories moves the same thing, more slowly:
- inventory-sync
- crm-hygiene
The routing table
Every rule cites a requirement of ours, never a claim about a vendor.
This is the part that keeps a routing table honest and, as it turns out, correct for longer. A requirement is something the organization can state and be held to. A model comparison is a benchmark somebody would have to keep re-running, and it expires the moment either provider ships.
Routing rules
6 rules · 5 owning teams| Workload | Decided by | Routes to | Falls back to | Owned by |
|---|---|---|---|---|
| Customer-facing refund adjudicationrefund.adjudication · v4 | Policy reasoningLatency budgetResidency | Claude Sonnet | GPT | Support Ops |
| High-volume ticket triage and classificationticket.triage · v6 | VolumeLatency budgetResidency | Claude Haiku | Claude Sonnet | Support Ops |
| Invoice extraction and ledger reconciliation draftingledger.drafting · v3 | Structured extractionPolicy reasoning | GPT | Claude Sonnet | Finance |
| Contract reading and clause extractioncontract.reading · v2 | ResidencyLong context | Llama | — | Legal |
| Vendor document classification, procurement onlyvendor.documents · v2 | ResidencyVolume | Mistral | Llama | Procurement |
| CRM record hygiene and duplicate detectioncrm.hygiene · v5 | VolumeStructured extraction | Gemini Proretiring | Claude Haiku | RevOps |
Rules
6
one per workload class
Owning teams
5
not one platform team
With a fallback
5
a rule without one is a single point of failure
Requirements in use
6
stated as task properties
IllustrativeIllustrative rules for the OpsAI sample estate, against the model register. No rule cites a benchmark result, because none has been run.
The requirements, and what each one is not.
Each of these is a property of the work, not of a model. The second column is there because every one of them has an adjacent version that sounds similar and is a vendor claim in disguise.
Requirement
What it means
What it is not
- Residency
- The content of the request may not leave our perimeter, under any contract.
- A statement that self-hosted models are better. It is a statement about where data may sit.
- Latency budget
- A person is waiting, so the answer has a deadline measured in seconds.
- A benchmark of provider response times. It is the budget our workload has.
- Volume
- The workload runs at a rate where unit cost, not capability, sets the ceiling.
- A price comparison. It is a statement about how often we call.
- Policy reasoning
- The task requires following a written rule through several steps and explaining the result.
- A claim that a model reasons well. It is a claim about what the task demands.
- Structured extraction
- The output must be a schema an accounting system will accept without a human retyping it.
- An accuracy score. It is a statement about the shape of the output.
- Long context
- The unit of work is a whole contract, not a paragraph of it.
- A context-window comparison. It is the size of our documents.
What a migration costs
A retiring model becomes an edit, not a quarter.
This is the whole return on making the choice a rule. The model register already knows which models need a decision; routing is what turns that knowledge into a change somebody can actually make this week.
01
The register flags it
A model moves to retiring or blocked, with a named owner and a reason. That is a fact about the estate, not a routing concern yet.
02
The rule names its successor
The owning team sets where the workload is going. Both models are valid while the migration runs, which is what keeps it from being an outage.
03
The record shows which served
Every trace already carries the model that answered, so a migration is verifiable from the evidence rather than from someone confirming they merged it.
The fallback is the part that makes a rule safe to change.
5 of 6 rules name somewhere to go when the selected model is unavailable. The one that does not is deliberate: the only other model that satisfies its residency requirement is approved for a different purpose, and routing contracts through it would be a governance failure dressed as resilience. A rule with no lawful fallback is worth being able to see rather than quietly filling in.
Scope
Routing picks which model answers. It grants nothing.
Four boundaries worth stating outright, because each one is something a page about model selection could imply by saying nothing — and the last one is the difference between a routing table and an authorization system nobody reviewed.
- It does not choose for you
- OpsAI does not rank models or recommend one. The organization writes the rule; OpsAI evaluates it, records which model served the request, and makes the rule changeable without a deployment.
- It does not compare models
- No rule here cites a benchmark, because we have not run one and a vendor comparison expires the moment either provider ships. A rule cites a requirement of ours, which is a thing we can defend.
- It does not call a model to decide
- The rule is evaluated deterministically, the same way a bound is. A routing layer that asked a model which model to use would put an inference call in front of every inference call.
- It does not widen what an agent may do
- Routing decides which model answers. Reach is governed at the action by a bound, and no rule on this page can grant an agent anything. A routing table that quietly accumulated authority would be the exact failure this product exists to prevent.
Owned by the team that carries the workload.
5 teams own rules here, which is the same arrangement the policy register uses. The team that answers for a workload is the team that decides what that workload needs — a platform team cannot know that a refund has to be explainable or that a contract may not leave the building.
Where to start
Find out how many repositories name a model you are trying to leave.
It is a grep, and the answer is usually larger than anyone expects. That number is the cost of storing a governance decision in code, and it is the number routing removes.