AI sales tools / Agents & automation
Jev by TypeSafe AI: classify and route GTM decisions
Jev is a decision model for software. It can help classify accounts and route leads, but the useful implementation starts with a clear taxonomy, labeled evaluation data and explicit rules for uncertainty.
By Stan, Co-Founder & CEO at frontBrick · Reviewed October 18, 2026 · 8 min read
Jev is TypeSafe AI's model for structured decisions rather than prose generation. It fits workflows that need a label, score or probability from supplied context, such as account classification and inbound lead triage.
What Jev does in a GTM workflow
A B2B form submission rarely arrives as a clean sales decision. Someone may request a demo, ask for support, propose a partnership or submit a job application through the same form. Jev can help interpret that input and return a structured answer that your workflow uses for routing.
The official API supports Choice for selecting an option, Score for an ordered rubric and Noul for a yes-or-no probability. Choice and Score include probability distributions and confidence; Noul returns its probability without a separate confidence value. Questions operate against supplied state. See TypeSafe's introduction.
Jev does not supply a contact database, browse for missing evidence by itself or maintain your CRM. Those remain separate stages. It is a strong candidate when the output can be narrowly defined. It is a poor fit for asking an open-ended question such as “design our whole growth strategy” or generating a finished outreach email.
Start with a taxonomy that sales can agree on
Before selecting a model, ask two people to label a sample of recent inbound requests. If they disagree on what counts as a sales lead, adding AI will automate the disagreement. Write definitions with positive examples, counterexamples and an explicit route for insufficient information.
A useful first classification might be sales inquiry, customer support, partnership, recruiting or unclear. Separate account fit from request intent. A customer asking for help can be a perfect ICP match and still belong with support. Combining everything into one “lead score” makes the resulting action difficult to explain.
| Decision | Proposed question | Downstream use |
|---|---|---|
| Request intent | Which defined category best describes this message? | Choose a team queue |
| Offer relevance | How closely does the stated need match this rubric? | Prioritize review within the queue |
| Missing evidence | Does the supplied record contain the required company context? | Request enrichment or human review |
| Existing relationship | Use confirmed CRM status, not model inference | Preserve the current account owner |
Keep exact rules outside the model. If the CRM already confirms an active customer and named owner, use that fact directly. Ask Jev for the ambiguous interpretation, then combine the result with deterministic business logic.
A proposed implementation: classify first, route second
This is a design blueprint, not a measured client deployment. The workflow can be coordinated through n8n, Make or your application.
- Collect the event. Store the original request, submission ID and received timestamp. Preserve the customer's wording rather than replacing it with an earlier AI summary.
- Resolve account context. Add verified company domain, current owner and lifecycle status. Distinguish source facts from inferred enrichment.
- Prepare compact state. Include the information needed for the classification. Remove irrelevant website boilerplate and repeated histories that make the decision harder.
- Ask atomic questions. Separate intent, offer relevance and missing information. Define criteria so adjacent labels do not overlap unnecessarily.
- Apply a review policy. Route uncertain or consequential cases to a person. Keep the original state, model version and decision output available for inspection.
- Execute the approved route. Update the CRM or create a task through the workflow layer. Protect against duplicate submissions and repeated writes.
- Capture corrections. Store the human's final label and reason. Use those examples to evaluate the next rubric or model version.
An illustrative input is a message asking to connect an existing product account to a new CRM, alongside a confirmed customer ID. The intent classifier may identify an implementation request, but the routing layer should preserve customer ownership. A generic high-fit score must not put that customer into an outbound sequence.
Confidence is useful, but it is not your accuracy rate
TypeSafe derives Choice and Score confidence from the distribution of model probabilities. A concentrated distribution produces higher confidence; an even spread produces lower confidence. That number is not the same as your observed percentage of correct decisions. The official confidence documentation recommends thresholds suited to the use case and consequences.
Choose thresholds with labeled examples. Run historical records through the proposed questions without changing live ownership. For each candidate threshold, calculate precision among automatically routed records, coverage of the total workload and the size of the review queue.
For example, suppose a hypothetical 200-record evaluation produces 120 automatic routes with 114 correct assignments. That is 95% precision at 60% coverage. It is an arithmetic example, not a Jev benchmark. The right decision depends on the cost of six misroutes versus reviewing the other 80 records.
Do not force all decisions through one threshold. Routing a message to a review queue is more reversible than suppressing a promising lead or initiating external outreach. Evaluate those actions separately. A low-confidence result should remain visible, not become an automatic rejection.
Build an evaluation set that exposes your edge cases
Include ordinary leads and the cases that create operational friction: mixed support and sales requests, consultants researching for a client, students, vague messages, personal email domains and multilingual submissions. Keep a holdout sample that was not used while refining the criteria.
Record disagreement between human reviewers before blaming the model. If both labels are defensible, revise the policy or provide a review path. Measure errors by category. High overall accuracy can hide a weak result for an important minority, such as existing customers seeking expansion.
Compare three baselines: the current manual process, simple rules and the Jev-assisted design. A rule based on explicit form selection may outperform a model where the needed information is already structured. Reserve model calls for decisions that need interpretation.
Current features, model versions and limits
Reviewed October 18, 2026. TypeSafe's model reference lists Jev 1.14 and 1.13, with default limits of 64k tokens per request and 32k per question. It also documents organization-level request and token rate limits. Model aliases can move, so record the returned version and pin a tested version where stable evaluation matters. See models and limits.
The October 14 release introduced experimental image, bounding-box and extended-context options under explicit flags. The vendor warns that these features have limitations for production use. Do not include them as assumed requirements in an initial lead-routing build. Start with supported text decisions and evaluate new capabilities separately. See the Jev 1.14 announcement.
When the API is unavailable or rate-limited, preserve the event and use a bounded retry or review queue. The operational system needs a fallback even if the model usually responds quickly. Latency should be measured across your complete data preparation and CRM path, not only the model call.
Jev pricing and a transparent cost model
As reviewed October 18, 2026, the official model rate is $42 per billion input tokens, equivalent to $0.042 per million, with output free. That is a token rate, not a flat price per lead. Use billed input usage and your selected access route to calculate actual cost. The official model reference is the pricing source.
For an illustrative estimate, 100,000 records averaging 1,000 billed input tokens each total 100 million tokens. At the stated rate, model input cost is $4.20. That excludes enrichment, workflow-platform charges, hosting, retries and human review. Measure total billed input rather than counting only the visible customer message.
At this unit price, taxonomy design and review effort may matter more than shaving a few tokens. Removing necessary evidence to reduce cost can increase misrouting and manual rework. Evaluate cost per correctly resolved record, including review, before presenting an ROI case.
Jev versus rules, chat models and agents
| Approach | Use when | Watch for |
|---|---|---|
| Deterministic rules | Inputs and policy are explicit | Unmaintained exceptions and overlapping conditions |
| Jev | A narrow interpretation must become a typed decision | Ambiguous criteria and unvalidated confidence thresholds |
| A text-generating model | The output needs prose, synthesis or explanation | Unsupported content and output handling |
| Hermes or another agent | The job requires gathering information and coordinating tools | Access scope, cost and unreviewed actions |
These components can work together. An agent can gather account evidence; Jev can classify it; a workflow platform can apply the approved routing policy. Keep each component's responsibility visible so an incorrect outcome can be traced to evidence, interpretation or execution.
What implementation and handover should include
Ask for a versioned taxonomy, labeled evaluation set, threshold report, field contract, integration, failure procedure and monitoring view. The team should know how to inspect a decision, override it and test a changed rubric before release. Discuss a Jev workflow with Stan. frontBrick implementation is scoped and priced around the business process, not the model's token bill.
Buyer questions
Can Jev write personalized outreach?
Its core role is returning structured decisions. Use it to classify relevance or route work, then use an appropriate writing tool and review process for prose.
Does typed output mean the answer is always correct?
No. A valid label can still be the wrong judgment. Evaluate business accuracy on your own records separately from whether the response has the expected structure.
What confidence threshold should we use?
There is no universal number. Select it from a labeled evaluation and the cost of mistakes. Measure both precision and review workload, then monitor changes after release.
Can Jev find missing account information?
The model evaluates supplied state. Fetch verified information through your research or enrichment layer, retain its provenance, and pass the relevant context into the decision.
Should we use the latest model alias?
It is convenient for exploration. For a production process with tuned criteria and thresholds, record the model version and evaluate changes before switching.
How do we prove it is better than our current process?
Compare it against current routing and simple rules on the same held-out records. Include misroutes, review time, unresolved cases and total cost, rather than only response speed.
Explore the connected tools
- n8n implementation guide
- Make implementation guide
- Clay implementation guide
- Hermes Agent implementation guide
Sources and editorial notes
Product facts and prices were checked against the sources below on October 18, 2026. Workflow recommendations are frontBrick’s implementation guidance. Examples are illustrative unless linked to a named case study. We offer paid implementation, and verified partner relationships are disclosed above.
