DEV Community: Alexandre Itida

Jev Is Not the Main Story. The Main Story Is How We Spend Intelligence.

Alexandre Itida — Fri, 25 Sep 2026 13:14:03 +0000

TypeSafe's Jev is fascinating. But I think the bigger idea behind it may matter even more for the future of AI agents.

For the last few years, the dominant way to build AI software has been surprisingly simple:

Send something to a large language model.

Need to classify a message? LLM.

Need to decide which tool to call? LLM.

Need to check whether a result makes sense? LLM.

Need to decide whether another LLM should retry?

Another LLM.

It works.

But as we move from chatbots to systems containing dozens — eventually hundreds — of AI decisions, I think this architecture starts to look increasingly strange.

Then TypeSafe AI introduced Jev.

And while most of the discussion around Jev has understandably focused on its speed, cost and unusual architecture, I think there is another lesson hiding underneath the launch.

We may have been treating intelligence as a single resource when it should actually be managed as a hierarchy.

Jev changes the unit of AI

Traditional LLMs produce strings.

Jev does something deliberately narrower.

TypeSafe describes JEV as a System One model: you provide state and structured questions, and the model returns typed probabilistic decisions that software can consume directly.

Instead of asking:

Read this customer request and explain what our system should do.

you might effectively ask:

Is this urgent?

Which department should handle it?

Does this require human review?

And receive structured probabilities rather than paragraphs.

The difference sounds small.

Architecturally, it isn't.

Jev moves intelligence closer to something like a probabilistic function call.

TypeSafe's published numbers are striking: the company reports end-to-end latency between 70 and 500 milliseconds and a price of $0.042 per million input tokens.

In some of its workflow evaluations, it reports gains as high as 193.6× in speed and 444.6× in cost.

Those are TypeSafe's own benchmarks, and the company itself acknowledges important methodological caveats.

So I don't think the numbers should be the main story yet.

The architecture should.

Not every decision deserves a frontier model

Consider an autonomous agent working on a real business process.

During a single task it might need to decide:

Is this information relevant?
Which tool should I use?
Did the previous step succeed?
Should I retry?
Is this result suspicious?
Does this require human approval?
Do I need deeper reasoning?

Those decisions do not have equal complexity.

Yet a common agent architecture effectively treats them as if they did.

That is like asking a senior engineer to personally answer every support ticket, check every log line and approve every routine operation.

It works.

It is also a terrible organizational design.

The same may be true for AI.

FAST, REVIEW and DEEP

One mental model I have started using is to separate machine reasoning into three layers.

I call them:

FAST → REVIEW → DEEP

This is not TypeSafe terminology. It is simply a way I find useful to think about agent architecture.

FAST

Cheap, low-latency judgments.

Routing, classification, relevance, simple validation and confidence estimation belong here.

Most decisions in a large autonomous system may eventually happen at this level.

Jev is an interesting candidate for exactly this layer.

REVIEW

Something is uncertain, contradictory or important enough to deserve more computation.

A stronger model examines the state, checks evidence and determines whether the original decision should stand.

DEEP

Expensive reasoning is reserved for the relatively small number of problems that actually require it.

Planning.

Complex diagnosis.

Novel situations.

High-impact decisions.

And in sufficiently important cases, the next step is not another model at all.

It is a human.

So the architecture becomes something closer to:

EVENT
   ↓
FAST
   ↓
confidence high? ─── yes ──→ ACT
   │
   no
   ↓
REVIEW
   ↓
resolved? ────────── yes ──→ ACT
   │
   no
   ↓
DEEP
   ↓
high impact / uncertainty?
   │
   yes
   ↓
HUMAN

Now intelligence is no longer simply something an application "calls."

Intelligence becomes something the system allocates.

That may be more important than model routing

Model routing already exists.

Send simple prompts to a cheap model and difficult prompts to an expensive one.

Useful, yes.

But I think the bigger opportunity goes beyond routing.

The real system needs to manage:

effort, uncertainty, evidence and authority.

A fast model saying "92% confident" should not automatically mean that an action is safe.

Confidence must interact with consequences.

Deleting a temporary file and deleting a production database can have exactly the same model confidence while requiring completely different governance.

So a mature agent architecture eventually needs something like:

decision
+ confidence
+ consequence
+ evidence
+ permissions
= execution policy

That layer interests me much more than simply choosing between Model A and Model B.

About the "zero hallucinations" claim

I would interpret that claim carefully.

Jev's output space is typed and defined in advance, so the model cannot suddenly return an essay when the software expects one of three categories.

Type errors can therefore be eliminated by construction.

That's genuinely valuable.

But a structurally valid answer can still be wrong.

A classifier that confidently selects the wrong category has respected the schema perfectly.

It has still made the wrong decision.

Type safety solves an important software problem. It does not eliminate epistemic uncertainty.

Interestingly, Jev exposing probabilities may make that distinction more useful rather than less useful: software can decide what to do with uncertainty instead of pretending it doesn't exist.

The real opportunity: cognitive governance

This is where I think things become particularly interesting.

Imagine an agent system where every task starts with inexpensive judgment.

Most operations finish there.

Some escalate to stronger reasoning.

A smaller number reach deep analysis.

And only consequential or unresolved cases reach humans.

The objective would no longer be:

