Can Jev and an LLM Work Together in One Workflow?

Most AI workflows run on a single model. Every step goes to the same large language model, whether the task is drafting a customer reply or answering a simple question like "Is this ticket urgent?"

That setup gets expensive fast. Each small decision adds seconds of wait time and another charge on your bill. You also have to parse the text that comes back, check its format, and retry when it breaks. At a few hundred calls a day, that's a nuisance. At a few million, it can take over your AI budget fast.

The fix is to split the work between two kinds of models. Jev, the decision model from TypeSafe AI, returns typed answers with probabilities instead of text. When you pair it with an LLM, each model handles the part of the job it was built for.

Yes, Jev and an LLM can work together in one workflow. Jev handles the fast, repeated decisions, such as routing, scoring, verifying, and blocking risky actions, and returns typed answers with confidence scores. Your LLM handles the steps that need written text. Your code connects the two and decides what happens next.

• A Jev and LLM workflow uses Jev for bounded decisions and an LLM for open-ended text, with your code passing results between them.
• Jev decides and the LLM writes. Neither model has to do the other's job.
• Jev can screen most of your volume cheaply, so your LLM only sees the hard minority of cases.
• Your code owns the final action. Jev's confidence scores tell it when to act, when to escalate, and when to ask a person.

Jev and an LLM belong together because they're good at different things. In its launch post, TypeSafe positions LLMs for human-in-the-loop work like chat, copilots, and coding agents, and Jev for decisions inside software, such as classifying, routing, scoring, and verifying LLM outputs.

Here's what you gain when you combine them:

• Each model does its own job: Jev answers closed questions with a fixed set of possible answers. Your LLM writes replies, summaries, and explanations. When you split the work this way, neither model gets stretched past what it does well.
• You cut cost and wait time: TypeSafe prices Jev at $0.042 per million input tokens, with output tokens free. It reports end-to-end response times of 70 to 500 milliseconds, compared with 3 to 329 seconds for frontier LLMs in the benchmark it cites.
• You get a clear signal for handoffs: Every Jev answer comes with a calibrated probability. A low score is a simple, reliable trigger to pass the case to your LLM or a person.
• Your rules stay in your code: Thresholds, permissions, and retries live in your application, so you can change a business rule without rewriting a long prompt.

Jev and an LLM work together by passing work back and forth, with your code in the middle. Jev makes a typed decision, your code reads it, and the LLM steps in wherever text is needed. The seven patterns below cover the most common setups:

1. Jev Triages, Your LLM Handles the Hard Cases

This is the most common pattern. Jev looks at every incoming item first, and only the cases that need real reasoning reach your LLM.

Here's how it works:

• Jev classifies each item, such as a support ticket, email, or chat message, and scores it for urgency or complexity.
• Your code handles clear, simple cases directly, like tagging or routing to a queue.
• Anything complex or low-confidence goes to your LLM or a human reviewer.

Use it when you have high volume and most items are routine.

2. Jev Picks Which LLM Runs the Task

Not every request needs your most powerful model. Jev can look at a request and choose the right one before any text gets generated.

Here's how it works:

• You define a few model options, such as a fast, low-cost model and a more capable one, with plain-language criteria for each.
• Jev reads the incoming request and picks the option that fits.
• The chosen LLM runs the task. LangChain's model-routing middleware uses Jev in exactly this way.

Use it when your requests range from simple lookups to complex, high-stakes work.

3. Your LLM Writes, Jev Checks the Answer

In this pattern, the LLM goes first. Jev then acts as a fast, low-cost reviewer of what the LLM produced.

Here's how it works:

• Your LLM drafts an answer, summary, or reply.
• Jev checks the draft against your criteria. For example, a yes/no question (TypeSafe calls this type a Noul) can test whether each claim is supported by the source.
• Drafts that pass move on. Drafts that fail get flagged, retried, or sent to a stronger model or a person.

Use it when accuracy matters and you want every LLM output reviewed without doubling your costs.

4. Jev Guards Your Agent's Actions

LLM agents can take actions, like running commands or editing files. Jev can check each proposed action before it runs.

Here's how it works:

• Your LLM agent proposes a tool call.
• Jev scores the call for risk, such as deleting data or leaking secrets.
• Your code blocks risky calls or asks for approval before they execute. LangChain's AutoModeMiddleware follows this pattern.

Use it when your agent can touch production systems, files, or customer data.

5. Your LLM Prepares the State, Jev Decides

Some inputs are too messy for a quick decision. Here, the LLM cleans up the input first, and Jev makes the call.

Here's how it works:

