When an employee asks for a list of open work orders, the hard part may already be solved: the organization has a report, a database query and rules about who may see it. The assistant needs to recognize the request and use that existing capability.

A follow-up such as “Which delays need attention, and what information are we missing?” asks for something different. It needs comparison, interpretation and a useful explanation. A practical design can route the first request through a narrow path and reserve a larger language model for the second.

Give each part a clear job

  1. The small routing model proposes a capability. It chooses from a short, defined list, such as work-order lookup, approved-document search, reasoning or clarification. It does not invent tools or grant access.
  2. Application code validates and authorizes the request. Ordinary rules check the capability, the signed-in user, the allowed records and the required arguments before anything executes.
  3. The larger model handles ambiguity and synthesis. It can interpret a difficult question or explain validated results when language reasoning adds value. Tool requests from this model pass through the same code checks.

These paths are sometimes called System 1 and System 2: a quick decision stage and a more involved reasoning stage. Here they are architectural labels. They do not guarantee speed, correct reasoning or safe behavior. The router is still a model that can misunderstand a request.

A generic office example

This is a fictional design example, not a client case study or a report of measured results. Imagine an office assistant with read-only access to approved work-order information.

An employee asks: “Show the open work orders assigned to my team this week.”

  1. Propose the route. The small model selects the known work-order lookup capability. The application requests clarification if the date range or team is unclear.
  2. Check the request. Code rejects unknown capabilities, checks the employee’s permission, and derives the allowed team scope from their identity. It validates dates, filters and result limits. A team name supplied in a prompt cannot expand access.
  3. Run the existing lookup. The application executes an approved, parameterized query using read-only credentials. The model does not write SQL or select arbitrary tables. Return only permitted fields, with record references and the lookup time.
  4. Present the result. A normal table may be enough. If the employee asks for a summary of delays, a larger model receives only the permitted results and prepares a draft with source references. It distinguishes recorded facts from suggested explanations.

Parameter binding keeps query values separate from query structure; it does not establish who may access the records. Permission and scope checks remain separate application responsibilities. OWASP’s query parameterization guidance explains the query boundary.

Closing a work order or reassigning staff falls outside this read-only example. A consequential action or decision needs an explicit approval process and a responsible human reviewer.

Make uncertainty an ordinary outcome

“Take care of the overdue jobs” could mean display them, summarize them or change assignments. Choosing a plausible route is not enough. The assistant should ask what the employee intends. A reasoning model may help interpret the question, but it cannot bypass a denied permission or invent missing authorization.

Include clarification and unsupported-request outcomes in the design. If a tool times out, say the lookup failed. If records are missing, say what is unavailable. If the request exceeds the employee’s access, decline it. None of these outcomes should become an invented answer.

Keep instructions found inside retrieved records from becoming tool authority. Validate proposed tool calls and limit privileges at the application boundary, as described in OWASP’s prompt injection prevention guidance. Routing alone is not a prompt injection defense.

Measure what the employee waits for

A fast routing call can still make the whole workflow slower. Every request pays its overhead, and an ambiguous request may pay for both models. Compare the design with a simpler baseline using representative examples held out from tuning.

  • End-to-end latency: time from the employee’s request to a usable result, including model loading and cold starts, queueing, routing, validation, tool calls, fallback and rendering. Check typical and slower responses under realistic concurrency.
  • Routing quality: correct routes, confidently wrong routes, unsupported requests sent to a tool, and requests that should have triggered clarification. A well-formed choice can still be the wrong choice.
  • Fallback and answer quality: how often the larger model is needed, whether clarification resolves uncertainty, and whether summaries stay supported by the retrieved records.
  • Full operating cost: both models, hosting or local hardware, employee review, error handling and maintenance. A lower cost per routing call is not the cost per completed task.

Test paraphrases, incomplete questions, unfamiliar requests and attempts to cross access boundaries. Repeat the evaluation when tools, model versions or business rules change. Keep consequential outputs subject to human review.

The extra layer has to earn its place

A router is worth considering when many requests map to a stable set of capabilities and avoid enough larger-model work to outweigh routing overhead, misroutes and fallback. It is less attractive when most requests already require reasoning, request volume is low, or tool definitions change constantly.

Someone must maintain the capability descriptions, permission rules, validation, evaluations and failure handling. If a button, form or existing report already meets the need, start there. A focused pilot should establish whether routing improves the workflow enough to justify another component.

Explore RAW’s AI assistant and integration setup or use the first-project guide to define a pilot with clear boundaries and a way to judge the result.

Where Tev1 fits in this discussion

Recent integration work with Tev1 prompted this article. Its public documentation provides an example of a model aimed at bounded choices. Together AI describes Tev1-4B-experimental as a language-model fine-tune for decisions among supplied options. It still uses a language-model output head; it is not deterministic application code.

Confidence also needs care. Ollama’s Tev1 documentation says its confidence value describes how concentrated the option probabilities are, rather than the probability that the answer is correct. A production fallback threshold needs evaluation on your workflow.

As checked on September 30, 2026, the Tev1 repository’s code and original documentation are MIT licensed, while the model card says the fine-tuned weights’ release license is still being finalized. Dataset terms are separate. Verify the terms for the exact model before commercial deployment. The model card also says prompt injection, calibration and broad behavior on unfamiliar inputs have not been comprehensively evaluated.

The useful lesson is the division of work: recognize a known request, enforce its boundaries in code, and bring in reasoning when the task calls for it. That design can be evaluated without assuming a particular model will make it faster or safer.