Jev is the first “System One” model from TypeSafe AI, released Sept. 15. The name borrows from Daniel Kahneman’s Thinking, Fast and Slow.

Think of System 1 as the quick gut-level call. System 2 is more slow deliberate thinking. Most of what we call AI today (at least referring to LLMs) is built for System 2 that reason, write, and explain one token at a time.

Jev is built for the other half. You can hand it the state of a system and a set of typed questions and it will hand back a choice from the options you defined with a probability attached.

I posted a link on our internal Slack channel just after release and asked the team for initial tests. Results were very interesting… In this article I’ll cover why I care, and why I think anyone building AI for production should too.

Most AI work is decisions

Open up any production agent and count the calls it makes to a model. A huge percentage of these calls are small decisions dressed up as text generation:

• Should this question go to agentic search/RAG

• Which queue does this support ticket belong in?

• Did the agent’s answer pass or fail?

• Which category in one system matches this line item from another?

Today most teams send each of those through a frontier LLM. We write a prompt parse the output, and handle the times it comes back malformed. We pay for output tokens we throw away, which is fine when you prototype, but expensive at scale. We also wait seconds for an answer that is ultimately a binary yes or no.

Tomasz Tunguz put it well “AI is coming for the if statement”. He replaced roughly 25% of the model calls in one of his agents with specialized deciders, and on 98 verified email threads the decider was right 80% of the time against 47% for a generative model.

What the Numbers Say

TypeSafe reports responses in 70 to 500 milliseconds, input priced at US$0.042 per million tokens, and free output tokens. The headline claim is up to 193 times faster and 444 times cheaper than frontier LLMs. Impressive, but those are vendor numbers from vendor-chosen tests.

The more useful early evidence comes from outside. LangChain tested Jev as an evaluator for agent outputs in LangSmith. On a pass/fail judgment, Jev matched human reviewers 100% of the time, compared with 80% for Claude. Its scores barely moved across 100 repeat runs. The full test cost 34 cents with Jev and $28.17 with Claude.

That’s five test cases on one weather agent, far too small to settle anything for our clients’ workflows, but enough to justify a real experiment.

The limits are real too. Developer Flavio Copes, who mapped them in detail, points out that Jev always returns one of the options you define, so you need an “other” choice for inputs that don’t fit. It doesn’t count reliably, struggles with dates and double negatives, reads text only, and caps out at 255 choices per question. It also can’t write, so anything a person needs to read still needs a generative model.

Why This Matters to those Building in the Applicaiton Layer

We built AltaML in the classical ML world. In the “old days” before LLMs, a lot of our work was classification. Is this pump about to fail? Is this claim likely fraudulent? Which customers are about to leave? Which of 40 categories does this document belong in? We trained a model, measured it against labeled data, and put it into production with a confidence threshold.

Jev looks a lot like that discipline delivered as an API. That’s why I think teams with ML roots are better placed to use it well than teams that started with ChatGPT. The skills that matter here are ones our people have used for a decade. Start with defining a clean label set (which rarely exists), build ground-truth data (often massive human involvement), calibrate the right threshold (huge debate with SMEs), and then figure out the adoption issue, especially when a supposedly confident answer is still wrong.

Our team has already flagged where they want to test first:

• Routing inside agents. Deciding which retrieval path, tool, or model a request needs, and do it in milliseconds instead of seconds.

• Evals. Many of our LLM-as-judge prompts already return true or false. When we don’t need the reasoning, a typed score is cheaper and repeatable.

• Mapping between systems of record. For example, invoices that categorize items differently than the ERP, time sheets that don’t line up with billing codes, freeform text that never matches exactly, etc.

• Checks before an agent acts. A fast gate that asks whether a proposed action fits policy before it runs.

Cost changes what’s worth building. When a decision costs a fraction of a cent, scoring every agent trace in production is no longer a budget conversation. Neither is classifying the millions of records a client has sitting in an old system.

It also fits where we’re taking our business. We’re moving clients toward pricing tied to outcomes. When the cost of each decision drops this far, that margin can go back to the client as a lower price or into more quality checks. The client comes out ahead either way.

How We’re Testing It

Here’s the approach we are trying:

1. Pick a live decision point where we already have labeled data and a current baseline.

2. Run Jev beside the existing LLM call and compare accuracy, speed, and cost on the same inputs.

3. Always include an “other” or “none of these” option, and track how often it gets picked.

