AI-agenter sløser bort en utrolig mengde intelligens på bittesmå valg.
Skal jeg prøve på nytt? Hvilket verktøy passer her? Ble oppgaven faktisk ferdig? Er denne handlingen risikabel? Hvilke 5 av disse 100 dokumentene betyr noe? Følger dette svaret egentlig instruksjonene?
Akkurat nå kaller vi den samme svære modellen som skriver koden vår og gjør researchen vår, bare for å svare på sånt. Det er litt som å ringe arkitekten hver gang du lurer på om du skal ta trappa eller heisen.
Så kom Jev. Og jeg har ikke klart å slutte å tenke på den siden.
Jev koster 0,042 dollar per million input-tokens. Uten betaling for output-tokens i det hele tatt. TypeSafe oppgir responstider på rundt 70–500 ms ende-til-ende, og deres egne workflow-evals viser forbedringer på opptil 193,6x raskere og 444,6x billigere enn LLM-baselinene de testet mot.
Og det er en grunn til at den kan få det til: du kan bokstavelig talt ikke chatte med Jev.
Den skriver ikke blogginnlegg. Den skriver ikke kode. Den genererer ingen forklaring. Den fører ingen samtale.
Den tar imot en tilstand og svarer på strukturerte spørsmål om den.
Det viser seg å være nyttig på langt flere steder enn jeg hadde sett for meg.
Choice. Velg ett alternativ. retry, wait, change_parameters, switch_provider, escalate.
Score. Plasser noe på en ordnet skala. Lav risiko, middels, høy, kritisk.
Noul. Gi meg sannsynligheten for at noe er sant. Ble oppgaven faktisk fullført?
Du får tilbake avgjørelsene sammen med sannsynligheter og konfidensinformasjon som koden din kan bruke direkte. TypeSafe kaller denne klassen modeller for «System One»-modeller.
En enkel forespørsel ser slik ut:
{
"model": "jev-latest",
"state": "The deploy failed twice and customers are seeing 500 errors.",
"questions": {
"urgent": {
"type": "noul",
"instructions": "Does this need attention immediately?"
},
"severity": {
"type": "score",
"instructions": "How severe is the impact?",
"criteria": ["Minor", "Degraded", "Major outage"]
}
}
}
Det virkelig fine er at spørsmålene deler samme tilstand og evalueres sammen i én forespørsel. Du kan blande Noul, Choice og Score i samme kall.
Det gir en ganske annen måte å designe agenter på. Den store modellen kan fortsatt resonnere, skrive kode, researche og foreslå handlinger. Jev kan sitte rundt den og ta de bittesmå avgjørelsene som skjer om og om og om igjen.
Selvhelbredende verktøykall. Agenten kaller et API. Det feiler. Vanligvis går feilen rett tilbake til LLM-en: «API-et returnerte 429. Hva nå?» Og så betaler du for nok et resonneringskall bare for å avgjøre om du skal vente i ti sekunder. Send heller tilstanden til Jev (verktøy, handling, feilkode, antall forsøk, forrige ventetid, alternativ leverandør) og spør hva som bør skje. Koden din utfører svaret. Gang det opp med tusenvis av verktøykall.
Loop-kontrolleren. Enhver langtkjørende agent må til slutt svare på «er vi ferdige?». Gi Jev opprinnelig oppgave, siste handlinger, verktøyresultater, artefakter og feil. Spør om oppgaven er fullført, om et steg til trengs, om noe viktig mangler, om et menneske bør inn.
if finished > 0.95:
complete()
elif needs_human > 0.8:
escalate()
else:
continue_loop()
Modellruting. En skrivefeil trenger ikke samme modell som design av et distribuert system. Send oppgaven, spør hvilken modell som bør ta den: lokal, billig, frontier, menneske. LangChain har allerede eksperimentell TypeSafe-middleware for akkurat dette mønsteret. Poenget er ikke å finne «den beste modellen». Poenget er å slutte å betale for den beste modellen når oppgaven åpenbart ikke trenger den.
Beskjæring av grener. Si at den store modellen foreslår 20 mulige tilnærminger. Du kan la den resonnere dypt om alle 20, eller du kan score dem billig først: sannsynlighet for suksess, kostnad, risiko, reverserbarhet, manglende informasjon. Drep de svake. Bruk den dyre tenkingen på de tre beste.
Verktøyvalg. Agenten har nettleser, terminal, GitHub, e-post, CRM, database, søk, Slack. Du trenger ikke nødvendigvis en frontier-modell til å revurdere hele den lista hver eneste runde.
Det er her Jev blir mer interessant enn «billig klassifisering».
Port for irreversible handlinger. Før agenten gjør noe utenfor sandkassen, sjekk konsekvensen. Kan dette lett angres? Berører det et annet menneske? Berører det penger? Eksponerer det private data? Er det tydelig autorisert? Så setter du tersklene selv: høy konfidens og reverserbart kjører, usikkert og reverserbart kjører med logging, irreversibelt går til gjennomgang, uautorisert blokkeres.
Dynamiske tilganger. Permanente agenttilganger kommer til å se rarere og rarere ut. «Du har for alltid tilgang til Gmail, Stripe, GitHub, Slack og hele databasen vår.» Generer heller tilgangene for oppgaven: Stripe lesing ja, refusjon til gjennomgang, kundedatabase ja, Gmail nei, maksimal refusjon 50 dollar. Så forsvinner settet når jobben er gjort.
Pengebrannmur. Samme idé for innkjøp. Send pris, leverandør, budsjett, regler og tidligere kjøp. Få tilbake godkjenn, vurder eller avslå. Den deterministiske koden din eier fortsatt selve betalingen.
Konfidensbaserte menneskekøer. Ikke alt trenger et menneske. Bare de rare tilfellene. Lav konfidens, høy kostnad eller stor konsekvens går til en person. Resten går automatisk. Én operatør kan følge med på langt flere arbeidsflyter uten å bli flaskehalsen.
Den mest åpenbare bruken: hovedmodellen genererer et svar, og så ringer du en ny svær modell for å spørre «var det bra?». Det blir dyrt fort. Gjør heller sjekkene eksplisitte. Fulgte den instruksjonene? Svarte den på alle deler? Støttes påstandene av materialet? Brøt den noen policy? Send bare de tvilsomme tilfellene videre til den dyre dommeren.
Det samme gjelder logger. En agentkjøring på en time kan inneholde hundrevis av meldinger, dusinvis av verktøykall, omstarter, endrede planer og subagenter. Ingen orker å lese gjennom det manuelt. Kjør Jev over sporene og spør om agenten gjentok seg, brøt instruksjoner, kalte verktøy unødvendig, hoppet over godkjenning eller gikk i loop. Dashbordet ditt løfter fram kjøringene som faktisk fortjener oppmerksomhet.
Og semantisk linting, som jeg liker godt: vanlige lintere forstår syntaks. Jev kan sjekke regler skrevet på vanlig norsk (eller engelsk). Gjør dette endepunktet autorisasjon før det leser kundedata? Innfører denne endringen et direkte databasekall utenfor repository-laget? Logger vi personopplysninger her? Kjør det i CI.
Søket returnerer 100 dokumenter. Frontier-modellen din trenger neppe alle. Gi Jev spørsmålet og ett kandidatdokument, be om relevans, ta de fem beste.
Kildeverifisering er like enkelt. Du har en påstand: «Selskap X økte omsetningen med 40 %.» Du har passasjen. Støtter passasjen faktisk påstanden? Nå kan du sjekke referansene før en AI-generert rapport sendes ut.
Og kontekstfilter: før du dumper alt tilbake i den dyre modellen, score hver bit. Er dette fortsatt relevant? Er det duplisert? Trenger modellen det for neste steg? Færre tokens inn, og mindre støy som konkurrerer om oppmerksomheten.
Her blir antall mulige kall nesten komisk. Supportruting (hvilket team, hvor haster det, ber de om refusjon, hvor frustrerte er de, er churn sannsynlig). Refusjonstriage. Incident-håndtering som starter i ren anbefalingsmodus og får lov til å handle først når den har bevist seg på historiske hendelser. Marketplace-matching, som er nettopp der latensen betyr noe: en avgjørelse som tas én gang om dagen trenger ikke en submodell på millisekunder, men tusenvis av skiftende avgjørelser gjør det.
Ett skille er verdt å merke seg fra lead-kvalifisering: match og kjøpsintensjon er ikke samme spørsmål. En perfekt kunde kan ha null interesse i dag. En som tigger om demo kan være helt utenfor målgruppa. Hold dem adskilt.
Du trenger ikke LangChain. Du trenger ikke et agentrammeverk. Du trenger nesten ikke kode.
pip install typesafe-sdk
export TYPESAFE_API_KEY=...
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
client = TypeSafeClient()
result = client.system_one(
state={
"task": "Fix the checkout bug",
"last_action": "Ran test suite",
"result": "2 tests still failing"
},
questions={
"finished": Noul(
instructions="Has the original task been successfully completed?"
),
"next_step": Choice(
instructions="What should happen next?",
criteria={
"continue": "Continue working",
"retry": "Retry the previous step",
"human": "Ask a human for help"
}
)
}
)
Det er hele primitivet. Tilstand → spørsmål → sannsynligheter → kode.
Jeg ville ikke koblet Jev rett på produksjon og håpet på det beste.
Ta en avgjørelse systemet ditt allerede tar. Hent 100–500 historiske eksempler der du vet hva som burde skjedd. Kjør både dagens system og Jev. Mål treffsikkerhet, falske positive, falske negative, konfidens, latens og kostnad.
Konfidensbiten er viktig. Dokumentasjonen er tydelig på at kalibrering gjelder på tvers av grupper av prediksjoner. Et svar med høy konfidens er ingen matematisk garanti for at akkurat dette svaret er riktig.
Så setter du terskler. Kanskje over 0,95 automatiseres, 0,70–0,95 automatiseres bare hvis det er reverserbart, under 0,70 går til menneske eller frontier-modell. Tallene er eksempler. Dine egne evals bør bestemme dem.
Og kjør det i skyggemodus først. La Jev ta avgjørelser uten å handle på dem, og sammenlign med hva som faktisk skjedde. Først da gir du den kontroll.
Det finnes en enkel test: trenger du at modellen skal skape noe nytt, er Jev antakelig feil verktøy.
Jeg bruker fortsatt en frontier-modell til å skrive kode, skrive innhold, drive åpen research, tegne arkitektur, brainstorme, forklare grundig og løse problemer ingen har løst før. Jev tar imot tekstbasert tilstand og returnerer avgrensede avgjørelser. Den genererer ikke svar, kode eller resonnement.
Og en siste ting som er verdt å si høyt: Jev kan ta feil. Den kan ikke plutselig finne på et fjerde alternativ når du ga den tre. Men det betyr ikke at alternativet den velger er riktig. Typede utdata løser ett pålitelighetsproblem. De løser ikke dømmekraft.
Det er egentlig dette som gjør meg mest nysgjerrig.
Vi brukte noen år på å anta at én diger modell skulle gjøre alt. Skrive koden. Søke. Klikke i nettleseren. Dømme svaret. Rute oppgaven. Bestemme om den skulle prøve igjen. Sjekke om den var ferdig. Godkjenne handlingen.
Den arkitekturen ser plutselig veldig dyr ut. Jeg tror framtidige agentsystemer kommer til å se mer slik ut: én frontier-modell til den virkelig vanskelige tenkingen og genereringen, en beslutningsmodell til valgene og scoringen, spesialister på repetitive maskinhandlinger, bittesmå rerankere til gjenfinning, små klassifiserere til ruting, og helt vanlig kode til harde regler og utførelse.
Én dyr modell tar fortsatt det som faktisk er vanskelig. Så omgir du den med stadig mindre spesialister bygget for helt bestemte jobber.
Hver gang jeg ser på en agent-loop nå, stiller jeg det samme spørsmålet: trenger dette steget virkelig en frontier-modell?
Overraskende ofte er svaret nei.