Hyppää pääsisältöön

Jev, and the return of the AI classifier

Julkaistu aiheella AI, Teknologia
A close-up of an Othello game board with black and white game pieces (disks).

Kirjoittaja

Mika Majakorpi
Mika Majakorpi
Chief Technology Officer

Mika Majakorpi works as CTO at Nitor. Mika has been there and done that in various architecture and development roles for years in the Finnish IT scene. Lately, he’s been combining business and technology insights to chase the ever-elusive ROI of AI investments with clients.

Artikkeli

On September 15, TypeSafe AI released Jev, an AI model for fast decision-making. Jev answers multiple-choice questions, gives a score on a scale you define, and states the probability that something is true. Nothing else. Constraints foster creativity, and builders have not stopped talking about it since. A small ecosystem of open-source lookalikes has already appeared around it.

That’s worth pausing on, because classification is the oldest, least glamorous branch of machine learning, and it’s suddenly back at the centre of how people build with AI. 

There’s a business reason to like the classifier renaissance, too. BCG’s read on enterprise AI this August found that 82 percent of CEOs are more optimistic about AI’s return than they were a year ago, while only 6 percent of companies are actually seeing meaningful financial value from it, and traced the gap to companies measuring hours saved and tasks automated instead of money moved. 

Classifiers speak directly to that gap, because money moves on decisions: approve or decline, which option to take, how urgent or risky something is. Jev turns each of those into a data-driven, auditable call, with a calibrated probability and a log entry behind every answer. That points to a layered way of automating workflows: Jev handles the high-volume yes-or-no, multiple-choice, and scoring decisions quickly and cheaply, and frontier GenAI steps in to reason only where a step is genuinely open-ended. Getting that division of labour right, instead of sending every step through the most expensive model, is where the financial value from AI actually shows up. 

Jev decides, frontier GenAI reasons visualisation. Summarised: High volume, bounded decisions → Jev. Low volume, open-ended work → frontier GenAI.

What changed

Classical classifiers are narrow by design: pick a task, label a dataset for that exact task, train a model on it, deploy something good at that one thing only. Every new decision meant a new training cycle. 

Jev and its peers skip that step. You send a block of context (a chat message, a support ticket, an agent’s current state, whatever) plus typed questions, a choice between options, a score against a scale, a yes or no with a probability. The model answers all of them at once, in well under a second, at a fraction of the cost of routing the same decision through a frontier GenAI model. No training cycle. That’s the actual shift: a general-purpose model you can point at almost any bounded decision without building a dataset and training a custom model first.

One spike vs broad coverage illustration: A classical classifier excels at the one task it was trained for. A broad classifier is good enough at almost anything.

It’s still a classifier. It won’t reason through something open-ended for you, and a confident-sounding score is only as good as its calibration on your own data. But for the huge number of small, bounded decisions that never justified their own ML pipeline, it’s a genuinely useful new primitive. 

Here’s how to put Jev to work.

Data-driven decisions: let the classifier choose 

Textbook case: ticket handling

The most valuable use is letting Jev make actionable decisions: the choices that move a business process forward or automate a step for the users of an application. At each step, it chooses among several valid next actions based on the data in front of it. Support ticket triage is the textbook case. A new ticket arrives, and Jev picks which team it goes to (technical, sales, or billing) with a probability for each. A confident pick routes the ticket straight to the right queue, while an ambiguous split sends it to someone to sort out. No one has to read and forward every ticket by hand, and no frontier model spends a full turn deciding where it belongs. The pattern is: enumerate the valid next moves deterministically, then let a cheap, broad-knowledge classifier pick among them.

Agentic commerce

This applies also to agentic commerce we’re working on with our clients. On the customer-facing side, an AI shopping assistant acting on a customer’s behalf has to choose, at each step, from a set of moves that are already valid: your usual oat milk is sold out, so swap in the closest alternative, skip it this week, or wait for the next delivery; a discount comes up on something you buy often, so stock up now or ignore it. That choice can be the classifier’s job instead of a hardcoded flow or a full model turn spent reasoning it out.

