Abstract. Multi-model routing is conventionally presented as a gateway-level concern: a shared classifier inspects every request and dispatches it to the most appropriate model. This paper argues that for a focused, single-purpose agent, that framing is the wrong layer. We describe a two-model workflow in which a single agent assigns reasoning by role — a fast, inexpensive model (DeepSeek) performs high-volume comprehension, and a stronger model (Gemini 2.5 Pro) is reserved for the verification step where judgment is the binding constraint. The routing decision is made at runtime by the agent itself, on a structural boundary of the task, rather than by an external classifier on a heuristic. We examine the design rationale, the implementation, and the conditions under which this pattern is — and is not — the correct one.
1. Introduction
Discussions of language-model selection tend to converge on a single global question: which model is best? The question is malformed. A model is not better or worse in the abstract; it is better or worse for a particular kind of work. The model that reasons well through a subtle defect is usually overkill for the task of reading a ticket and determining what it asks. Conversely, the model that is inexpensive enough to run against every incoming request may not be the model an operator wants rendering a judgment on whether a change is safe to ship.
Most agent deployments suppress this distinction by routing every turn through one model, accepting that a single capability level is the price of simplicity. The alternative — a multi-model router that classifies each request and dispatches to the optimal model by task type, cost, and modality — is well established at the platform layer. This paper concerns a third configuration: a two-model workflow that lives inside a single agent, in which the agent assigns reasoning by role rather than by request classification.
2. Problem Statement
An agent that reviews changes before merge does not perform one kind of work; it performs two, with materially different requirements:
- Ingest. Pull the ticket, read the request, parse the acceptance criteria into an actionable checklist. This step is high-volume, repetitive, and structurally simple. It is exactly the kind of work for which a large, expensive model is unnecessary — and where a fast model's occasional misread is inexpensive to detect and to repair.
- Verify. Check the change against those criteria and render a verdict — pass, or request changes. This is the judgment call. A false pass ships a broken change; a false fail blocks a sound one. It is the step where error carries real weight, and therefore the step where the stronger model earns its cost.
The governing observation: within a single workflow, the read-and-understand step and the verify step are not the same job. Binding a single model to both forces a compromise on the one step where compromise is most expensive.
3. Design
The workflow assigns each role to a model by design:
| Role | Model | Rationale |
|---|---|---|
| Ingest — read the ticket, parse acceptance criteria | DeepSeek | Fast and inexpensive; sufficient for comprehension at volume. The output is a small, inspectable artifact, so a modest error rate is tolerable. |
| Verify — run the QA pass and render a verdict | Gemini 2.5 Pro | Judgment is the expensive part. This is where a wrong call costs the most, so it is where the strongest model available is directed. |
The agent's primary model (DeepSeek) handles ingest and all other work. The verification stage is delegated to a Gemini 2.5 Pro subagent through an explicit model-and-provider specification. The scope of the delegation is deliberately narrow — verification only — which is what keeps the economics coherent: the stronger model is paid for only where judgment, not volume, is the bottleneck.
The handoff between the two roles is made visible rather than implicit. At runtime the sequence is labeled:
🔍 Gemini · QA verification — gemini-2.5-pro reviewing the change against the criteria
✅ Gemini · verdict — pass / request changes
The labeling is an operational measure, not a cosmetic one. It makes the model boundary auditable: at a glance it is clear which stage a stalled or failed run had reached, and which model was responsible for it. In a system where model attribution is otherwise presumable, that visibility is what allows the boundary to be inspected rather than assumed.
4. On the Placement of the Routing Decision
There are two coherent places to put this kind of decision, and they solve different problems:
- At the gateway. A shared proxy sits in front of every request from every agent, classifies each by task type, and selects a model. This is the correct shape when an organization runs many agents and providers and requires centralized accounting, rate limiting, and failover in a single control point.
- At the agent — in the runtime. The routing logic lives inside the workflow. The agent knows it has two stages and delegates the verification stage to the appropriate model when it reaches that point.
For a focused, single-purpose workflow, the gateway is the wrong layer. A gateway router must introduce a classifier to infer complexity, when the actual boundary is structural and already known: ingest goes one way, verification goes the other. Routing at the runtime level allows the agent to route on a real boundary of the task rather than on a heuristic about it, and it removes an entire class of runtime decisions — and with them, a class of failures. Gateway routing is reached for when the fleet outgrows the single agent; it is not the starting point.
5. What This Pattern Is Not
To avoid misreading the design, it is worth stating what it does not contain:
- It is not a classification matrix — there is no task-type routing layer deciding which model should field which question.
- It is not a fallback chain — no mechanism fans requests across models when one stalls. There are two fixed roles, each assigned to a model by design.
The division is static rather than dynamic by intent. A static assignment removes a class of runtime decisions and, with them, a class of failures. The cost is generality; in exchange, the behavior is predictable and auditable, which is the property a verification workflow most needs.
6. Applicability
A two-model split is not a universal good. It is the correct instrument when:
- The workflow contains a real structural boundary. Ingest versus verify is one. If the task does not naturally divide into a cheap step and a careful step, the split should not be forced.
- The two steps have genuinely different cost and quality requirements. If a single model would serve both adequately, a second model adds complexity without return.
- The deployment has not yet reached gateway scale. A single agent with a clear division does not require a classifier, a routing matrix, or a central proxy. Those arrive with the fleet, not before it.
7. Conclusion
The two-model workflow is, at bottom, a budgeting discipline. It does not make any individual model more capable, and it does not add capacity. What it adds is proportionality: inexpensive work remains inexpensive, and the single decision that would be costly to get wrong receives the strongest model it is defensible to direct at it. For an agent whose output is a pass-or-fail verdict on another party's work, that selective investment has proven worth more than any single-model upgrade on offer.
The pattern's value is not in the number of models it employs, but in the discipline of assigning the right model to the right role, at the layer where that role actually occurs.