TypeSafe AI’s Jev makes a structured AI decision fast and nearly free. That’s a big deal for anyone building automation, and a new load on the data layer underneath: more reads and writes, on data that changes faster.
TL;DR: Jev turns AI into “smart if-statements”: routing, triage, fraud checks and guardrails, fast and cheap enough to run on every event. That’s the good news. The catch is underneath. Every decision reads data and writes a result, so the data layer sees two new pressures. Volume: far more reads and writes per second, from many agents at once. Velocity: the data changes faster, because the decisions are changing it. And Jev’s confidence scores can’t warn you when the data it was given is stale. The model will be confident either way. Getting the most out of Jev means infrastructure that handles both pressures in one place.
On September 15, TypeSafe AI released Jev, and it’s one of the more interesting model launches this year. Jev doesn’t write text. You hand it the state of your program and a set of typed questions, and it returns typed answers with calibrated probabilities. TypeSafe reports responses in 70 to 500 milliseconds, input at $0.042 per million tokens, and output for free.
That makes a real AI decision fast and cheap enough to put almost anywhere in your code. For anyone building automation, that’s great news.
It’s also a problem. Not TypeSafe’s problem: yours, one layer down. Every decision Jev makes reads data before it runs and writes a result after. Put Jev everywhere and the data layer has to serve far more of those reads and writes, on data that changes faster than it used to. This post is about what that means.
Jev is a System One model from TypeSafe AI, released in early access on September 15, 2026. It takes program state plus typed questions and returns typed answers (a choice from a list, a score on a scale, or the probability that a statement is true), each with a calibrated confidence. It’s built to be called by software, not read by people.
A few details matter for what follows:
TypeSafe is open about the limits of its own numbers: its team wrote the benchmark workflows, and it calls the reported gains the likely high end of what real workloads will see. For the full details, start with TypeSafe’s launch post.
TypeSafe’s phrase for Jev’s main use is “smart if-statements.” Is this ticket urgent? Which model should handle this request? Is this tool call safe to run? Does this transaction look like the last three that turned out to be fraud?
Until now, most of those branches ran on hand-written rules, because a multi-second model call per event was too slow and too expensive. If a model was involved at all, it ran off to the side, in a batch job or a review queue. Jev is built for the main path. The branch that used to be if amount > 500 becomes a model reading the whole situation and returning a typed verdict before the user notices a wait.
That’s a real step up in what automated decisions can take into account. And TypeSafe expects it to spread fast: the model is named after the economist William Stanley Jevons, who showed that when something gets cheaper to use, people use far more of it. Cheap decisions won’t be saved for special cases. They’ll run on every event.
A model call is one step in a decision. Before it, something has to gather the data: the customer’s balance, recent activity, a few computed signals, similar past cases, what another agent just did. After it, the result gets recorded: a verdict, a route, a hold, a spend against a budget.
Jev makes the middle step fast and cheap. It doesn’t change the steps on either side. When decisions multiply, those steps multiply with them, and the data layer feels it in two ways.
A person working a review queue makes a few hundred decisions a day. A fleet of smart if-statements makes that many in a second. Each decision reads several things, and Jev’s parallel answers make this sharper: ten questions cost roughly what one does on the model side, but on the data side those ten questions often need ten different pieces of data.
The writes multiply too. Every answer Jev returns is a row: a choice, a probability, a confidence. And the next decision needs it: which tickets went where, what this customer scored a second ago, how much of a budget an agent has already committed, what’s waiting for human review. Those aren’t logs to load overnight. They’re inputs to the next decision.
More decisions don’t only read more data. They change it. Every approval moves a balance, every reservation moves inventory, every agent action moves a budget. When decisions run on every event, the data they depend on changes on every event too.
So the decision’s validity window, the time in which the data it read is still true, shrinks to the gap between two events. A cache three seconds behind was fine when a person made the next decision a minute later. It isn’t fine when a model makes it forty milliseconds later.
This is where Jev’s best feature turns into a risk. Its confidence scores are calibrated: when it says 0.9, it’s right about nine times in ten. But that’s measured against the data you hand it. Jev can’t know the balance is three seconds old or the risk signals came from last night’s batch. Give it stale data and you get a confident answer about a world that has already moved on. It won’t land in the “review the middle” band, because from the model’s side nothing looks uncertain. The confidence score catches ambiguity. It can’t catch stale data.
At speed, that shows up as two agents spending the last of the same budget, a hold that lands after the item shipped, or a fraud check that approves the fourth transaction because it only saw the first three. Under concurrency, those aren’t edge cases.
Each pressure has a standard fix, and each fix makes the other one worse.
Fix volume with copies, and freshness suffers. Caches and read replicas absorb load by serving data that’s slightly old. The more load you push onto them, the more decisions read the old version.
Fix freshness with pipelines, and the copies multiply. Streaming jobs keep computed signals fresher, but each one is another system with its own copy and its own lag. A decision that reads a balance from the cache, a signal from the stream and similar cases from a vector index is combining three moments that never lined up.
At human speed that rarely mattered. At Jev speed, it’s the main way decisions go wrong. That’s the context gap: acting on data that is incomplete, inconsistent or out of date at the moment of the decision. We cover it in more depth in why AI agents act on the wrong context.
Here’s what a Jev decision looks like in practice, using the Pydantic AI integration: a refund request that gets approved, held or denied. The model call is the short part. Most of the code is reading the state and writing the decision back.
from typing import Annotated, Literal
import psycopg
from psycopg.types.json import Json
from pydantic import BaseModel, ConfigDict
from pydantic_ai import Agent, BoolCriteria
class RefundDecision(BaseModel):
"""Decide what to do with a refund request."""
model_config = ConfigDict(use_attribute_docstrings=True)
action: Literal['approve', 'hold', 'deny']
"""What should happen to this refund?"""
abuse_risk: Annotated[bool, BoolCriteria(
true='The pattern looks like refund abuse.',
false='The pattern looks like a normal customer.',
)]
"""Does this look like refund abuse?"""
agent = Agent('typesafe:jev-latest', output_type=RefundDecision)
# Every value here, including refunds approved a second ago, must reflect now.
STATE_SQL = """
SELECT c.account_age_days,
o.amount,
o.status AS order_status,
(SELECT count(*) FROM refund_decisions d
WHERE d.customer_id = c.id AND d.action = 'approve'
AND d.decided_at > now() - interval '30 days') AS refunds_30d,
(SELECT coalesce(sum(d.amount), 0) FROM refund_decisions d
WHERE d.customer_id = c.id AND d.action = 'approve'
AND d.decided_at > now() - interval '24 hours') AS refunded_24h
FROM orders o JOIN customers c ON c.id = o.customer_id
WHERE o.id = %s
"""
def decide_refund(conn, order_id, customer_message):
# 1. Read the state.
with conn.cursor() as cur:
cur.execute(STATE_SQL, (order_id,))
cols = [d.name for d in cur.description]
state = dict(zip(cols, cur.fetchone()))
# 2. Decide.
result = agent.run_sync(f'Account state: {state}\nCustomer says: {customer_message}')
decision = result.output
confidence = result.response.provider_details['confidence']
# 3. Write the decision back, where the next read will see it.
with conn.cursor() as cur:
cur.execute(
"""INSERT INTO refund_decisions
(order_id, customer_id, amount, action, abuse_risk, confidence, decided_at)
SELECT o.id, o.customer_id, o.amount, %s, %s, %s, now()
FROM orders o WHERE o.id = %s""",
(decision.action, decision.abuse_risk, Json(confidence), order_id),
)
conn.commit()
return decision, confidence
Three things in that function decide whether Jev’s answer is right, and none of them are in the model call.
The counts have to include the last second. refunds_30d and refunded_24h read decisions this same function wrote moments ago, possibly from another worker handling the same customer. If they come from a cache or a nightly rollup, a customer who fires five refund requests in parallel looks like a first-timer five times, and Jev approves all five with high confidence.
Every value has to come from the same moment. The order status, the account and the refund totals only make sense together if they reflect the same set of events. Split them across a replica, a feature store and a cache, and the state object describes a moment that never happened.
The read has to hold up at Jev’s volume. This query is trivial once. Run it on every refund, every ticket and every tool call, with the aggregates computed against data that changes on every decision, and it’s the part of the system that has to scale.
The SQL runs against any PostgreSQL-compatible database. What changes from one system to another is whether it still returns current, consistent answers when thousands of these functions run at once.
To get the most out of a model like Jev, the data underneath has to handle volume and velocity in one place:
Reads at the pace of the decisions. Lookups, aggregations, search and vector retrieval served together at machine-scale concurrency, so gathering the data doesn’t take longer than deciding on it.
Current sub-second behind the write. Computed signals such as rolling spend or transaction counts update within a second of the change underneath them. Many don’t need precomputing at all and can be computed on read against the latest committed data.
One consistent view per decision. The balance, the signals and the retrieved cases behind one Jev call all reflect the same set of events.
A place to write the decision back. Verdicts, holds, per-agent limits and review queues held in the same system with transactional guarantees, so two agents can’t both commit against the last of the same limit. That’s why ACID matters for agents.
This is the job the Tacnode Context Lake™ was built for. It holds the decision context: everything a decision reads and everything it decided, current and in one snapshot. Source data arrives from the systems you already run through change data capture (CDC) or streams. Decisions are written straight to it and become context for the next one. It presents the PostgreSQL wire protocol, so the data behind a Jev call is a SQL query away. See how it works.
Jev solves a real problem: AI decisions that are fast, cheap and always in the right format. Teams will put it in places no model has run before.
Every one of those places has an input, and the model trusts it completely. The teams that get the most out of Jev will be the ones whose data can keep up: more reads and writes than they’ve ever served, on data that changes as fast as the decisions do.
Former Cockroach Labs. Tells stories about infrastructure that actually make sense.
Fresh Context Newsletter
The argument behind the posts — what breaks when AI acts on stale data, from the team building the Context Lake. About twice a month.
Book a demo and discover how Tacnode can power your AI-native applications.
Book a Demo