Stackable Labs

Blog · September 28, 2026

Meet Jev: why decisioning engines are the missing layer for agents that act

A new kind of AI makes typed decisions instead of writing text, and it fills in the missing piece of the stack: a decision layer underneath, a brain in the middle and a stage on top.

By Adam Grohs, Co-Founder / Head of Product - Stackable Labs

Share

For three years, the AI conversation has mostly been one long argument about which chatbot is smartest. Bigger context, better benchmarks, a new model name every other Tuesday. (We read the launch posts too. All of them. Send help.)

Meanwhile, something genuinely different showed up, and it doesn't talk at all.

Meet the decisioning engine

On September 15, TypeSafe AI introduced "System One Models", which it describes as "a new class of frontier models built to make fast, structured decisions that software can use directly." The first one is called Jev, and TypeSafe's one-line definition is the best summary I've seen: "unstructured state in, typed probabilistic decisions out."

The name is a nod to Daniel Kahneman's Thinking, Fast and Slow: fast, intuitive System 1 thinking versus slow, deliberate System 2. Large language models are the deliberate, wordy part of that pair. Jev is the snap judgment.

A few things make it a different animal from the LLMs we're all used to:

  • It returns values, not prose. You define the possible outputs and their structure in advance. Jev answers inside that structure, every time.
  • Every answer comes with a number. In TypeSafe's words, "all answers are accompanied with calibrated probabilities and confidence scores."
  • It's built for software, not for chatting. TypeSafe pitches it for jobs where outputs "classify, route, score, extract, or branch," and calls those "smart if-statements": "Structured outputs slot into ordinary software as fuzzy decision rules."
  • It gave up writing on purpose. "While Jev gives up string generation, it's optimized for structured outputs and can't hallucinate." TypeSafe also claims big speed and cost advantages over LLMs on these kinds of questions. Those are vendor numbers, so test them on your own workload.

Jev is in early access, with developers being let in from a waitlist. Early days. But the category is the news. I've started calling it what it is: a decisioning engine. LLMs handle language and reasoning. A decisioning engine handles the fast, typed calls that software acts on.

Most of an agent's job isn't talking

Think about what actually happens when a customer types "my order arrived damaged."

Before any reply goes out, a whole chain of small decisions has to get made. Is this order eligible for a replacement or only a refund? Is the customer frustrated, or just being efficient? Is this a fraud pattern? Does it route to the AI agent, the returns team or a supervisor? Which of the three actions we offer is the right one to put in front of this person?

None of those answers are paragraphs. They're a yes or no, one of five labels, a score. Today most teams get them by asking an LLM to write something and then parsing the text back into a decision, which is a bit like hiring a novelist to fill out a checkbox form. It works, mostly. It's slow, it's pricey at volume, and sometimes the novelist gets creative with the checkbox.

That's the gap a decisioning engine fills. And once you see it, the shape of an agent that acts gets a lot clearer.

Three layers: decide, reason, perform

Here's how we think about the stack now:

1. Decide (underneath). Fast, typed, scored decisions: eligibility, intent, routing, risk, next best action. The customer never sees this layer. It just needs to be quick, consistent and impossible to get off-menu.

2. Reason (the middle). The LLM and the AI agent. This is the brain of the conversation: understanding what the customer actually said, deciding which tools to call, and explaining what happened in plain language. Zendesk's AI agents live here, and they're getting very good at it.

3. Perform (on top). The stage. Where the customer sees the order, the options and the amount, and confirms the action with a real control instead of typing a magic word. This is the layer we wrote about in Beyond the FAQ bot, and it's the one that's still missing from most messengers.

Each layer is good at something the others aren't. Ask an LLM to make every snap call and you pay for prose you throw away. Ask a decisioning engine to hold a conversation and you get, well, nothing, because it doesn't talk. Skip the stage and you get a brilliant agent reading a wall of text to your customer.

Confidence scores deserve a stage

This is the part that gets me genuinely excited.

A typed decision with a calibrated confidence score isn't just useful to the code. It's a design input. It tells the interface how much to trust itself:

  • High confidence, low stakes: show the answer and a one-tap action. "Your replacement is ready to ship. Confirm."
  • High confidence, high stakes: show the exact items, amount and date, then wait for an explicit confirmation. The decision can be confident and still wrong.
  • Low confidence: don't guess. Show the two or three likeliest options as buttons, and make Talk to someone one of them.

That last point matters. A model that "can't hallucinate" in TypeSafe's sense can't invent an answer outside the options you defined. It can still pick the wrong option. Typed outputs make the decision reliable to consume. They don't make it right. The customer confirming on a clear, branded screen is still how you catch the difference.

So the stage isn't decoration. It's where the decision layer's uncertainty gets turned into a better experience instead of a confident mistake.

Where Stackable fits

Stackable is the top layer. The decision layer and the reasoning layer are yours to choose: your models, your rules, your Zendesk AI agent. Stackable extensions give all of it a stage right next to the Zendesk messenger:

  • Bring in the decision. Extensions call your systems through data.fetch, a proxied, allowlisted request with API keys injected server-side. If your backend asks a decisioning model "replace or refund?", the extension shows the answer, and the confidence behind it, as UI.
  • Let the customer confirm. Real components (cards, badges, radio groups, buttons), themed to the brand automatically.
  • Leave a receipt. messaging.send posts the confirmation, a label or a carousel into the conversation, so the AI agent's next turn and any human who picks up the thread see what happened.
  • Hand off with the decision attached. actions.invoke can start a new conversation with tags, custom fields and metadata already set. A low-confidence call can route to a person with the reason already on the ticket.
  • Listen to the conversation. With events:messaging, an extension can react when a customer taps a postback button and open the right view.

Every extension runs in a sandbox, declares its permissions up front, and goes through a scan and review before it hits the marketplace. If decisions are going to move money and merchandise on your customers' behalf, the code that shows them should be held to that standard.

The headliner needs a crew

Agents that act are going to be built from more than one kind of AI. A fast decisioning engine underneath, a reasoning brain in the middle, and a stage on top where the customer can actually see what's happening and say yes.

The industry spent three years upgrading the brain. Now the crew is showing up. Make sure there's a stage for them to take.

If you want to see what that top layer looks like in a real messenger, see it in action. If you're building, the developer docs go from create to a live preview in minutes, and Stackable Messaging is free to get started.