Academy
6. Missions and Agents: Automatic Selection Beyond Chat
Learn that missions use an admin-configured model pool with the same health signals, and that agents may switch models between steps.
In OUPI's chat, automatic model selection works per message: every time you send a message, the system evaluates the task, complexity, your plan's eligible models, cost, and provider reliability to pick the best model. But what happens when you move beyond chat into missions and agents?
Missions operate on their own model pool, configured by your administrator. Instead of drawing from the full set of models your plan allows, a mission uses only the models the admin has explicitly assigned to it. This gives organizations tighter control over which providers handle specific workflows — important for data sensitivity, budget, or compliance reasons.
Despite using a separate pool, missions still benefit from the same health signals that protect chat. If a provider is failing or its quota is exhausted, the mission can consult those reliability measurements and steer away from the troubled model, just as chat would.
A key difference between chat and missions is how model switching works. In chat, you pick a model (or let OUPI pick) and that choice holds for the conversation until you change it. Each message is routed independently, but within a single conversational flow.
In a mission, an agent may execute multiple steps — for example, researching, drafting, then reviewing. Between those steps, the agent may switch models. A complex reasoning step might use a frontier model, while a simple reformulation step might drop to a fast, lighter model. This mirrors the same logic automatic selection uses in chat (escalating for hard tasks, economizing for easy ones), but applied across the stages of a structured workflow rather than across individual messages.
The reliability layer — OUPI's continuous measurement of provider health — is shared across both chat and missions. Models that fail too often are set aside until they recover. If an answer fails mid-way because a provider is unavailable or its quota is exhausted, OUPI retries once with a model from another provider.
For missions, this is especially valuable. A multi-step agent workflow that breaks halfway through because of a provider outage would waste all the work done in earlier steps. By reading the same health signals, missions can proactively avoid unreliable models before a failure occurs, and still benefit from automatic failover if something goes wrong unexpectedly.
Reasoning effort also adapts automatically in missions, just as it does in chat. For models that support extended reasoning, the depth of thinking scales with the detected complexity of each step. A straightforward extraction step gets minimal reasoning; a multi-criteria decision step gets deeper analysis. You don't configure this — the trade-off between speed, cost, and depth is handled automatically per step.
This means administrators configure which models are available, but the intelligence of how those models are used — including reasoning calibration and health-aware routing — is built into the platform.
If you're an administrator setting up a mission, include models from more than one provider in the pool. This way, the mission can take advantage of automatic failover: if one provider goes down, the agent can retry on another without the workflow stopping.
You don't need to micro-manage model choices within a mission. The same signals that drive chat routing — task fitness, cost, reliability — apply to missions too. Trust the system to escalate to stronger models for hard steps and economize on simple ones. Intervene only when you have a specific reason, like restricting data to a particular provider.
Missions extend automatic model selection beyond chat. They use an admin-configured model pool rather than the full plan catalog, but share the same health and reliability signals. Agents in missions can switch models between steps — using heavier models for complex reasoning and lighter ones for simple tasks. Reasoning effort adjusts automatically per step. Failover protection works the same way: if a provider fails, OUPI retries on another. Administrators control which models are available; the platform handles the rest.