In September 2026, a startup founded by one of the researchers behind ChatGPT's training method launched an AI model that cannot chat, write code, or draft an email. Jev only answers questions you define in advance, with probabilities. Developers loved it almost immediately. Here is the Jev story, how it actually works, what its headline numbers do and do not prove, and how I would use a decision model inside a production agent.
Research and product status checked October 31, 2026.
Most of What an Agent Does Is Not Writing
Imagine a coding agent about to run a shell command.
Before executing anything, the harness asks a frontier model a simple question: is this command safe to run without a human?
The model replies with a paragraph. "This command is generally safe for a build directory, although it is worth noting that rm -rf permanently deletes files, so you may want to double-check the path before proceeding."
Now your code has to turn that paragraph into a decision.
Someone writes a parser. It looks for the word "safe." It finds it. The command runs.
That is a real class of bug, and it is not the model's fault. The model was asked a yes-or-no question and answered like a careful colleague. The software needed a boolean and a confidence level. It got prose.
There is a second problem hiding in the same call. The agent probably makes this kind of decision hundreds of times per task: which tool, which model, which skill, is this result good enough, does this need a human, is this input malicious. Each one waits for a frontier model to generate tokens one at a time, and each one is billed like a conversation.
Most of what an agent does all day is not writing.
It is choosing.
On September 15, 2026, a San Francisco startup called TypeSafe AI came out of two years of stealth with a model built for exactly that. It is called Jev. It does not generate text at all. You give it some state and a set of typed questions, and it returns structured answers with calibrated probabilities. TypeSafe calls it the first "System One model," borrowing Daniel Kahneman's term for fast, intuitive thinking.
The CEO, Diogo Almeida, is a former OpenAI researcher credited as a co-inventor of reinforcement learning from human feedback, the training technique behind ChatGPT. The company announced a $40 million seed round led by DCVC. Within days, developers were posting demos, the service briefly ran out of capacity, and TechCrunch described the model as "thrilling developers."
The excitement is justified. The reason is more interesting than speed.
Jev's real innovation is not that it is fast or cheap. It turns an AI judgment into a typed, priced, measurable probability. That makes decisions much easier to engineer, and it moves the hardest question, how much probability is enough to act, squarely onto you.
TL;DR
- Jev is a decision model, not a language model product. It cannot chat, write code, or produce prose. It answers developer-defined questions with choices, yes/no probabilities, or positions on a scale.
- The founding team has serious pedigree. CEO Diogo Almeida co-invented RLHF at OpenAI. CTO Erik Gafni came from genomics companies Invitae and Freenome. COO Sasha Sheng was a research engineer at Meta and FAIR. The company was founded in 2024 and spent about two years in stealth.
- "System One" is the product thesis. Large language models are excellent slow, deliberate System Two thinkers. Software also needs fast, cheap, intuitive judgments, the kind TypeSafe describes as "smart if-statements."
- The training target is calibration. TypeSafe says Jev is trained with Reinforcement Learning for Calibrated Decisions, aiming for probabilities that mean what they say: answers given at 0.8 should be right about 80 percent of the time.
- The economics are the hook. TypeSafe lists $0.042 per million input tokens with free output and claims 70 to 500 milliseconds end to end. Those are vendor numbers, but they change what is reasonable to call on every agent step.
- The headline benchmarks come with the vendor's own caveats. TypeSafe's "up to 193x faster" and "about 444x cheaper" figures are high-end results on workflows its own team designed. The company says so. Treat them as upper bounds, not expectations.
- "Cannot hallucinate" means the format is guaranteed, not the answer. Jev cannot invent an option you did not declare. It can still choose the wrong one with high confidence.
- Calibration is a population property. A calibrated 0.9 is right about 90 percent of the time across many similar answers. It tells you nothing certain about this answer, and calibration on the vendor's data does not guarantee calibration on yours.
- Early users report real wins and real trade-offs. Vercel reportedly replaced an OpenAI model for command-safety classification and got results five to 18 times faster. Another early tester found Gemini slightly more accurate but 10 to 20 times more expensive.
- The category is now bigger than one startup. OpenAI announced its own Decisions API at DevDay on September 29 and has since made it generally available. Typed AI decisions are becoming a standard building block.
- A probability is evidence, not permission. Use Jev to produce the signal. Use deterministic policy, asymmetric thresholds, and human review to decide what that signal is allowed to trigger.
The Jev Story So Far
Jev's launch moved quickly, so it helps to lay out what happened, in order.
| Date (2026) | What happened | Source type |
|---|---|---|
| 2024 | TypeSafe AI co-founded by Diogo Almeida, Erik Gafni, and Sasha Sheng | Launch coverage |
| September 15 | TypeSafe exits stealth, launches Jev in early access with a waitlist, announces a $40 million seed led by DCVC | Company announcement via press |
| September 16 to 19 | Coverage in VKTR, TechCrunch, The New Stack, and others; developers share demos | Press |
| Launch week | Demand briefly exceeds TypeSafe's serving capacity | TechCrunch |
| September 27 | Access opens beyond the waitlist, according to third-party reporting | Third-party |
| Late September onward | Jev appears in integrations including Vercel's AI Gateway, OpenRouter, LangChain, and MotherDuck | Integration docs |
| September 29 | OpenAI announces its own Decisions API at DevDay, later made generally available | OpenAI docs and press |
A few details from launch coverage capture the company's attitude.
DCVC general partner James Hardiman said that "TypeSafe is approaching one of the biggest remaining challenges in AI." The New Stack's headline summarized TypeSafe's view of conventional models for software automation even more bluntly: sequential LLMs are "totally useless for computers."
That is a provocative line from a company with a competing product. It is also pointing at something real.
Language models are extraordinary at producing language. A huge share of production AI calls do not need language. They need a branch.
First, Separate Generating From Deciding
Jev is easy to misunderstand because several existing tools look similar from a distance.
| Approach | What you get back | What it guarantees | What it does not give you |
|---|---|---|---|
| LLM text response | Prose | Nothing about format | A machine-usable decision without parsing |
| LLM structured output | JSON that matches a schema | The shape of the answer | A probability distribution over the options |
| LLM-as-judge prompt | A label or score, often with reasoning | Whatever your parser enforces | Calibrated confidence |
| Traditional trained classifier | A label and score | Fast, cheap inference on a fixed task | Flexibility without collecting data and retraining |
| Decision model (Jev) | Typed answers with calibrated probabilities | Answers come only from the options you declared | Correctness, or calibration on your specific data |
These are different things.
Structured outputs guarantee the format of an answer. You still get one answer, sampled from the model, with no reliable statement of how likely the alternatives were.
A decision model returns the distribution. If you ask Jev whether an email is a refund request, an invoice dispute, or something else, you do not just get "refund request." You get how much weight it put on each option.
That difference sounds small. In software, it is the difference between a value and a value you can reason about.
A label lets your code branch. A calibrated probability lets your code decide whether it is safe to branch without a human.
How Jev Actually Works
TypeSafe has shared the interface and training goals publicly, while keeping the architecture mostly private.
The interface: state in, typed decisions out
TypeSafe describes Jev as a "frontier-intelligence function call: unstructured state in, typed probabilistic decisions out."
You send:
- State: the text the decision is about, such as an email, a log excerpt, an agent's proposed tool call, or a product description.
- Questions: named, typed questions about that state.
Each question uses one of three primitives:
- Choice: pick one option from a list you supply. Third-party documentation lists a limit of 255 options. The answer includes the chosen option, a probability for every option, and a confidence value.
- Yes/no: estimate the probability that a statement about the state is true.
- Scale: place the state on an ordered scale, such as none, low, medium, high.
Jev evaluates the declared questions in parallel rather than generating tokens one by one.
A simplified request, written to show the shape rather than the exact API schema, looks like this:
{
"model": "jev-1.13",
"state": "Agent proposes shell command: rm -rf ./dist && npm run build",
"questions": [
{
"id": "deletes_outside_build",
"type": "yes_no",
"description": "The command deletes or overwrites files outside build output directories such as dist or build."
},
{
"id": "command_category",
"type": "choice",
"description": "The primary purpose of the command.",
"options": ["read_only", "build_or_test", "package_install", "network_or_deploy", "other"]
},
{
"id": "unattended_risk",
"type": "scale",
"description": "Operational risk of running this command without human review.",
"levels": ["none", "low", "medium", "high"]
}
]
}
And a simplified response:
{
"answers": {
"deletes_outside_build": { "probability": 0.04 },
"command_category": {
"choice": "build_or_test",
"probabilities": {
"read_only": 0.01, "build_or_test": 0.93, "package_install": 0.03,
"network_or_deploy": 0.01, "other": 0.02
}
},
"unattended_risk": {
"probabilities": { "none": 0.31, "low": 0.55, "medium": 0.12, "high": 0.02 }
}
}
}
There is no paragraph to parse. There is no "generally safe, although." Every field maps directly to code.
One practical detail from integration documentation matters more than it looks: question identifiers are not sent to the model. All of the meaning must be in the descriptions and options. A question called is_refund with a vague description is a vague question.
Writing good decision questions is the new prompt engineering, and it looks a lot like writing good acceptance criteria.
The thesis: System One for software
The "System One" name comes from Kahneman's Thinking, Fast and Slow, which describes fast, intuitive System 1 thinking and slower, deliberate System 2 reasoning.
TypeSafe's argument is that the AI industry has spent years building better System 2 machines: models that reason, plan, write, and explain. Software also needs the other kind. It needs judgments that are fast, cheap, consistent, and good enough to put inside an if statement.
The company's own phrase for this is "smart if-statements."
That framing places Jev between two existing options:
Hard-coded rules Jev (System One) Frontier LLM (System Two)
--------------------- ---------------------------- ---------------------------
deterministic probabilistic, typed probabilistic, open-ended
brittle on messy input handles messy input handles messy input
microseconds tens to hundreds of ms seconds or more
nearly free very cheap per call expensive per call
cannot read meaning reads meaning, picks options reads meaning, writes anything
The training goal: calibrated probabilities
TypeSafe says Jev is trained with Reinforcement Learning for Calibrated Decisions (RLCD). The name is a deliberate echo of RLHF, the technique Almeida helped invent. RLHF optimizes for human preference. RLCD optimizes for probabilities that match reality.
TypeSafe's explanation of calibration is the standard one: when Jev says 0.8 about a kind of answer, it should be right about 80 percent of the time across many such answers.
This matters because modern neural networks are often not calibrated by default. A well-known 2017 study by Guo and colleagues found that modern deep networks tend to be overconfident, and that calibration needs to be measured and corrected rather than assumed. A model trained specifically for calibration is addressing a real weakness.
The architecture: mostly undisclosed
TechCrunch reported that Jev is transformer-based, that TypeSafe says it is not an LLM, that it was trained on synthetic data, and that the company is tight-lipped about the architecture. Some outside observers suspect it starts from an open-weight language model.
For engineering purposes, the architecture matters less than the contract. What you can test is the interface, the latency, the price, the accuracy on your data, and the calibration on your data.
The Numbers, With Their Fine Print
Jev launched with eye-catching figures. To TypeSafe's credit, it published caveats alongside them.
Speed and cost claims
TypeSafe lists:
- $0.042 per million input tokens, with output tokens free;
- 70 to 500 milliseconds end-to-end latency; and
- in its internal workflow evaluations across security alerts, invoice processing, agent reviews, and customer service, results up to 193 times faster than Claude Sonnet 5 and about 444 times cheaper than Claude Opus 5.
The company's own caveats, as reported at launch:
- those figures are high-end results, not typical ones;
- TypeSafe's team designed the workflows, which may introduce bias;
- reference answers were built by averaging OpenAI's GPT-6 Astra and Anthropic's Fable 5.1; and
- "zero hallucination" means outputs are guaranteed to match the declared schema, not that answers are error-free.
That last caveat deserves emphasis. The headline "cannot hallucinate" is true in a narrow, useful sense. Jev cannot invent a category that does not exist in your list. It can still choose the wrong category.
Early user reports
TechCrunch reported two early experiences that are more useful than any benchmark chart, because they show trade-offs:
- Vercel used Jev to classify commands for safety, replacing an OpenAI model, and reported results five to 18 times faster with greater accuracy.
- Bryo AI's CTO tested it on classifying business emails and found Gemini slightly more accurate, but 10 to 20 times more expensive.
That second result is exactly the kind of decision teams will face. A decision model does not need to be the most accurate option to be the right option. It needs to be accurate enough for the threshold you set, at a cost and latency that let you call it everywhere.
Armin Ronacher, CTO of Earendil, gave TechCrunch the most important critique: "At the end of the day, it delegates the hallucination problem a little bit to the user."
He is right. That is also the point.
What the demos show
Launch demos included a bot playing Doom by making about ten structured queries per second, at roughly $7 per hour, and a Wikiracing navigation challenge. Developers also previewed fast browser automation using Jev for step-level decisions.
These are demos, not production evidence. They do show the design intent: many small decisions, made continuously, cheaply enough that you stop thinking about the cost of each one.
Where Jev Fits Inside an Agent
The natural architecture is a split brain: a System Two model for planning, writing, and complex reasoning, and a System One model for the constant small decisions around it.
+------------------------------+
| Frontier LLM (System Two) |
| plan, write, reason, code |
+---------------+--------------+
|
proposed step, tool call, output
v
+-----------------------------------------------------------------------+
| Decision Layer (System One) |
| route? which model/skill? safe to run? good enough? needs human? |
| typed questions -> calibrated probabilities |
+-----------------------------------+-----------------------------------+
|
v
+-------------+--------------+
| Deterministic Policy |
| rules, thresholds, limits |
+------+-------+-------+-----+
| | |
allow review block
High-value places to put a decision model:
- Tool-call risk gates. Is this command destructive? Does this API call touch production? Vercel's reported use is this pattern.
- Model and skill routing. Does this request need a frontier model, a cheap model, or a specific skill?
- Triage. Which queue, which team, which priority?
- Verification. Does this output satisfy the acceptance criteria? Does the summary contain claims not supported by the source?
- Agent monitoring. Does this trace show looping, scope creep, or an action outside the task's purpose?
- Memory write classification. Is this proposed memory a user-stated preference, an inferred fact, or instruction-like text from an external source? I covered why that matters in my article on memory poisoning.
- Spending gates. Does this purchase match the task's purpose and approved vendor list? I covered the deterministic side of that in my article on agent payments.
Notice that every item on this list is a judgment that currently costs a frontier model call, or is not being made at all because it would cost too much.
That is the real opportunity. Cheap decisions do not just make existing checks faster. They make it affordable to add checks you previously skipped.
What a Probability Does Not Prove
Decision models remove some failure modes and make others easier to miss. These are the ones I would design for.
Type-correct is not correct
A Jev answer is always one of your declared options. That eliminates parsing errors and invented categories. It does not eliminate wrong answers. Confident, well-formatted, wrong is still wrong.
The right answer may not be on the list
Decision questions assume a closed world. If none of your options fits, the model must still distribute probability across them.
Always include an escape option such as other or none_of_the_above, and treat a high probability on it as a signal to escalate, not as an error.
Calibration is measured over many answers
A calibrated 0.95 means that, across many answers at that level, about 95 percent are correct. One in twenty will still be wrong.
For low-stakes routing, that is fine. For deleting data, moving money, or changing access, one in twenty is a disaster.
Calibration on their data is not calibration on yours
TypeSafe trains for calibration on its training distribution. Your support tickets, logs, contracts, and agent traces are a different distribution. Calibration can degrade when inputs shift.
You must measure calibration on a labeled sample of your own data before trusting the probabilities for automation.
The state is still untrusted input
A decision model reading an email, a web page, or a tool output is reading content an attacker may control. Text designed to make a command look harmless, or a fraudulent invoice look routine, can shift the probabilities.
Removing the paragraph removes the parsing bug. It does not remove the injection problem.
Questions are evaluated independently
Each question gets its own answer. If one decision depends on another, such as "is it a refund?" and then "is it above the auto-approval limit?", you must enforce that dependency in your code or make separate calls.
Models change
Jev is versioned, and integrations reference pinned identifiers such as jev-1.13 alongside floating aliases such as jev-latest. A floating alias can change your probability distribution without a code change.
Pin versions for anything automated. Re-run your calibration set before upgrading.
The company is young
Jev launched in early access, briefly ran out of capacity during launch week, and is less than two months old as of this research date. That is normal for a new product. It is also a reason to keep a fallback path and avoid making a single decision vendor a hard dependency for critical workflows.
Probability In, Policy Out: The Production Pattern
The cleanest way to use Jev is to keep two jobs separate:
- The model estimates. It produces probabilities.
- Your policy decides. It turns probabilities into allow, review, or block, using rules you can read, test, and audit.
Choose thresholds from costs, not instinct
Most teams pick a threshold such as 0.8 because it feels reasonable. A better method is to compare costs.
Suppose an agent wants to run a command, and Jev returns p, the probability the command is destructive. You can auto-approve, or you can send it to a human.
Auto-approving costs nothing when the command is safe and costs C_harm when it is destructive. Human review costs C_review every time.
Auto-approve only when the expected cost of being wrong is lower than the cost of asking:
auto-approve if p x C_harm < C_review
which means p < C_review / C_harm
Now plug in realistic numbers. If a human review costs about $2 of engineering time and an accidental destructive command costs $5,000 in recovery work, the threshold is:
2 / 5,000 = 0.0004
The agent should auto-approve only when Jev estimates less than a 0.04 percent chance the command is destructive.
That result is the most important engineering insight about decision models. For high-stakes actions, the useful part of the probability scale is the extreme tail, and that is exactly where calibration is hardest to verify. You need many labeled examples to know whether 0.0004 really means one in 2,500.
For low-stakes routing, where a wrong choice costs a few seconds, the threshold can be generous. For consequential actions, deterministic rules should do most of the work and the probability should only narrow what reaches a human.
Put deterministic rules first
HARD_DENY = ("rm -rf /", "mkfs", "git push --force", "DROP TABLE")
def gate(command, answers, policy):
# 1. Deterministic rules always win.
if any(pattern in command for pattern in HARD_DENY):
return "block"
if not policy.binary_allowlisted(command):
return "review"
# 2. Escape hatches and refusals go to a human.
category = answers["command_category"]
if category.choice == "other" or category.refused:
return "review"
# 3. Cost-based threshold on a calibrated probability.
p_destructive = answers["deletes_outside_build"].probability
threshold = policy.cost_of_review / policy.cost_of_harm
return "allow" if p_destructive < threshold else "review"
The model never gets the final word on a blocked pattern. It only helps decide which of the remaining actions can skip a human.
Record every decision
If a decision can trigger an action, record it like any other control:
{
"decisionId": "dec_01JC4K...",
"timestamp": "2026-10-31T10:22:05Z",
"model": "jev-1.13",
"questionSetVersion": "command-gate-v4",
"stateDigest": "sha256:58ad...",
"answers": {
"deletes_outside_build": 0.04,
"command_category": "build_or_test"
},
"policyVersion": "command-policy-2026-10",
"threshold": 0.0004,
"outcome": "review",
"reviewer": "employee:48213",
"finalLabel": "safe",
"traceId": "4bf92f3577b34da6a3ce929d0e0e4736"
}
The finalLabel from human review is not just audit evidence. It is your next calibration dataset. Every reviewed decision tells you whether the model's probabilities are still trustworthy on your traffic.
Jev, an LLM Call, or OpenAI's Decisions API?
Jev is no longer the only way to get typed AI decisions. OpenAI announced a Decisions API at DevDay on September 29, and its guide now describes it as generally available on GPT-6 Luna, with predicate, choice, and score question types. Its guide states the same principle I would apply to Jev: "Decisions returns typed answers; your application runs any actions those answers select."
As of this research date, the published differences look like this:
| Jev (TypeSafe) | OpenAI Decisions API | Frontier LLM with structured output | |
|---|---|---|---|
| Output | Typed answers with probabilities | Typed answers with probabilities | Schema-valid JSON, usually one answer |
| Inputs | Text | Text, images, JSON | Text, images, more |
| Listed input price | $0.042 per 1M tokens, free output | $0.10 per 1M uncached tokens, free output | Varies by model; output usually billed |
| Latency claim | 70 to 500 ms (vendor) | About 10x faster than the Responses API (vendor) | Typically seconds |
| Choice options | Up to 255 (third-party docs) | 2 to 255 | Schema-dependent |
| Questions per request | Not confirmed in docs I reviewed | Up to 400 | Schema-dependent |
| Maturity | Launched September 2026 | Generally available after public beta | Mature |
All speed and price figures are vendor-published and should be checked against your own workload. The choice will usually come down to three practical questions: which one is better calibrated on your data, which inputs you need, and which vendor you are comfortable depending on.
The bigger takeaway is that the category is real. When a startup and the largest model provider ship the same primitive within weeks of each other, it is a sign that typed decisions are becoming a standard part of the AI stack.
A Practical Four-Week Pilot
Week 1: Pick one decision and label it
- Choose one decision you currently make with an LLM and a text parser, such as ticket routing, command safety, or output verification.
- Collect 300 to 500 real examples from your own traffic.
- Have humans label the correct answer for each.
- Write question descriptions as if they were acceptance criteria, and include an escape option.
Week 2: Run in shadow mode
- Call Jev, or another decision API, alongside your current method without acting on its output.
- Compare accuracy, latency, and cost against your current approach.
- Build a reliability curve: group answers by predicted probability and check how often each group was right.
- Look specifically at the cases where the model was confident and wrong.
Week 3: Enforce with a human in the loop
- Set thresholds from the cost of a wrong decision versus the cost of review.
- Put deterministic rules in front of the model.
- Auto-handle only the high-confidence, low-stakes cases.
- Route everything else to review, and capture reviewer labels.
Week 4: Harden and monitor
- Pin the model version and question-set version.
- Add adversarial examples, such as inputs written to look harmless, to your evaluation set.
- Monitor calibration drift using reviewed decisions.
- Define a fallback path if the decision service is slow or unavailable.
At the end of four weeks, you should know whether a decision model is accurate enough, calibrated enough, and cheap enough for that one decision. That is a far better basis for expansion than any launch benchmark.
Seven Questions to Ask Before Trusting a Decision Model
- How calibrated are its probabilities on a labeled sample of my data, not the vendor's?
- How does it behave when the correct answer is not among my options?
- How easily can adversarial input shift its probabilities?
- Can I pin a model version, and how will I know when the distribution changes?
- What happens to my workflow if the service is slow, rate-limited, or down?
- What data does the vendor retain from the state I send?
- Which actions am I prepared to let a probability trigger without a human?
If the answer to the last question is "anything above 0.9," the threshold is a guess, not a policy.
Final Take: The Model That Does Not Talk
For three years, the AI industry has measured progress by what models can say: better answers, better code, better reasoning, longer context.
Jev is a bet in the other direction.
It says that software does not need most of its AI calls to talk. It needs them to decide quickly, cheaply, and with an honest estimate of how sure they are. That is a genuinely useful idea, and the speed with which developers adopted it, and with which a major provider shipped a similar primitive, suggests it arrived at the right moment.
But the honest probability is only half of the system.
A model can tell you it is 96 percent sure an email is a routine invoice. It cannot tell you whether 96 percent is enough to pay it. That depends on what a mistake costs, who is accountable, and which rules no probability should ever override.
That part is still engineering.
LLMs gave software a voice.
Jev is trying to give it reflexes.
A probability is evidence. A threshold is policy. The action, and the responsibility for it, is still yours.
Sources and Further Reading
- VKTR, ChatGPT Co-Creator Launches TypeSafe AI With Jev (September 16, 2026): https://www.vktr.com/ai-platforms/chatgpt-cocreator-launches-typesafe-ai-with-jev/
- TechCrunch, A new kind of AI model from a ChatGPT inventor is thrilling developers (September 18, 2026): https://techcrunch.com/2026/09/18/a-new-kind-of-ai-model-from-a-chatgpt-inventor-is-thrilling-developers/
- Let's Data Science, TypeSafe AI Launches Jev for Structured Software Decisions (September 19, 2026): https://letsdatascience.com/news/typesafe-ai-launches-jev-decision-model-889a38c0
- The New Stack, TypeSafe launched Jev because sequential LLMs are "totally useless for computers": https://thenewstack.io/typesafe-jev-system-one/
- OpenRouter, What Is Jev? TypeSafe's Decision Model Explained for Developers: https://openrouter.ai/blog/insights/what-is-jev/
- LangChain, TypeSafe integration documentation: https://docs.langchain.com/oss/javascript/integrations/providers/typesafe
- MotherDuck, Jev (TypeSafe) integration documentation: https://motherduck.com/docs/integrations/data-science-ai/typesafe/
- eesel AI, OpenAI Decisions API: what it is, how it works, and what's new (includes Jev comparison; published by a vendor with a competing product): https://www.eesel.ai/blog/openai-decisions-api
- OpenAI, Decisions API guide: https://developers.openai.com/api/docs/guides/decisions
- Guo, Pleiss, Sun, and Weinberger, On Calibration of Modern Neural Networks (2017): https://arxiv.org/abs/1706.04599
- Daniel Kahneman, Thinking, Fast and Slow (2011).
About the Author
Suraj Khaitan - Gen AI Architect | Building scalable platforms and secure cloud-native systems
Connect on LinkedIn | Follow for more engineering and architecture write-ups
Which decisions in your agents still run through a full LLM call and a text parser? Would you move them to a decision model like Jev, and what accuracy would you need to see first?
Top comments (0)