The hot potato of the weekend: Jev, from TypeSafe AI, the lab Diogo Almeida (RLHF co-inventor) took out of stealth on September 15. Jev is a "System 1 model": instead of generating text, it returns a typed decision in a single forward pass - a choice from a schema, a score on a rubric, or a calibrated yes/no probability. No autoregression, no hallucinated prose, 70-500 ms, input at $0.042 per million tokens. The pitch is 20-200x faster and 40-400x cheaper than frontier LLMs on decision-shaped work.

And the ecosystem sprinted. Within days there were LangChain harness guides, safer-agent tutorials, and use-case roundups - by this weekend, seemingly everyone with an agent harness was retrofitting Jev into it, all making the same move: take the judgment calls in your agent loop - route this intent, gate this tool call, approve this step - and hand them to Jev instead of an LLM. One LangGraph demo measured the trade honestly: 96.8% routing accuracy for Jev against 99.1% for an LLM, at a fraction of the latency and cost.

There's a subplot too. Days after Jev's launch, Laya appeared: an open-source, Apache 2.0 implementation of the same idea from Nandakishor Mukkunnoth of ConvAI Innovations, built on ModernBERT-class encoders, claiming 6-8x faster than Jev with 3x better calibration. The announcement's framing is barbed: he published the non-autoregressive decision-model concept in March 2025 and formalised the training method (RLCD) that September, a year before a frontier lab presented the same concept as a breakthrough. Jev's own materials name their training method... RLCD. I'll let readers weigh that one themselves.

So, the obvious question for anyone running an agent harness: should this go in ours?

What pi-rukas already does

pi-rukas is the Trail Openers agent harness, the current form of the orchestrator lineage this blog has written about since pi-ensemble. I spent a while this weekend checking where Jev or Laya could slot in. The answer surprised me by how small it was, and the reason is worth spelling out.

The heavy flows in pi-rukas are compiled drivers: TypeScript state machines where an issue runs end-to-end through explicit states. The work driver is literally a string-union step enum and a transition table:

export const WORK_STEPS: readonly WorkStep[] = [
  "explore", "plan", "branch", "develop", "adversarial", "commit-pr",
  "lens-review", "lens-fix", "step-back", "handoff", "ci", "merged",
];

Twelve states, 33 event kinds, 23 distinct cap conditions (review rounds, CI retries, wall clock, token budgets, loop detection), per-step failure policies (halt / retry-once / degraded-ok), and a persisted event log that is authoritative over the state snapshot. Research and planning run as the same kind of pipeline. The README says it plainly: /work is a compiled driver, not prose.

The division of labor is the whole design. Deterministic code owns every transition, every cap, every gate, and every irreversible act: git operations, PR creation, and merging happen on executed evidence (a real diff exists, typecheck and tests pass, gh pr checks is green), never on an agent's claim. LLM calls own the things that genuinely need judgment: exploring a codebase, writing the code, adversarial review, the six-lens review. And when an LLM answers, it doesn't answer in prose that code then trusts: verdicts come back through schema-validated tool calls or through parsers whose core rule is that a marker that fails to parse is "absent", never "approved". An unparsed verdict at the cap becomes an infrastructure retry, not a pass.

One precision that matters: this is deterministic control flow, not deterministic outcomes. The LLM still decides whether the diff passes adversarial review. What it cannot do is decide what happens next with that verdict, skip a gate, extend its own budget, or rewrite the rules it's judged by (policy prose is read at base SHA precisely so a cycle can't self-grant). The machine consumes typed values; it does not take advice.

None of this was built for aesthetics, and the doctrine for when to build it is written down in the repo: compile a flow when the steps are enumerable, a repeated incident class exists where LLM improvisation was the failure source, and a mechanical gate can catch the failure; keep prose when the shape is judgement-driven. Every compiled driver traces back to numbered incidents. The research behind that doctrine leaned on MAST, the 1,642-trace taxonomy of multi-agent failures this blog has cited before: 41.8% of failures are system-design issues, and fixing the structure - role specs, a verification step - moved task success by +9.4% and +15.6% on the same model with the same prompt. Structure is a design variable, not a model capability. That is the whole bet the drivers make.

Why a decision model has almost nothing to add here

Now look at what the weekend's Jev tutorials use it for: should this request route to the cheap model? Is this tool call risky? Should the loop continue or stop? Has the agent finished?

In pi-rukas, essentially none of those are model calls. Which model handles which role is configuration. Whether a tool call is permitted is a guard, a hook that fires on the tool-call event and refuses, in any trust mode. Whether the loop continues is the transition table plus caps. Whether the work is done is executed evidence. Replacing an LLM judgment call with a 30 ms calibrated classifier is a real improvement - 96.8% at near-zero cost is a good trade against 99.1% at LLM prices for high-volume routing. But a transition table is 100% at zero milliseconds, with calibration that isn't a metric because there is no probability involved. You cannot beat code at being code.

