Why We Built Automatic Model Routing for AI Agents
June 5, 2026 · 6 min read
When you build a team of AI agents, the instinct is to give everyone the best model available. If one agent runs on Claude Sonnet and it produces great output, why not just run every agent on it? Or go further — use the frontier model for everything, and you'll never have to worry about quality.
The problem: a frontier model costs roughly 20–50× more per token than a fast efficient model. And most of the agents in a typical team don't need frontier capability. The formatting agent that cleans up HTML output, the triage agent that routes incoming tickets to the right queue, the classifier that labels records as "urgent" or "normal" — these are not tasks that benefit from deeper reasoning. Spending frontier budget on them is waste. And the waste compounds across every run, at every volume level.
The other instinct — run everything on the cheapest model to save cost — has the opposite problem. The orchestrating analyst that reads 40 pages of context and synthesises a coherent recommendation genuinely needs the capability. Routing it to a fast model produces mediocre output. So you end up paying less and getting less.
The right answer is somewhere in between, and it's different for every agent.
What we built
Envelope now automatically assigns a model to each agent based on two signals: the agent's role description and its position in the team hierarchy.
We defined five tiers:
| Tier | Model | Signal |
|---|---|---|
| Reasoning | o4-mini | Roles about verification, logic chains, multi-step planning |
| Frontier | gpt-5.4 | Root orchestrators, analysts, senior/principal agents |
| Balanced | claude-sonnet-4-5 | No strong signal — safe default |
| Efficient | gpt-5-mini | Classification, extraction, formatting, summarisation |
| Fast | gpt-5-nano | Labelling, tagging, filtering, detection |
We trained a set of keyword signals against each tier. "Analyst", "synthesise", "decide", "review", "orchestrate" → Frontier. "Classify", "triage", "route", "extract", "transform" → Efficient. "Label", "tag", "categorise", "filter", "detect" → Fast. Roles containing "verify logic", "chain of thought", "multi-step" → Reasoning.
For agents whose roles don't match any keyword, we fall back on hierarchy. Root agents — those with no supervisor — default to Frontier, because they're typically orchestrating or producing final output. Leaf agents — those that report to a supervisor — default to Efficient, because they're typically executing a specific scoped task.
The whole thing is computed from the agent definition at runtime. No configuration required, no model field in the JSON unless you want one.
What we discovered
Role keywords are surprisingly predictive. We initially expected role descriptions to be too vague to do useful routing. What we found is that well-written roles — the kind that describe what an agent does rather than what it is — contain consistent signal. An agent described as "Senior researcher who synthesises findings across multiple sources" reliably needs more capability than one described as "Classifier that routes inbound tickets by department". The verbs carry the information.
Single-agent teams are different. A team with one agent often has a root agent doing a simple well-defined task — "Send a daily digest email summarising yesterday's commits." That's not really a Frontier job. We added a rule: root agents with short roles (five words or fewer) default to Balanced, not Frontier. This avoids frontier spend on teams that clearly don't need it.
Hierarchy is a useful prior, not a rule. The leaf-agent-defaults-to-Efficient heuristic holds most of the time but breaks when a leaf agent is given a surprisingly complex task. Someone building a team where a leaf agent is responsible for generating executive-level summaries will find the default too light. The override path handles this — one sentence in the room thread resets it — but it surfaced that hierarchy is a signal, not a guarantee.
Observability changes how people think about cost. Once the By Agent table showed which model each agent ran on, and whether it was auto-routed or manually set, we immediately had questions like "why is the formatter on Frontier?" and "is that routing actually right?". Making the model selection visible — rather than buried in a config file — turns a previously implicit decision into an observable one. That's a change in how you relate to cost, not just a display change.
Provider defaults had to come from somewhere — and they'll move. The cheap tiers — Efficient and Fast — don't carry meaningful provider preference; you'd switch those for latency or cost, not quality. Balanced defaults to Claude Sonnet, which is already a strong Anthropic position for the majority of agents with no strong signal. Frontier defaults to gpt-5.4 because that's the model we've validated in the orchestrator role — Claude Opus is a real alternative there, possibly better for long-form synthesis, and the override is one sentence. We expect the Frontier default to be the one that shifts as real run data comes in. These aren't ideological choices; they're starting points.
The override UX
We deliberately didn't build a settings panel for model selection. A modal with a dropdown for each agent is the right interface when models are a permanent architectural decision. For most teams, they're not — they're a parameter you might want to change during testing, dial in over a few runs, and then leave alone.
Instead, overrides happen in the room thread. Say "switch the researcher to a faster model" and the assistant maps the intent to a concrete model, persists it to the install, and confirms. "Reset back to auto" clears it and routing takes over again. The override is per-agent and per-install, so you can have different choices in different contexts without changing the underlying team definition.
The constraint is that it requires an install — you can only override the model for a team you've actually installed in a workspace, not for a template definition. The template stays provider-agnostic. The install carries the preferences.
What this looks like in practice
A typical content production team — strategist, researcher, writer, editor — might route like this before any manual intervention:
- Strategist (root, role: "Senior strategist who plans content calendars and decides priorities") → Frontier
- Researcher (reports to strategist, role: "Research agent that finds and summarises relevant sources") → Efficient
- Writer (reports to strategist, role: "Writer who produces first drafts from research briefs") → Frontier (strong write/produce signal — would be balanced without the Frontier FRONTIER_SIGNALS match)
- Editor (reports to writer, role: "Editor who reviews drafts for quality and formats final output") → Efficient
If you ran that team on frontier for all four agents, you'd spend roughly 3–4× more per run than necessary. With routing, the researcher and editor — which genuinely don't need frontier reasoning for their tasks — run on models that are both cheaper and faster.
What's next
We're currently building the successor-model nudge: if you've manually pinned an agent to an older model that has a better replacement available, the assistant mentions it once when you're in the room thread. Not a hard upgrade, not a notification — just information, the next time you're there.
We're also looking at feedback-loop routing: using the quality of previous runs (from human gate decisions) to adjust tier assignment over time. If an agent is consistently being approved at the Efficient tier, routing learns. If it's being rejected and re-run, it might benefit from a higher tier. That's further out, but the architecture supports it.
Model routing is live for all teams created in Envelope. Existing teams with explicit model fields in their definitions are unaffected — routing only fires when no model is set. To opt an existing agent into routing, ask the assistant to "reset the model for [agent] to auto" in the room thread.
Read the model routing guide — tier table, override phrases, and when to intervene →
Envelope is an open schema and managed runtime for AI agent teams. openenvelope.org
Frequently Asked Questions
What is automatic model routing in Envelope?
Automatic model routing assigns the right AI model to each agent in a team based on two signals: the agent's role description and its position in the team hierarchy. A classifier gets a fast efficient model; a root orchestrator gets a frontier model. No manual configuration required.
Which models does Envelope route to?
Four tiers: reasoning models (o4-mini) for verification and logic-chain tasks; frontier models (gpt-5.4) for root orchestrators and senior analysts; balanced models (claude-sonnet-4-5) as the safe default; and efficient models (gpt-5-mini) for classification, extraction, formatting, and summarisation.
Can I override the automatic assignment?
Yes. You can specify a model for any individual agent in the workspace, or describe what you want in plain language — "use the fastest model for this agent" — and Envelope will update the assignment.
Why does this matter for cost?
A frontier model costs roughly 20–50× more per token than an efficient model. In a typical multi-agent team, most agents are doing classification or formatting work that doesn't need frontier capability. Routing those agents to cheaper models cuts run costs substantially without affecting output quality.