Jev och det nya beslutslagret för AI-agenter

Varför System One-modeller kan separera snabb bedömning från långsam resonemang

Många AI‑agenter använder en språkmodell för nästan alla sina beslut. Språkmodellen väljer ett verktyg, utvärderar resultat, avgör om den behöver fortsätta och genererar slutligen svar. Flexibel; dock kan processen bli kostsam när ja‑eller‑nej‑beslut upprepas i stor skala. Unite.AI har tidigare diskuterat hur agentbaserade arbetsflöden ökar modellanrop, kontext och omförsök. Varje ytterligare beslut kan lägga till tid och pengar innan användarna får användbar information.

Jev föreslår att dela upp uppgiften på ett annat sätt. Använd en modell byggd för begränsade bedömningar där svarsmängden är definierad. Använd en generativ modell för öppet resonemang och språk. Jev påpekar att huvudtanken här inte är att alla agenter måste köpa en ny produkt. Den centrala idén är att en agent inte behöver samma typ av intelligens vid varje tillfälle.

Vad Jev faktiskt gör

TypeSafe lanserade Jev i september 2026, den första av deras nya System One-modeller. Jev skriver inte ut prosa. Istället skickar du ett tillstånd (t.ex. ett supportmeddelande och användardata). Du skickar också en eller flera frågor som har fördefinierade svarstyper. Därefter svarar Jev med typade svar och sannolikheter.

Enligt företagets officiella dokumentation finns det tre grundläggande element för att fatta bedömningar:

• Choice låter dig välja bland fördefinierade alternativ.
• Score låter dig betygsätta något mot en ordnad bedömningsmall.
• Noul uppskattar sannolikheten för att ett påstående är sant.

Du kan ställa flera oberoende frågor om samma tillstånd i en enda begäran.

Till exempel, låt oss säga att du hanterar ett kundtjänstärende. Ett system kan vilja ta reda på vilket team som ska hantera fallet. Det kan också avgöra hur snabbt någon behöver svara och om kunden begärde en återbetalning.

En chattmodell skulle potentiellt kunna utföra alla tre uppgifterna. Den skulle dock behöva leverera resultaten tillbaka till din app som ett strukturerat svar. I kontrast tillhandahåller Jev endast de begränsade besluten. Din app skulle sedan avgöra vilken åtgärd som ska vidtas härnäst baserat på dessa beslut.

Den arkitektoniska förändringen är viktigare än modellen

Majoriteten av dessa debatter jämför stora modeller med små. Jev föreslår en alternativ gräns. Vissa steg involverar språkgenerering. Andra är snäva bedömningar som mjukvara kan konsumera.

Detta skapar ett beslutslager i agenten. Modellen kommer att uppskatta. Mjukvaran kommer att tillämpa policy. Om den uppskattade sannolikheten överstiger ett testat tröskelvärde och åtgärden är lågrisk och reversibel, kan arbetsflödet fortsätta. Om det finns osäkerhet i resultaten eller om åtgärden kan ha allvarliga konsekvenser, kan systemet söka mänsklig tillsyn. En resonemangsmodell kan hjälpa till att undersöka osäkerheten, men den ersätter inte nödvändigt mänskligt godkännande.

Figur 1. En begränsad beslutsväg håller tröskelvärden, behörigheter och eskalering i kod.

Det finns likheter med modellruttning, men det finns en kritisk skillnad. RouteLLM fattar beslut om vilken av två språkmodeller som ska väljas. Den väljer mellan en starkare och en svagare modell för att balansera kvalitet och pris. En System One-modell producerar begränsade bedömningar som kod kan använda direkt. Dessa bedömningar kan stödja modellruttning såväl som andra beslut inom en agent.

Varför agentloopar är en naturlig passform

Agentlooparnas natur gör dem särskilt lämpade för att fatta många bedömningar på mycket små nivåer. Dessa bedömningar hjälper till att nå det slutgiltiga resultatet. Med andra ord måste agenter göra många “små” bedömningar efter att en användare har skickat sin fråga eller begäran. Dessa bedömningar sker innan svaret eller resultatet returneras.

Ett exempel skulle vara att besluta vilka verktyg som ska användas, rangordna hämtade poster och utvärdera risk. Systemet avgör också om tillräckligt med bevis finns och om processen ska fortsätta. Troligen kommer alla dessa att ske upprepade gånger. Dessutom kan fördröjningar mellan varje loop ackumuleras över tid.

Denna roll för agentloopar exemplifieras av LangChains Jev-integration, där Jev kan utföra både modellruttning och verktygsanropkontroller. Medan Jev integreras kring kanterna av den generativa modellen, fortsätter den generativa modellen själv att planera och generera innehåll. Detta representerar ett mycket mer realistiskt användningsfall för Jev. Den kompletterar en allmän språkmodell snarare än att ersätta den.