And the first independent measurements of Jev, out within days of launch, back the code side harder than I expected. One hand-labelled tool-call-risk benchmark found Jev is not deterministic: identical input flipped the label on 1.7-3.3% of items. The same study noted the "zero hallucinations" claim is trivially true of any schema-constrained decoder - all 1,800 of its GPT-class calls under a strict JSON schema were "hallucination-free" in exactly the same sense. A multi-suite quality benchmark put Jev mid-pack on accuracy (76.3% on a 77-way intent task, behind two LLMs) and found the vendor's 193x speed claim "holds only against LLMs left in their slowest default mode". An ordered tool-routing eval got 44% hit rate - better than the LLM's 24%, and still wrong more than half the time. And a pre-registered routing study found confidence-cascading Jev to an LLM wins on one dataset and loses on the next, with no routing parameter transferring between them. Type-safe is not the same as correct, and non-autoregressive is not the same as deterministic.

The learned-router literature says the deeper version of the same thing. A 21-method routing study found routers converge to a narrow band far below the oracle because they learn global trends, not per-query signals. Learned routers collapse to the expensive arm as budgets rise, a failure mode code does not have, and they are adversarially steerable with query-independent token gadgets. A robustness lifecycle study puts the punchline better than I could: training-free routers showed the strongest adversarial and backdoor robustness, "benefiting from the absence of learnable parameters". Learnability is precisely what sells the classifier, and precisely what buys the variance back.

I'd put the general principle this way: most of what people are gating with Jev this weekend is control flow, and control flow should not be a model call of any size. The System 1 framing is right about the problem - agent loops are full of small decisions that don't need a frontier model - but a 421M-parameter encoder is the second-best answer to most of them. The best answer is that the decision was never open. The honest scope of Jev and Laya is the decisions that are genuinely about content: is this email spam, which of ten queues does this ticket belong in, does this text violate policy. Those need a model because code can't read. If your harness makes thousands of those per hour, a calibrated non-autoregressive classifier is exactly the right shape, and Laya's open weights make it locally runnable, which is very much this blog's territory. The published case where the pattern demonstrably works confirms the shape: MemRouter replaced an LLM's per-turn memory-admission decision with a small classifier and beat it (F1 52.0 vs 45.6, latency 970 ms to 58 ms) - a closed boolean, high volume, and the classifier as sole authority, not an advisor the main model can overrule.

pi-rukas mostly doesn't have that shape: its remaining judgment calls are few, low-volume, and deep - is this diff correct - which is precisely the case where you want the big model and the executed-evidence check behind it, not a fast classifier. "Mostly", because the research pass did find one seam that fits: intent resolution, a closed five-way verdict (proceed / park / and friends) where the LLM resolver has a documented history of unreliable answers and a wrong "proceed" costs a full work cycle. That one is classifier-shaped, and it's on the list. One seam, out of a harness. That's what "for the most part, no" means when you actually count.

So if you're one of the many wiring Jev into a harness right now, the exercise I'd actually recommend is the one this post came from: list every place your loop asks a model a question, and sort them into three piles. Decisions about content at volume: Jev or Laya, genuinely. Decisions that need deep judgment over a diff or a document: keep the big model, put an executed-evidence check behind it. Everything else - routing, permission, continuation, done-ness: that pile is your missing state machine, and no classifier, however fast and well-calibrated, should be holding it. My suspicion is that for most harnesses the third pile is the biggest one, which would make the honest headline of the weekend not "gate your agents with Jev" but "stop asking models questions code can answer".

This is the same conclusion this blog keeps arriving at from different directions: instructions steer, mechanisms stop, and a skill's rules had to become code before agents actually followed them. pi-rukas even splits the vocabulary explicitly: steering is prompt-layer discipline (there's a dispatch_steer tool for mid-flight nudges, deliberately uncapped, trust-model-of-the-prompt), gating is code. The weekend discourse uses "gating and steering" as one phrase. They're opposites.

The tongue-in-cheek part, which is only half tongue-in-cheek

Laya's author watched a well-funded lab present his year-old concept as a breakthrough. I have some sympathy, and also some deja vu: when "loop engineering" got named and celebrated this summer, the practice it described had been running on this blog's infrastructure for over a year. There's a pattern here: practitioner builds the thing because the work demands it, writes it up in unglamorous terms (a transition table! caps! parsers that admit they didn't parse!), and a while later the same idea arrives from a lab with a name, a waitlist, and a launch video.

So let me get ahead of it this once. pi-rukas' drivers - deterministic, typed, event-logged control flow where language models supply judgment as schema-validated values and never hold the steering wheel - are public, Apache-licensed, and running in production. If a frontier lab would like to call this a breakthrough in a few months, the repo history has the timestamps ready. I'd suggest "System 0": it's like System 1, but faster, free, and correct by construction...