What breaks when you put Jev in an agent workflow?

Jev shipped with two integrations that put it inside an agent loop rather than beside one: a model in Pydantic AI and a classifier plus middleware in LangChain.

Reading both against TypeSafe’s own jaggedness page, the same pattern appears three times. Work that the language model used to absorb quietly now has to live in your loop.

Where does Jev sit in an agent workflow?

At the decision points, with a language model still doing the open-ended work.

LangChain’s harness write-up shows two placements. A routing step defines several model choices with criteria and instructs Jev to choose the least costly model that can complete the task, selecting on the latest user message. An AutoModeMiddleware uses Jev to check tool calls for risky decisions and block calls before the tool executes.

Pydantic AI takes the model-shaped route. TypeSafeModel('jev-latest') is passed to an Agent with a Pydantic output type, and each field’s docstring becomes the question Jev answers. Confidence per field arrives in provider_details['confidence'].

One turn of an agent loop with a Jev gate

Show as text

One turn of an agent loop with a Jev gate. Sequence diagram between Agent loop and Jev. 1. Agent loop to Agent loop: Project state for this decision. 2. Agent loop to Jev: POST /v1/systemone. 3. Jev to Agent loop: typed answers with probabilities. 4. Agent loop to Agent loop: Compare confidence to your threshold. 5. Agent loop to Agent loop: Record the action in the executed ledger.

#	From	To	Message
1	Agent loop	Agent loop	Project state for this decision. Filter in code. Irrelevant context costs accuracy.
2	Agent loop	Jev	POST /v1/systemone. State plus every question you need about it.
3	Jev	Agent loop	typed answers with probabilities
4	Agent loop	Agent loop	Compare confidence to your threshold. Below it, hand the decision to a language model.
5	Agent loop	Agent loop	Record the action in the executed ledger. Jev may propose the same tool again next call.

Both placements share a property worth naming. The decision is made from a state you assembled, about an option set you fixed before the call, and the model returns a probability over that set. Nothing about the loop’s history reaches it unless you put it there.

Why does a Jev workflow always need a language model?

Because the output space has no strings in it.

Pydantic AI states the consequence directly: Jev does not write text, so a route with a str field escalates to a language model. TypeSafe’s jaggedness page is blunter, saying the model is not trained to generate text and that forcing it produces poor and slow results.

In an agent loop this bites at the first free-form tool argument. A gate deciding whether to run bash is a bounded decision Jev answers well. Deciding what command to run is a generation problem, and no amount of question modelling turns it into a choice among 255 named options unless the command set genuinely is that small.

The practical shape is two models with a clear division. The language model plans, writes arguments and explains. Jev answers the bounded questions along the way: is this risky, which route, how severe. Designing as though one model can cover both ends with an escalation path you did not plan for.

What threshold should gate a Jev decision in a workflow?

One you fitted yourself, because nobody has published a defensible default.

Pydantic AI exposes decision_route_threshold for handing uncertain decisions to a fallback language model, and decision_boolean_threshold for boolean fields. LangChain’s write-up describes the tool-call gate and the router without naming any threshold at all.

The reason a default cannot be borrowed is what the number measures. As covered in how Jev’s question types report confidence, confidence is derived from the probability distribution and describes how concentrated the mass was. A confident answer is one the model was not torn about, which leaves correctness open.

So the threshold is a spread cutoff being used as a correctness proxy, and the mapping between them is a property of your data. Bucket your own decisions by reported confidence, measure how often each bucket was right, and set the cutoff from that. Skipping it means every escalation boundary in the workflow sits at an arbitrary point.

Why does Jev re-propose a tool the workflow already ran?

Because the model answers a question about the state you sent and holds no concept of turn progress.

Pydantic AI lists this among its documented failure modes: once a tool executes, Jev may propose it again until the next turn. That is unsurprising given the architecture. The question “which action should run next” is answered from the state, and if the state does not record that the action already ran, the same answer stays correct by the model’s reading.

What a Jev workflow owns against what Jev owns

Show as text

What a Jev workflow owns against what Jev owns. Diagram: 8 ordered layers. Response matches the schema you asked for, then Every answer carries a probability, then All questions answered in one parallel pass, then Jev above, your code below (breakpoint), then Which actions have already executed, then Which fields of state each question needs, then The threshold that escalates to a model, then Arithmetic, counting and date ordering.

#	Layer	Note
1	Response matches the schema you asked for	Guaranteed by construction.
2	Every answer carries a probability	Choice and score add a confidence.
3	All questions answered in one parallel pass	Adding questions barely moves latency.
·	Jev above, your code below (breakpoint)
4	Which actions have already executed	The model has no notion of turn progress.
5	Which fields of state each question needs	Accuracy falls with irrelevant context.
6	The threshold that escalates to a model	No defensible default is published.
7	Arithmetic, counting and date ordering	All three documented as unreliable.

A language model in the same position usually avoids this because the tool result is in its context and it reads the transcript as a sequence. Jev reads a payload. The fix is a ledger in your loop: record what executed, then remove those options from the next question’s option set rather than hoping the probability shifts.

This generalises. TypeSafe’s jaggedness page also says structural invariants across separate questions are not guaranteed, so two questions that logically exclude each other can both come back affirmative.

How much agent state can a Jev workflow send?

Less than a transcript, and less than the limit suggests.

The hard numbers are 64k tokens per request and 32k for state plus the longest question, per the Pydantic integration and TypeSafe’s models page. A loop that appends tool results crosses 32k quickly on anything involving file contents or search output.

The softer limit binds earlier. The jaggedness page says accuracy falls as the state grows with content unrelated to the decision, and recommends retrieving and filtering in code so you send only the fields the question needs. An agent transcript is the opposite shape, since it grows monotonically and most of it is irrelevant to any single decision.

That makes state projection a required step rather than an optimisation. For each question, assemble the minimum payload that could answer it. LangChain’s router selecting on the latest user message is exactly this move, and it keeps the call small as well as accurate.

How would you structure a Jev workflow today?

My read is that Jev belongs at gates and routers, with the loop keeping its own bookkeeping, and that the cost of adoption is mostly in that bookkeeping rather than in the integration.

Three things move into your code the moment you swap a language model decision for a Jev one: the executed-action ledger, the per-question state projection, and the escalation threshold. All three were previously handled by the language model reading a transcript, imperfectly and for free.

Against that, the gains are real and narrow. A gate that costs $0.042 per million input tokens with free output and answers in hundreds of milliseconds changes what you can afford to check. Checking every tool call becomes cheap enough to be the default rather than a sampled audit.

What I would avoid is treating the integration’s defaults as a design. The threshold, the projection and the ledger are the design, and the API call is the easy part.