Skip to content
/Orbit Blog
Go back

Jev Explained: Is It Just Another Classifier?

ByMohammed Izhaar

Jev is making headlines for solving classification problems up to 200 times faster than before. Almost everyone who hears that asks the same question: isn’t Jev just a machine learning classifier, something that has existed for years?

Jev versus a trained classifier: same output, different setup

It’s a fair challenge. A random forest has been sorting support tickets into buckets for a long time, and nobody wrote headlines about it. So what is different this time? The answer isn’t in what the model outputs. It’s in how the model is told what to do.

The output looks exactly the same

Put a random forest and Jev side by side and look only at the results. Both give you a fixed list of labels and a probability for each one. For a support ticket, that might be Billing 0.94, Technical 0.04 and Sales 0.02.

If the output is identical, the difference has to be upstream. It comes down to how each model learns the task it is asked to do.

How a trained classifier learns the task

A traditional supervised classifier, like a random forest, learns its job during training. You collect labeled examples, meaning tickets that people have already sorted, and you train the model on that one problem. From those examples, it learns that a ticket can go to one of three teams: Sales, Technical or Billing.

That works well until the business changes. Say a fourth team, Onboarding, is created next month. The model has never seen that label, so it can’t assign it. You need new labeled examples for the new team, and then you have to retrain the model.

That is more than a small tweak. Someone has to find and label enough tickets, run the training again, and check that the older labels still behave. Every change to the list of teams sends you back through the same loop.

How Jev handles the same task

Jev doesn’t need a new model for each task. Instead, you write the options in plain English inside the request itself, next to the ticket. For the support inbox, a simplified sketch of the request looks like this:

Ticket: I've contacted you three times about my refund and I'm still waiting.

Options:
- Sales handles pricing.
- Technical handles product failures.
- Billing handles refunds.

The answer comes back in the familiar form, a label and a probability for each option. These numbers are made up for illustration:

Billing    0.94
Technical  0.04
Sales      0.02

Now the fourth team arrives. There is no labeling and no retraining. You add one line to the options, “Onboarding handles setup and getting started”, and send the request again.

It reads meaning, not keywords

There is a second difference, and it matters as much as the first. Jev understands the meaning of natural language, so it doesn’t depend on particular words showing up in the text.

Take the message “I’ve contacted you three times and I’m still waiting.” The word “frustrated” never appears, yet a model that understands meaning can flag this customer as frustrated. A keyword filter would miss it completely, and a classifier trained without a frustration label would have nothing to say about it.

In practice, that means you can ask new kinds of questions about the same ticket, such as who should handle it and how upset the customer sounds, just by describing them in words.

Side by side

Here is the whole comparison in one place.

Trained classifierJev
Learns the task fromLabeled examplesOptions written in the request
Adding a fourth teamNew labels, then retrainEdit the text, send again
Wording it has never seenOnly as well as its training data coversReads the meaning
OutputLabels with probabilitiesLabels with probabilities

A small sketch: act when sure, escalate when not

Because you get a probability for each label, your code can decide how far to trust an answer. This sketch is illustrative: classify() stands in for whatever call you use.

TEAMS = {
    "sales": "handles pricing",
    "technical": "handles product failures",
    "billing": "handles refunds",
}   # a fourth team is one more line here

def route(ticket: str) -> str:
    probs = classify(ticket, options=TEAMS)      # e.g. {"billing": 0.94, ...}
    team, p = max(probs.items(), key=lambda kv: kv[1])
    return team if p >= 0.8 else "human_review"  # unsure: a person decides

The 0.8 cutoff is an example. Tune it on your own tickets.

When to pick which

If your labels are stable and you already have plenty of labeled tickets, a trained classifier is still a solid, cheap choice. If your labels change often, or you have little labeled data, describing the options in plain English is much easier to maintain.

So is Jev just a classifier? It returns the same kind of answer, but you set up the task in words instead of training data. Speed claims like 200 times faster are worth testing on your own tickets before you trust them.


Share this post:

Previous Post
Six Workflow Patterns for Multi-Agent AI, and Two to Build First
Next Post
Context Engines Explained: And How to Build the Half That RAG Misses