Därtill förändrar parallellisering av frågor också hur team tänker kring att dela upp uppgifter. Specifikt kan team bryta ner en tvetydig instruktion i flera separata utvärderingsfrågor. Detta kan potentiellt leda till en mycket kortare sekvens av modellanrop. Det kan skapa ett arbetsflöde som är mycket enklare att utvärdera. Det möjliggör också för utvecklare att använda explicit affärslogik för att kombinera de resulterande bedömningarna.

Allmänna språkmodeller kan producera strukturerad output och kan i vissa fall vara det bättre valet. Till exempel kan en fastställning och en förklaring behöva levereras tillsammans. Därför måste Jev visa mer än bara schema‑efterlevnad för att anses vara effektiv.

Jevs effektivitet beror på att minska den totala systemlatensen. Det beror också på att producera användbara sannolikhetsuppskattningar och visa stabilitet i prestanda över varierande indata. Om Jev misslyckas med att leverera dessa fördelar kommer valet av en annan modell bara att lägga till ytterligare utvecklings‑ och driftskostnader.

Betyder typat att det är korrekt?

Språket som används när påståenden om Jev görs måste också formuleras noggrant. Eftersom utdatautrymmet definieras i förväg bör modellen inte returnera ett påhittat fält eller ett otydligt stycke. Det eliminerar en form av fel; det eliminerar inte semantiskt fel. Det finns inget som hindrar ett system från att returnera en felaktig avdelning, tilldela en felaktig risknivå eller ange för stor säkerhet. Det kan göra allt detta samtidigt som det är helt typ‑säkert.

TypeSafe’s own System One-dokumentation gör en viktig distinktion. Kalibrering mäts över grupper av prediktioner; den garanterar inte korrektheten för en enskild prediktion. I produktion har detta konsekvenser. Team måste testa om de förutsagda sannolikheterna matchar observerade resultat på deras egna data.

Underlaget för prestandan är fortfarande preliminärt

TypeSafe rapporterar svarstider på 70 till 500 millisekunder. Det refererar också till betydande kostnadsbesparingar och hastighetsförbättringar i sina interna arbetsflödesutvärderingar. Dessutom indikerar TypeSafe att dessa rubrikvinster sannolikt ligger nära den övre delen av verkliga vinster. TypeSafe’s offentligt tillgänglig arbetsflödestestning använder referenssannolikheter som tillhandahålls av andra frontier‑modeller snarare än sanningsgrundade etiketter. Resultaten är bra för att bilda hypoteser. Resultaten kan inte ersätta ett oberoende test mot en verklig arbetsbelastning.

Ett praktiskt test före införande

När du bygger ditt första AI‑drivna beslutsarbetsflöde, välj inte dina mest kritiska beslut (till exempel medicinska godkännanden eller kontosuspensioner). Välj istället något som är mycket vanligt, reversibelt och enkelt att granska av andra i teamet. Det inkluderar men är definitivt inte begränsat till ärende‑routing, dokumentkategorisering, modellval och låg‑risk kvalitetskontroll.

Fyra frågor hjälper dig att bedöma om detta kommer att fungera:

• Har outputen ett ändligt antal möjliga svar?
• Kan du tydligt formulera kriterierna för bedömningen?
• Finns det mätbara resultat? Följ prediktionen, dess sannolikhet, åtgärden och de efterföljande resultaten. Kontrollera kalibreringen regelbundet genom att jämföra förutsagda sannolikheter med observerade utfall.
• Har du en alternativ plan om den automatiserade beslutsprocessen misslyckas? Identifiera en specifik punkt då du ska använda en resonemodell, be om mer information eller involvera en människa.

Din analys bör omfatta hela arbetsflödet, inklusive beslutsprocessen. Använd mått som beslutsnoggrannhet, avstå‑ eller eskaleringsfrekvens, total end‑to‑end‑bearbetningstid, kostnad per framgångsrikt slutfört uppdrag och påverkan av misstag. Kör tester under ogynnsamma förhållanden: varierande ordval, utelämnande av relevant data, sällsynta kategorier och motståndskraftiga indata. En optimerad klassificerare som genererar ytterligare kostnader nedströms är ingen optimering.

Den långsiktiga lärdomen här

Om Jev lyckas, förändras avsevärt, eller ersätts snabbt, förblir en sak konstant. Den arkitektoniska frågan kvarstår. Är det nödvändigt att varje maskinbaserat beslut renderas som genererat språk?

I många fall är svaret “nej”. I en produktionsmiljö kan ett system som använder generativa modeller skapa tolkningar, planer och förklaringar. Med begränsade beslutsmodeller kan samma system routa, poängsätta och gate. Koden kan fortsätta att ange acceptabla tröskelvärden och behörigheter. Människor bör förbli ansvariga för beslut som påverkar andras liv.

Även om detta är ett mindre dramatiskt perspektiv än att låta en autonom modell utföra alla uppgifter pålitligt, speglar det hur pålitliga system byggs. Nästa prestandaförbättring för agenter kan bero på att välja de områden i systemet där tänkandet tar längre tid. Andra områden kräver snabba beslut, och vissa kräver ingen åtgärd alls.