Use the smartest AI available.

It would become:

Use the minimum sufficient intelligence required to reach a reliable decision.

That is a very different optimization problem.

We could measure a system not only by benchmark accuracy, but by:

quality
×
latency
×
cost
×
human intervention
×
evidence

This could eventually matter enormously for AI economics.

If agents execute thousands of decisions while completing one business process, reducing the cost of an individual decision by an order of magnitude changes what is economically possible.

TypeSafe explicitly connects Jev's name to William Stanley Jevons and the Jevons paradox: making intelligence dramatically cheaper could increase total consumption of intelligence rather than reduce spending on it.

That may prove to be a very good analogy.

Jev may be a primitive, not the platform

And this is perhaps my biggest takeaway.

I don't currently see Jev as a complete agent platform.

I see something potentially more fundamental.

A primitive.

Something that could sit inside orchestration systems, agents, CRMs, security systems, support platforms and business automation.

The interesting product may therefore not be a system built entirely around Jev.

It may be an architecture capable of combining:

deterministic code
        +
fast probabilistic judgment
        +
frontier reasoning
        +
human authority

and knowing when each should be used.

Jev happens to make one part of that architecture dramatically more interesting.

We may be entering the age of intelligence budgets

Cloud computing taught us to think about CPU, memory, storage and network as resources that software architecture must allocate.

AI systems may add another resource:

cognitive effort.

Some decisions deserve milliseconds.

Some deserve seconds.

Some deserve minutes.

Some deserve humans.

If autonomous agents become as common as many of us expect, deciding how much intelligence a decision deserves may become just as important as the intelligence itself.

That's why I'm watching Jev.

Not because I think every LLM is about to be replaced.

Quite the opposite.

Jev makes the differences between kinds of intelligence much clearer.

And that may lead us toward agent architectures that are faster, cheaper — and, more importantly, much better governed.

Why AI Agents Need a Pause Button Before They Need More Autonomy

Alexandre Itida — Thu, 24 Sep 2026 11:36:29 +0000

An AI agent can be impressive in a demo: it reads a request, selects a tool, and completes a task with little intervention. But an agent that changes a live system needs a different kind of capability. It needs to know when not to act.

A useful way to think about agent autonomy is not “How many steps can it perform without asking?” but “How much uncertainty can it safely resolve before an irreversible action?” Those questions lead to a more practical design for agents that create accounts, publish content, deploy software, or update business records.

Separate preparation from execution
Imagine an agent asked to publish a weekly technical article. The work has several stages: selecting a topic, checking sources, drafting, reviewing, scheduling, and sending the final text to a publishing API. These stages do not carry the same risk.

Research and drafting can happen in an isolated workspace. An accidental publication under a real person's name has a different consequence. The agent should be able to prepare a complete article and then stop at the boundary between proposed and public.

That boundary should not depend on a sentence in a prompt alone. The publishing program can require a structured approval state, a specific account identity, a valid publication window, and an explicit switch that is disabled by default. Each check addresses a separate failure mode.

Make actions observable before making them automatic
A reliable agent should leave a record of what it intends to do and what actually happened. For a publication workflow, that means retaining the proposed article, the approved version, the scheduled time, the remote article identifier, and the result of the API request.

This matters most when the answer from an external service is uncertain. A timeout after sending a request does not prove that the request failed. The remote service might have processed it successfully while the response was lost.

Blindly retrying a create request can then produce duplicate articles. A safer approach is to record the operation as in flight, inspect the remote system, and only resume after reconciling the result. The same principle applies to payments, account creation, and any other operation where repeating an action could matter.

An operation identifier or an API-supported idempotency key can help when the service provides one. When it does not, the client needs its own durable journal and a reconciliation process. A local variable that disappears at the end of a run is not enough.

Give the agent permissions that match the stage
An agent researching a topic does not need the credential used to publish under someone's identity. A reviewer does not need permission to modify the original evidence. A publisher does not need permission to rewrite approved content.

Separating these roles reduces the consequences of mistakes and makes review meaningful. It also creates a simpler audit trail: which version was reviewed, which version was sent, and which identity authorized the final action?

For small projects, these roles do not have to be separate AI models. They can be separate software permissions and workflow steps. A conventional script that refuses to publish without approved input may provide a stronger safety boundary than an elaborate conversation between agents.

Test the stop conditions, not just the happy path
A successful demo proves that a workflow can finish. Before enabling recurring execution, test cases in which it should stop: the wrong authenticated account, missing approval, a duplicate remote record, an unavailable API, a malformed article, an earlier attempt with an unknown result, or two scheduler runs starting together.

There is a useful distinction between an agent that fails to complete a task and an agent that correctly refuses to perform an unsafe action. For production automation, the second outcome can be evidence that the design is working as intended.

Autonomy is a property of the workflow
The goal is not to ask a human to click through every mechanical step. It is to move repetitive preparation, validation, and recovery work into software while preserving human decisions where identity, reputation, money, or live infrastructure is at stake.

More capable AI models may improve planning and drafting. They do not eliminate the need for durable state, constrained permissions, clear approval boundaries, and a reliable way to stop. Those engineering choices are what make an autonomous workflow useful outside a demo.

AI disclosure: This article was drafted with AI assistance. Its technical claims and final wording require the author's review before publication.