4. Keep a human reviewing a sample. A cheap evaluator that is consistently wrong makes bad calls at scale.

5. Decide on our data. If it doesn’t beat the baseline, it doesn’t ship.

The Bigger Picture

I expect production AI to split in two. Frontier models will handle the open-ended work of reasoning and writing. Fast, cheap deciders will handle the thousands of small calls that run a workflow every day. The companies that get this right will know which is which at every step.

We’ll share what we find. If you’ve already put Jev against a real workload, I’d love to hear how it went. What broke? What are we missing?

Sources

• TypeSafe AI. “Introducing System One Models and Jev.” TypeSafe AI Blog. Sept. 15, 2026.

• LangChain. “Jev as an Agent Evaluator in LangSmith.” LangChain Blog. 2026.

• Tunguz, Tomasz. “AI Comes for the If Statement.” Tomasz Tunguz. 2026.

• Copes, Flavio. “A Deep Dive into Jev, TypeSafe’s System One Model.” Flavio Copes. Sept. 24, 2026.

Enterprise AI Strategy is Broken

The generative AI honeymoon phase is officially over. For the past two years, the market has rewarded organizations for experimenting. Pilots have been launched. Chatbots have been deployed. Teams have purchased enterprise AI licenses.

Yet many (most?) organizations still struggle to demonstrate measurable business outcomes. Even worse, the industry's fixation on token consumption or even token-maxxing is not aligned with customer value.

The future of enterprise AI lies in protecting your intellectual property and building custom, domain-specific AI agents.

Stop Outsourcing Your Brain

Karp, perhaps the only pubco CEO who speaks with such fire, delivered a stark warning regarding closed-source, token-based AI models. He argued that enterprises are growing increasingly frustrated with frontier AI labs, stating that paying for API tokens while essentially handing over core data and IP is an “irresponsibly over-sold” business model.

Whoever controls the architecture, wins the enterprise. By merely hooking up your operations to a closed-source model, you risk training a system that ultimately benefits your competitors (or creates a new one!). To protect your IP, businesses must shift toward sovereign AI deploying open-source or custom models in secure, controlled environments where the enterprise retains absolute ownership of both their data and processes.

Couldn’t agree more.

Super Agents and the Domain Moat

Jensen echoed this sentiment with the clarity and eloquence he is known for. He emphasized that completely outsourcing your company’s core reasoning and workflows to external parties is a profound mistake.

His take is a bit more nuanced. While frontier models are of course extremely powerful, a company’s true value lies in its specialized IP. The winners won’t be those who rely on generic capabilities, but those who build an architecture of custom sub-agents or “super agents” imbued with proprietary domain expertise.

More specifically:

• Start with frontier models for speed and capability.

• Specialize once performance is “good enough.” Use open or cost-effective models to create specialized sub-agents connected to proprietary tools and data.

• Build on open stacks so enterprises can control, iterate, and improve the intelligence.

• Think in terms of building out the AI harnesses (the orchestration, memory, tools, safeguards, and evaluation layers) rather than traditional business processes alone.

This approach, when done repeatedly, creates an economic moat by building digital workforce that deeply understands your company’s specific logic, processes, and institutional knowledge.

The Alternative Playbook

If every company has access to the same foundation models, then those models cannot be your competitive advantage.

Your advantage comes from:

1. Your proprietary data, with

2. Your operational knowledge and business processes, and

3. Your ability to embed AI into real workflows and get to adoption

That’s where sustainable differentiation lives. The winners won’t have the biggest models, they will apply those models with the right context in a cost effective way.

Too many AI initiatives begin with a technology decision. “We should use Anthropic, or Claude, or whatever.” These are implementation decisions, not strategy.

The better starting questions are:

• Which business problems create the greatest economic value?

• Where do we have unique data?

• Which decisions could AI improve?

• How will success be measured?

Technology should support strategy, not define it.

…And You Need to Control Your Destiny

Your proprietary information is a critical asset. Questions around governance, intellectual property, security, and long-term control are moving from IT into boardroom conversations.

This doesn’t mean organizations should avoid foundation models.

It means they should deploy them intentionally.

Videos follow below.

This term has come up frequently. It was a topic on the Dwarkesh Podcast that got comments from Andrej Karpathy, Lex Fridman has explored, and some of the world’s best investors routinely cite.

For anyone building a product roadmap, funding an R&D team, or deciding where to place a bet on AI, this isn’t just an academic curiosity, it’s a pattern worth understanding because it keeps repeating.

