Jev agent routing means using TypeSafe’s decision model to select among actions defined by an application. The router receives task context and available candidates; the agent then checks whether the proposed action is allowed and useful. Tool selection, skill selection and memory decisions are related patterns, but they require different criteria.
The central engineering question is whether adding a decision model improves task completion, cost or latency compared with the current router. This guide explains the architecture, fallback paths and evaluation design needed to answer that question. It also separates routing from argument generation and authorization.
The examples below are illustrative designs. They are not ready-to-install integrations or claims of proven performance.
Design the boundary between routing and execution
An agent may receive a natural-language request and need to select a tool, identify information to retrieve or decide when to request review. The application must define available alternatives and prepare relevant context.
JEV can evaluate a bounded part of that process. The surrounding system checks whether the candidate exists, the data is available and execution is permitted. This prevents classification from becoming authorization.
An initial structure might include user input, context selection, semantic evaluation, rule validation and action or review. Applications can use different sequences; JEV is not required at every stage.
Before implementation, check whether interpretation is necessary. When a request already contains an exact tool or record identifier, deterministic lookup may be sufficient.
Choose between Choice Score and Noul
Choose a question type according to the result the workflow needs.
| Type | Purpose | Illustrative example |
|---|---|---|
| Choice | Select among defined alternatives | Pick a candidate skill |
| Score | Assess against described rubric levels | Assess the completeness of a description |
| Noul | Estimate the probability of a proposition | Assess whether context is missing for routing |
Choice uses explicit options. Provide descriptions that distinguish similar alternatives and a path for out-of-scope cases. The selected option still needs execution checks. Choice documentation.
Score uses a rubric with described levels. Its result can reflect a distribution across those levels; it is not an exact measurement of a real-world quantity. Defining what each level means is part of application design. Score documentation.
Noul returns a value from 0 to 1 representing the probability of a yes answer. It is not a boolean or a guarantee that a proposition is true. The application decides how to handle intermediate results and the consequences of each route. Noul documentation.
Use Jev for tool and skill selection
A tool exposes an operation, while a skill can combine instructions and resources for a task. A router needs candidate descriptions that explain when each is appropriate. Similar names alone are not enough to define the choice.
Start by filtering candidates against the application's current availability and permissions. Supply the remaining descriptions, the user request and relevant state to a bounded choice. Include a route for missing information or no suitable candidate. Once selected, validate the candidate again before execution.
Keep tool selection separate from tool arguments. Choosing “search records” does not provide a valid query, account identifier or authorization. Those values come from verified application state, user input or a separate generation step with its own validation.
For example, a request to “find the renewal date” should reach a permitted read operation when the account is known. If the account is ambiguous, a clarification route is more useful than a forced choice. A request to change a contract needs an additional authorization decision even if the intended tool is obvious.
Test paraphrases, overlapping candidates, unavailable tools and out-of-scope requests. A label can look reasonable in isolation while sending the agent down a path that cannot complete the task.
Original illustration from page 12 of the workbook; labels are in Portuguese. Actions shown are illustrative and require separate execution checks.
Use Jev for memory classification and context selection
Agent memory has at least two distinct decision points: what a new record represents, and whether an existing record is relevant to the current task. Classification labels a record; context selection chooses what to present to the agent.
For a proposed memory workflow, classification could distinguish a confirmed decision, an unresolved question and an execution result. A separate relevance evaluation could assess candidate passages returned by an existing retrieval system. Define and test each question independently.
The surrounding system remains responsible for storage, retrieval, source links, access and expiration. A relevance assessment cannot make an outdated memory current or make a restricted record accessible. Preserve the distinction between an observed fact and an interpretation.
Suppose retrieval returns a previous pricing decision and an unrelated support incident. A selection step might retain only the pricing record for a commercial question. The agent still needs to check whether that decision applies to the current account and date. This is an illustrative design, not a measured retrieval improvement.
Measure whether filtering removes useful evidence as well as whether it reduces context size. Fewer tokens can be a poor tradeoff if the agent loses the one passage required to answer correctly.
Assign a useful lifetime to memory
Distinguish current working context, information needed to resume a task and durable knowledge. A pending follow-up and an established project decision should not automatically share the same retention rule. Keep source, purpose and validity alongside the record.
Durable does not mean immutable or exempt from deletion policies. When a decision changes, retrieval should expose the applicable version rather than treating every historical record as current. These are application responsibilities around the classification step.
Original workbook illustration, page 18. The labels mean now, later and always; “always” denotes durable usefulness in the teaching model, subject to correction and retention policies.
Evaluate outputs without confusing judgment with proof
An agent producing code or documents may need to check the result against specified criteria. Semantic evaluation can help identify whether an explanation covers a requirement or a deliverable appears to omit an item.
The input should include the requirement and relevant evidence. A bounded question can assess the relationship between them, with ambiguous cases referred for review.
This does not replace executed tests. A model may evaluate a report, but agreeing with it does not prove the reported tests ran or the system works. Execution evidence must come from the mechanisms that actually produced it.
A favorable assessment also does not authorize a merge, deployment, data deletion or publication. Those operations retain their own policies and permissions.
Keep the review loop bounded
For each requirement, retain the expected behavior, the evidence and the check result. Product requirements, technical proposals and architecture decisions can supply criteria, but reported compliance is not execution evidence.
Limit automated repair attempts and define an escalation path for missing evidence or unclear requirements. A bounded loop makes the evaluation inspectable and prevents repeated edits from being mistaken for progress.
Prepare API state and define fallback behavior
State is the content supplied for evaluation. The documentation supports text, JSON objects and arrays; the format should clarify relationships relevant to the question. State documentation.
Instead of sending the agent's entire history, select the request, alternatives and necessary facts. Preserve identifiers for source verification and separate system instructions from received content.
The JEV 1.13 documentation describes limitations involving arithmetic, date comparison, indirection, contradictory criteria and adversarial content. Option order may also influence Choice. Test edge cases and keep exact operations in code. JEV 1.13 limitations.
Benchmark the complete agent rather than the router alone
-
Select representative tasks and define successful completion before testing.
-
Compare the existing router and the Jev-based router with the same tools, permissions and task inputs.
-
Include ambiguous requests, unavailable tools, missing context and cases that should be escalated.
-
Track task completion alongside routing errors, unnecessary clarification and missed escalation.
-
Measure total calls, retries, human review and end-to-end latency, not only decision-call speed.
-
Record the model version, routing criteria and evaluation set; tune on separate cases.
-
Review consequential failures before allowing actions under the system's authorization policy.
Do not copy a confidence threshold as if it were universal. Routing to an incorrect queue has different consequences from executing a sensitive action. Policy should reflect those differences and behavior observed in your cases.
For business applications, see the existing article on JEV in CRM, in Portuguese. For a broader architecture discussion, see JEV as a semantic judgment layer, in Portuguese.
Questions about JEV in AI agents
Jev vs LLM structured outputs for agent routing
The decision is architectural and empirical. Compare a Jev router with the existing LLM-based route on identical tasks and candidate sets. Evaluate whether each route leads to successful completion, not just whether it returns an allowed tool name. A separate decision call must justify its added latency and operational complexity.
Does a faster routing call make the agent faster
Not necessarily. Retrieval, tool execution, retries and fallback can dominate the total time. Measure the complete task, including failed attempts, before claiming a latency improvement.
Can Jev replace retrieval in a RAG or memory system
A semantic evaluation can be designed to assess candidates returned by retrieval. The search index, access controls and source records remain necessary. Test whether filtering retains the evidence required for a correct answer; a shorter context alone is not a quality metric.
Is JEV an autonomous agent
In this design, JEV is an evaluation component. The agent and application organize context, tools, permissions and execution.
Does JEV replace memory or search
No. It can support classification. Storage, retrieval and access control remain responsibilities of the system.
Can JEV be used with NoCode
A NoCode workflow can integrate an API when its platform provides the necessary capabilities. Authentication, request format, error handling and action controls must be checked. This article does not provide a ready-made integration.
Does model confidence allow execution without review
Confidence is an input to policy. Review requirements depend on risk, rules and evaluation of the model in the application's context.
Data organization and possible points for semantic evaluation. The value 0.94 is illustrative, not a performance measurement. JEV receives application-prepared context; the diagram does not imply autonomous source access or a mandatory stage.
Complementary roles in an AI workflow. The sequence is illustrative, not a required order. JEV extraction must be bounded by options and criteria; calculations and permissions remain in software.
Felipe Luis Salgueiro — Marketing Engineer and GTM Builder.