Jev vs. Tabular AI: What If AI Stopped Talking and Started Making Decisions?
From fancy bubble tea to practical business automation — exploring two approaches to making AI genuinely useful.
Introduction: AI, we need to talk. Or maybe not?
Recently, I came across an interesting development in AI that made me wonder: do we really need a Large Language Model (LLM) to answer every question?
Think about it. We have powerful AI models capable of writing articles, generating code, explaining quantum physics, and occasionally telling us how wonderfully intelligent our questions are.
But what if our application needs something much simpler?
Should we approve this order? Is this customer likely to leave? Which product should we recommend?
We don’t necessarily need a three-paragraph explanation from an AI philosopher. We need a decision, preferably fast, reliable, and understandable by software.
This is where two interesting AI approaches come into play: Jev, a new decision-focused model from TypeSafe AI, and Tabular Foundation Models, such as TabPFN and SAP’s RPT.
They approach the same problem from different directions. And, interestingly enough, they might work even better together.
1. Jev: Less talking, more deciding
Jev is the first System One model from TypeSafe AI. Instead of generating sentences word by word, it produces structured decisions that ordinary application code can use directly.
The name System One comes from Daniel Kahneman’s concept of fast, intuitive thinking.
Imagine an online shop selling some rather unusual products:
- Unicorn Bubble Tea
- Dragon’s Breath Chili
- Fairy Dust Tiramisu
- Wizard’s Cloak Hoodie
A customer writes:
“I love spicy food, but last time your chili almost turned me into a fire-breathing dragon. Could you recommend something less dangerous?”
A traditional LLM might compose a lovely response with apologies, recommendations, and perhaps a joke.
Jev takes another approach. We pass the customer’s message as state (the information available at the moment) and ask specific questions.
For example, Jev could classify the customer’s request as a product recommendation rather than a refund request. It could also return probabilities for the available choices.
No essay. No unnecessary conversation. Just a structured decision that application code can use.
Under the hood, Jev uses a training approach called Reinforcement Learning for Calibrated Decisions (RLCD). The idea is to reward not merely choosing the right answer, but also providing useful estimates of uncertainty.
It can produce a choice, a yes/no probability, or a score on a predefined scale. Multiple questions can be answered in parallel.
TypeSafe reports response times of 70–500 milliseconds for its target workloads, although actual performance depends on the task and deployment.
One important detail: Jev cannot generate arbitrary prose, but that does not mean its decisions are guaranteed to be correct. A perfectly valid answer can still be wrong.
2. Tabular AI: The spreadsheet gets a brain
Now consider a different situation.
Our imaginary shop has been selling magical products for several months. Naturally, we’ve collected some data.
Nothing particularly fancy. Just rows, columns, and numerical values. This is what we call tabular data.
Traditional machine learning has been working with this type of data for decades, using algorithms such as Random Forest, XGBoost, and CatBoost.
But a newer generation of models, including TabPFN and SAP’s Relational Pretrained Transformer (RPT), offers an interesting twist.
Instead of learning everything from scratch for each new spreadsheet, these models arrive with knowledge gained through earlier training on many datasets.
Think of it like hiring a data analyst who has already seen millions of spreadsheets.
You provide examples of previous sales, including which products were successful. The model looks for relationships between the columns and predicts outcomes for new records.
For example:
“Will Fairy Dust Tiramisu sell well during our Halloween campaign?”
Tabular AI could estimate demand using relevant historical records, prices, promotions, seasons, and other features.
The interesting term here is in-context learning: certain tabular foundation models can use the labeled examples supplied with a prediction request without traditional task-specific retraining.
TabPFN learns much of this ability during pretraining on synthetic datasets. Its 2025 research demonstrated strong performance on relatively small tabular datasets. The family has evolved quickly since then: TabPFN-2.5 extended support to datasets of up to 50,000 records and 2,000 features, while the newer TabPFN-3.5 continues pushing the capabilities of tabular foundation models.
And TabPFN isn’t alone in this space.
NVIDIA recently introduced Kumo Tabular, another foundation model that learns from labeled rows and predicts new outcomes without traditional task-specific retraining. NVIDIA reports impressive accuracy and efficiency across several tabular benchmarks.
SAP's Relational Pretrained Transformer (RPT) takes a related approach. NVIDIA's Kumo Relational also works with relationships across multiple database tables, moving beyond a single spreadsheet.
Different engines, similar ambition: turning ordinary business data into useful predictions without building a new machine-learning pipeline for every question.
Of course, a model can’t discover demand signals that were never recorded. If no relevant seasonal information exists, Halloween remains a mystery — even for a sophisticated transformer.
3. Jev vs. Tabular AI: Same destination, different engines
Here is where things become interesting.
Get Vadim Bakhrenkov’s stories in your inbox
Join Medium for free to get updates from this writer.
Both technologies are useful for making predictions, assigning scores, and supporting decisions. But they rely on different kinds of information.
Zero-shot vs. few-shot deserves a simple explanation.
Imagine asking two chefs to prepare Dragon’s Breath Chili.
The first chef has general cooking knowledge and can make a judgment immediately, without tasting previous batches. That’s our Jev analogy.
The second chef has records of 500 previous recipes, ingredients, customer ratings, and complaints about excessive spiciness. They use these examples to estimate whether the next recipe will succeed. That’s tabular AI.
Neither chef knows everything. One relies more on general knowledge; the other learns from your specific historical examples.
And this is precisely why combining them can make sense.
4. What if we combine both? The magical shop experiment
Suppose our shop wants to predict whether a customer will return a product.
We have structured information, such as purchase history and refund rates, alongside free-form customer reviews.
Jev can interpret the text:
“The Wizard’s Cloak Hoodie looks fantastic, but the sleeves are designed for an actual wizard with six arms.”
It might classify the review as a sizing complaint with a high probability.
Tabular AI can then combine that judgment with historical return patterns.
We could use the resulting prediction to offer a size exchange, recommend another product, or ask a human to review an unusual situation.
And this isn’t purely hypothetical from an architectural perspective. SAP researchers have already explored treating tabular foundation models as decision models and comparing their RPT approach against Jev.
In an SAP-reported comparison across four enterprise workflows, Jev achieved 72.70% accuracy, SAP RPT reached 76.75%, and RPT combined with CASE achieved 78.75%.
The additional CASE component helps RPT interpret semantic information in text.
One important detail: Jev was evaluated zero-shot, making decisions without task-specific labeled examples. SAP RPT used a many-shot approach, drawing on a larger collection of labeled examples.
Both approaches have their strengths, but the different learning setups mean this isn’t a like-for-like leaderboard.
5. What about real-world implementation?
If I were building a proof of concept, I would start with something deliberately simple.
Take a CSV file containing order history, add a collection of customer messages, and define one prediction target: Will this order require manual review?
For the first prototype:
- Use Jev’s API to classify customer messages into predefined categories, with probabilities.
- Add those judgments as new columns to the dataset.
- Feed the enriched table into TabPFN or another suitable tabular model.
- Test predictions against previously unseen orders, and compare with Jev alone and a traditional CatBoost baseline.
The important part is evaluating on data the system hasn’t already learned from. Otherwise, impressive-looking accuracy could simply mean we’ve built a very expensive memorization machine.
In production, we would also need to check probability calibration, false positives, privacy requirements, inference costs, and what happens when the model isn’t confident enough.
For practical experimentation, the starting points are TypeSafe AI and Prior Labs TabPFN.
6. So, is this the future of AI?
Possibly one part of it. But let’s not throw away our LLMs just yet.
Jev represents an interesting move toward AI as a software component rather than an endlessly chatting assistant. Tabular foundation models bring a different advantage: using previously observed relationships to predict what might happen next.
There are still limitations. Jev’s internal architecture is not fully public, and its calibrated probabilities need real-world validation. An independent September 2026 evaluation found strong results on several classification tasks, but also weaknesses in fine-grained judgments and certain probability thresholds.
Meanwhile, tabular models remain sensitive to data quality, changing business conditions, and the examples we feed them.
The fundamental lesson is surprisingly simple.
Not every AI problem needs a language model. Not every prediction needs a chatbot. And not every business decision requires a giant neural network.
Sometimes you need an LLM to explain a complicated problem. Sometimes you need Jev to make a quick judgment. Sometimes you need a tabular model to discover what your business data has been trying to tell you for years.
And sometimes you need all three.
And if anyone manages to predict the optimal spiciness of Dragon’s Breath Chili without setting the kitchen on fire, I’d be interested in the dataset.
Further reading