On the backend side, warehouse and delivery routing already runs on a rules engine choosing among a fixed set of warehouses, couriers, or shipment splits. Swapping the brittle decision tree for a classifier choosing among the same valid options, but able to weigh in a messy context the rules engine can’t (a delivery note, a customer’s stated urgency), is a lower-risk way to get the same idea into production than starting with a customer-facing assistant. 

Scoring

A second mode is to score. Instead of a pick from a list, Jev rates something against an ordered scale, and what happens next depends on the score rather than a fixed branch or a single winner. Support ticket urgency is the natural fit here: a ticket gets rated low, medium, or high, and that rating decides whether it’s auto-handled, queued, or escalated to a person. It’s not a pick among several; it’s a position on a scale that a threshold or a queue acts on afterwards.

AI in the product: cheap enough to gate everything 

The third mode is the simplest: allow or block. Here, the classifier sits beside a decision rather than making it, approving or blocking something another system already proposed. The obvious place for it is anywhere that takes open-ended user input and feeds it to an AI feature. A classifier this fast and cheap can sit in front of every message a user sends to a chatbot or AI-powered feature, scoring it for offensiveness, misuse, or simply "does this match what the feature was built for" before anything downstream runs.

The economics are what make this practical at scale: at this latency and cost, gating every single user submission this way is not a meaningful tax on the product, where routing every submission through a full LLM safety check would be.

Developer tooling: routing and guardrails 

The same gate works inside the tools developers use to build software. If a classifier is cheap enough to sit in front of every message a user sends, it’s cheap enough to sit in front of every tool call a coding agent makes. Take OpenCode and Pi, two open-source CLI coding agents that can run on open-weight models. Jev could power an auto mode for them that lets the agent act without asking for approval at every step, with Jev as the gate in front of each action. 

  • Action guardrails. Before the agent runs a shell command, edits a file outside its stated scope, or takes some other consequential step, a Jev call could score whether that action should proceed, need confirmation, or be blocked. The existing guardrail tools for OpenCode and Pi match command patterns against a rule list rather than judging them, so a broad classifier would add something real: it wouldn’t need every dangerous pattern enumerated by hand, and it’s cheap enough to call before every single tool call. 

  • Model routing by complexity. Jev could classify each incoming prompt or task to decide which model handles it: a small, cheap open-weight model for mechanical edits and exploration, something heavier for design work and hard debugging. The routing decision itself costs next to nothing compared to the work it’s routing, which is the whole point. 

The common thread 

All of these are the same underlying move, a cheap, fast, calibrated model sitting in a control loop where a slower or more expensive step used to be.

Sometimes it’s the choice itself, picking the next action from a set of valid moves. Sometimes it’s a position on a scale that decides which queue or threshold something falls into. Sometimes it’s a check before a proposed action, deciding whether to let it through. To see these patterns in the wild, JevTracks showcases the cool things people are already building with Jev. 

The payoff is faster answers for customers, fewer manual hand-offs for employees, and a smaller bill for frontier models, with every call logged and auditable. Money moves on decisions, so that’s where AI’s return shows up. Stop automating tasks. Start automating decisions.

Kirjoittaja

Mika Majakorpi
Mika Majakorpi
Chief Technology Officer

Mika Majakorpi works as CTO at Nitor. Mika has been there and done that in various architecture and development roles for years in the Finnish IT scene. Lately, he’s been combining business and technology insights to chase the ever-elusive ROI of AI investments with clients.

A close-up of an Othello game board with black and white game pieces (disks).

See Jev in action

Want to see it for yourself? Play Nitorious Othello and watch how quickly Jev decides moves in the game. Jev is fed with insight on Othello strategy and the game state, and it responds with ranked moves and confidence levels for each decision.