Who is this guy anyway?

Dr. Richard Sutton is an AI researcher and professor at the University of Alberta in Edmonton Canada. He is Chief Scientific Advisor at the Alberta Machine Intelligence Institute (Amii) and is a recipient of the prestigious Turing Award.

Putting aside all the accolades or citations that are too numerous to mention, he is widely thought of as one of the fathers of a branch of AI call reinforcement learning. He literally wrote the book.

The lesson in plain terms

You can read the original piece here.

The argument is simple yet profound: General methods that leverage ever-increasing computation ultimately outperform approaches that rely on human knowledge, and they do so by a wide margin.

Sutton observes that AI researchers have repeatedly tried to make progress by injecting human understanding into systems. Rules about how chess works, knowledge of language structure, features that describe edges in images, or models of how people think. These efforts often deliver quick wins because they make systems functional with limited resources. They feel intuitive and satisfying to the people building them.

Over time, however, these human-centric approaches plateau. Breakthroughs arrive instead from simpler, more general techniques that scale dramatically with more computation. The reason is Moore’s law and its extensions: the cost of computation keeps falling exponentially. What seems impossibly expensive today becomes routine in a few years.

When researchers (or companies) tie their systems too tightly to current human knowledge, they make it harder for those systems to take full advantage of future hardware and data. Time and resources spent crafting clever rules are resources not spent on methods that improve automatically as compute grows.

Why “bitter”?

Sutton calls this lesson bitter because it delivers a direct blow to human hubris.

We naturally want to believe that human intellect, taste, intuition, and domain knowledge are special. We assume that the secret to building intelligent software is encoding human wisdom into code.

The bitter truth is that human knowledge is often a bottleneck, not a catalyst.

When we hardcode our own strategic assumptions into AI software, we cap the machine’s potential at the limit of human understanding. When we step back and let general search and learning algorithms process massive scale, the AI discovers patterns, strategies, and efficiencies that humans could never have conceived.

There’s a psychological wrinkle here too, and it explains why smart people keep falling into the same trap. Building your own expertise into a system feels productive right away. It gets results in the near term, and it’s satisfying, because you can see your own thinking reflected in the machine.

Betting on raw computing power and letting the system learn on its own doesn’t feel as safe. It’s a bet on factors outside of your control, playing out over a longer timeline than most quarterly budgets, product roadmaps or government research granting cycles. So teams keep choosing the comfortable, expertise-driven path, and keep getting overtaken by whoever chose the harder, computation-driven one.

What this means outside the research lab

You don’t have to be training AI models to have run into a version of this problem. It shows up any time an organization needs to decide: do we build a hand-tuned solution around what our own experts already know, or do we invest in a more general system that improves mainly by throwing more processing power and data at it?

That question comes up constantly. Do you build a customer-service system around a decision tree that your best support agents helped design, or do you invest in an AI model that learns from vast amounts of conversation data without anyone hand-coding the rules? Do you build a forecasting model around your team’s understanding of the business, or a general statistical model trained on far more data than any one person could digest?

This isn’t to say that expertise is worthless. Hand-built, knowledge-driven systems are often exactly right for the problem in front of you today, especially when data or compute is limited, or when a deadline is close. That’s precisely why they win in the short term.

The bitter lesson is about what happens over a longer horizon, once cheaper computing power and larger data sets become available, as they reliably do. This is especially relevant if you are a research lab focused on achieving AGI debating on LLM architectures vs pure RL, etc. The thesis, if you agree with the bitter lesson, is then that the odds tend to favor whoever built something general enough to take advantage of it, and against whoever built in a fixed set of assumptions about how the problem should be solved.

The takeaway for decision-makers

Three things are worth carrying out of Sutton’s essay and into a boardroom.

First, be honest about the timeline. A hand-crafted, expert-built solution will likely outperform a general one in the near term. If your horizon is genuinely short, which is the case for nearly every commercial project, that is probably the right call. But if you’re in the enviable situation of making a multi-year bet, weigh the fact that general, scalable approaches have historically won.

Second, watch for the psychological trap. Teams get attached to solutions that reflect their own expertise. It’s flattering and you can brag about your results. That attachment is a poor guide to where the long-term advantage actually lies.

Third, treat “more computing power and data become available every year” as a fact to plan around, not a hope. It has held for decades across wildly different problems. Whatever roadmap you’re building, ask whether it’s positioned to take advantage of that trend, or whether it’s quietly betting against it.