• An LLM or vision model turns raw input, like a long thread or an image, into clean, focused text.
• Jev answers several policy or classification questions about that text in a single call.
• Your code applies thresholds to decide what happens next.

Use it for moderation, compliance checks, or any review of unstructured content.

6. Jev Decides, Your LLM Explains

Jev can't write, but your users often need a readable answer. The LLM turns Jev's decision into plain language.

Here's how it works:

• Jev returns a decision along with its probabilities.
• Your code passes that decision, plus the relevant context, to your LLM.
• The LLM writes a short explanation or reply for the person who needs it.

Use it when people act on the decision and need to understand it.

To build a Jev and LLM workflow, you sort your steps into decisions and text, send the decisions to Jev, and let your code hand the rest to your LLM. Follow these six steps:

Step 1: Split Your Workflow Into Decisions and Generation Steps

Start by mapping your current workflow on paper or in a spreadsheet, so you can see exactly where Jev fits.

Here's how to do it:

• Write down every step the workflow takes, from the moment input arrives to the final action.
• Mark a step "decision" if it picks from known options, rates something on a scale, or answers yes or no.
• Mark a step "generation" if it writes, summarizes, or explains anything in words.
• For each decision step, note which Jev question type fits: Choice to pick one option, Score for ordered levels, or Noul for yes or no.

Following this step gives you a clear map of which work moves to Jev and which stays with your LLM.

Step 2: Clean and Trim the State Before It Reaches Jev

Next, prepare the input you send Jev, which TypeSafe calls the state. Jev answers more accurately when the state is short and focused.

Here's how to do it:

• Strip out anything unrelated to your questions, such as email signatures, legal footers, or old messages in a thread.
• Do any math, counting, or date comparison in code first, then send Jev the result. For example, send "invoice is 45 days overdue" in place of two raw dates.
• If the state comes from a long LLM transcript, have your LLM summarize it first and keep the summary well under Jev's 32,000-token state limit.

Following this step gives Jev only the facts it needs, which improves its accuracy on every question you ask.

Step 3: Write Typed Questions and Ask Them All in One Call

Now write the questions Jev will answer. Jev evaluates every question in a request at once, so group them together.

Here's how to do it:

• Give each question a short ID for your code, such as is_urgent or category.
• Write the full question in the instructions field, since the ID isn't sent to the model.
• For Choice and Score questions, add a one-line description for each option or level so Jev knows where the boundaries are.
• Put every independent question you might need into one request, even ones that only matter for some inputs.

Step 4: Set Confidence Thresholds in Code

Jev returns a probability with every answer. Your code decides what each probability means.

Here's how to do it:

• Set an "act automatically" cutoff for each decision, such as 0.9 and above.
• Set a middle band, such as 0.6 to 0.9, that sends the case to your LLM for a closer look.
• Send anything below the middle band, or anything high-risk, to a person for review.
• Store your cutoffs in a config file so you can adjust them without changing your code.

Following this step turns Jev's raw probabilities into clear, predictable actions you can tune for cost and accuracy.

Step 5: Pass Jev's Answers to Your LLM as Context

When a case reaches your LLM, include everything Jev already decided, so the LLM only has to write.

Here's how to do it:

• Add Jev's answers and probabilities to the top of the LLM's prompt, such as "Category: billing (0.94). Urgent: yes (0.97)."
• Tell the LLM which decisions are final and shouldn't be revisited.
• Give the LLM one narrow task, such as "Draft a reply that acknowledges the urgency and explains the next step."

Following this step keeps your LLM prompts shorter and more focused, which lowers cost and keeps its output consistent with Jev's decisions.

Step 6: Test the Full Workflow Against Labeled Examples

Before you go live, test the combined workflow on real data, since an error in one model carries into the other.

Here's how to do it:

• Pull 100 to 200 real examples and record the correct outcome for each.
• Run them through Jev alone, your LLM alone, and the full combined workflow.
• Compare accuracy, total cost, and escalation rate for each setup.
• Adjust your thresholds from Step 4, then pin the Jev version you tested with, such as jev-1.13.0, so a future release doesn't change your results.

Following this step shows you how the workflow performs on your own data, so you can launch with numbers you trust.

The pairing works well, but every handoff between the two models adds a place where things can go wrong. Plan for these before you go live:

• A wrong route hides hard cases: Jev can still pick a wrong answer from your allowed options. If that happens at the triage step, your LLM never sees the case that needed it.
• LLM output can be too long for Jev: Jev accepts up to 32,000 tokens of state on the current version, according to Pydantic AI's Jev docs. Long LLM transcripts must be compacted first, and that summary has to come from an LLM, since Jev can't write.
• Injected text can move Jev's answer: Instructions hidden in user input or LLM output can steer Jev. Keep deterministic checks in place alongside any Jev guardrail.
• Explanations can drift from the decision: Jev doesn't explain its reasoning, so when your LLM explains a Jev decision, it's giving its own interpretation. Label these explanations accordingly in high-stakes settings.
• Thresholds need ongoing tuning. Your escalation cutoff decides how much work reaches the LLM. Set it too low and you miss errors. Set it too high and your costs climb back up.
• Model updates on either side can shift results. The jev-latest alias moves with each release, which can change the numbers behind a threshold you've tuned. Pin a specific Jev version once your thresholds are set, and retest whenever you update either model.

PromptQL gives you a place to run this pattern without building the plumbing yourself. You spin up a multiplayer bot for a piece of work, connect it to your data, and invite the teammates who know the context. Each bot runs around the clock on its own computer and only uses the permissions of the person asking.

In workspaces where it has been provisioned, PromptQL can use its Jev integration for the high-volume decisions in a task. The bot sends the bulk classification to Jev and saves LLM generation for the steps that need written output.

Here's what that looks like in practice:

• You describe the goal in plain English. The bot works out which steps are decisions and which need text.
• Jev screens the volume. It classifies, scores, and flags items in bulk with confidence scores attached.
• The LLM writes the output. It turns Jev's decisions into shortlists, summaries, drafts, or dashboards built inside a multiplayer AI thread.
• Your team reviews in one thread. Everyone sees the same work and corrects what they know is wrong.

If you want to try it yourself, join one of the Jev Workshops or start a bot in PromptQL.

The bigger change here is how you design workflows. Once a decision costs a fraction of a cent and takes under a second, you can afford to check far more things than before: every ticket, every agent action, every claim in every summary. TypeSafe named Jev after William Stanley Jevons for this reason, since cheaper resources tend to get used far more widely.

Start with decisions. Map the questions your workflow asks over and over, hand those to Jev, and keep your LLM for the moments where words matter. The teams that design this way first will be able to automate work that was too expensive to automate before.

What does it mean for Jev and an LLM to work together in a single workflow, and what roles does each play?

Jev is the deterministic orchestrator that owns the Execution Blueprint, a source code plan that controls every step, route, and conditional. It never decides the workflow path.

How does plan-based execution enable a deterministic agent and an LLM to collaborate reliably on data tasks?

The plan is coded in YAML with Jinja2 routing templates that resolve deterministically before any LLM is called. The agent fetches and filters the exact data context specified in the blueprint, then hands that bounded, pre-verified context to the LLM. The LLM works on what it is given, not what it retrieves.

What security and governance benefits exist when a deterministic agent works alongside an LLM in an enterprise workflow?

The LLM never accesses a data source directly. The deterministic orchestrator enforces strict context isolation using explicit, last_only, or accumulate modes. This architecture avoids the CI-Work benchmark's recorded privacy violations of 15.8% to 50.9% because the model cannot leak data it was never given permission to see.

What are the practical steps for setting up a workflow where a deterministic agent and a reasoning LLM share context?

To build a blueprint-first workflow:

1. Define your multi-step workflow as a YAML blueprint.
2. Declare each LLM task as a named agent step with a specific prompt, model, and context mode.
3. Use Jinja2 expressions for deterministic conditional routing between steps.
4. Add script steps for non-LLM tasks.
5. Deploy and monitor the entire workflow via a real-time dashboard.

How does an Agentic Semantic Layer help an LLM and AI agent work from the same business language?

It maps natural language business intent, like 'Q3 pipeline by region,' directly to the declared entities and schemas in your Execution Blueprint. This gives both the deterministic agent and the bounded LLM call a single, shared schema to operate on, preventing the model from hallucinating connections or guessing table names.

How do businesses measure accuracy and cost when running AI agents and LLMs together in production?

Blueprint-first workflows let you measure success across three dimensions:

• Accuracy: measure by final pass rate on complex, multi-step benchmark tasks (like the 35.56% TravelPlanner result).
• Cost: measure by tracking token spend per step, with deterministic routing eliminating LLM decision-loop overhead.
• Governance: measure by logging every context boundary transfer and verifying zero sensitive data leaks across agent steps.

1. [2508.02721] Blueprint First, Model Second: A Framework for Deterministic LLM Workflow - arxiv.org
2. Conductor: Deterministic orchestration for multi-agent AI workflows | Microsoft Open Source Blog - opensource.microsoft.com
3. CI-Work: Benchmarking Contextual Integrity in Enterprise LLM Agents - www.microsoft.com
4. PromptQL | Team AI with a wiki - promptql.hasura.io