Jev AI: qué es, cómo funciona y casos de uso en SaaS
Jev devuelve decisiones tipadas (choice, noul, score) que tu código ejecuta: devoluciones, leads, filtros, guardrails y navegación sin generar texto de más.
Estamos usando LLMs para decisiones que muchas veces no necesitan generar una sola palabra.
¿Este lead debe hablar con un asistente o con ventas? ¿Esta devolución puede seguir automáticamente? ¿Qué acción debe ejecutar un copiloto dentro de una interfaz conocida? ¿Este comando parece peligroso? ¿Qué documentos son relevantes para analizar un riesgo?
GPT o Claude pueden resolverlo. Pero siguen siendo modelos diseñados para generar tokens.
Jev intenta resolver otra cosa: tomar decisiones estructuradas que el software pueda consumir directamente.
No sustituye al LLM. Y tampoco sustituye al código. Si lo utilizas bien, ocupa el espacio que hay entre ambos.
Documentación oficial: docs.typesafe.ai/introduction
Qué es Jev realmente
TypeSafe denomina a Jev su primer System One model. En lugar de pedirle texto, le pasas un state y preguntas con un espacio de respuesta previamente definido.
Hay tres primitivas:
Tipo | Sirve para | Ejemplo |
|---|---|---|
choice | Elegir entre opciones | assistant, sales, human_review |
noul | Sí/no probabilístico | ¿Este comando parece destructivo? |
score | Posición dentro de una escala | Riesgo bajo a crítico |
La documentación completa de las primitivas está aquí: docs.typesafe.ai/primitives
La diferencia con un LLM parece pequeña hasta que la llevas a código.
Cómo se usa: un ejemplo realista
Imagina un SaaS de devoluciones. Llega este mensaje:
Me llegó el pedido ayer, pero está roto. Quiero que me devolváis el dinero.
En vez de pedir a un LLM que analice la petición y genere JSON, puedes enviar a Jev un estado y varias decisiones:
El endpoint oficial es:
POST /v1/systemone
API: docs.typesafe.ai/api
La respuesta no contiene una explicación. Devuelve algo de esta forma:
Y aquí está la parte importante: Jev no debería decidir qué ocurre después. Tu código sí.
Ese reparto importa.
En nuestro artículo sobre arquitectura de agentes ya defendíamos que el modelo no es el sistema: tools, estado, permisos, ejecución y policy siguen viviendo alrededor. Jev no cambia esa idea; la hace todavía más evidente.
Jev o un LLM: regla rápida
Utilizar Jev | Utilizar un LLM |
|---|---|
Clasificar una petición | Redactar una respuesta |
Elegir entre opciones conocidas | Descubrir una solución abierta |
Puntuar riesgo, relevancia o intención | Razonar sobre un problema complejo |
Routing entre agentes, tools o modelos | Diseñar un plan |
Filtrar muchos candidatos | Sintetizar información compleja |
Guardrails semánticos | Explicar una decisión |
Elegir la siguiente acción entre acciones conocidas | Generar código o contenido |
Decisiones frecuentes donde importa la latencia | Procesos donde importa más el razonamiento que la latencia |
Y hay una tercera columna invisible: código.
Si sabes exactamente cuál es la regla, no necesitas ni Jev ni un LLM.
Dónde puede tener sentido en un SaaS
El patrón bueno suele tener tres características: hay lenguaje natural o información desestructurada, existe un conjunto limitado de posibles decisiones y esa decisión ocurre muchas veces.
Gestión de devoluciones y soporte
Una devolución puede requerir detectar intención, comprobar si falta información, decidir qué política corresponde y saber si debe escalarse a una persona.
No todas esas decisiones necesitan razonamiento generativo.
Una capa de decisión puede devolver:
refund
exchange
need_information
human_review
y reservar el LLM para cuando realmente hace falta conversar.
Benchmark de referencia: en una prueba externa sobre 1.895 issues reales de GitHub, evaluando las mismas nueve preguntas sobre cada issue, Jev tuvo un coste total de $0,11 frente a $18,36 con Sonnet. Es aproximadamente 160x menos coste para la misma carga de clasificación.
La mejora no está en escribir mejor una devolución. Está en dejar de generar texto cuando solo necesitas decidir por qué camino continúa.
Sobre coste completo de agentes: el precio por token no es el coste del agente
Cualificación y routing de leads
Otro caso aparece cuando hay que decidir si un lead debe continuar con un asistente o pasar ya a una persona.
La decisión puede utilizar señales como intención, encaje, complejidad o urgencia:
assistant
ask_more_information
sales
discard
El LLM se ocupa de conversar. Jev puede hacer el routing.
Benchmark de referencia: en esa misma prueba externa se pudieron contrastar 767 issues contra las etiquetas que habían puesto los propios maintainers. Jev acertó el 96% frente al 94% de Sonnet. No es un benchmark de leads, pero sí un buen indicador para problemas de routing con clases conocidas: una capa de decisión especializada puede mantener o incluso mejorar el acierto sin pagar el coste de un LLM generativo.
Aquí unos pocos puntos de precisión importan: el error no es una frase peor, sino enviar un buen lead al flujo equivocado.
Filtros inteligentes
Marketplaces, viajes, seguros, configuradores o catálogos B2B tienen muchos problemas del tipo:
"Quiero un hotel tranquilo, pero no aislado."
"Necesito una solución para 200 empleados y SSO."
"¿Cuál de estos proveedores encaja mejor?"
Un LLM puede evaluar las opciones, pero si tienes cientos de candidatos estás utilizando generación donde realmente necesitas scoring o clasificación.
Benchmark de referencia: en la prueba externa sobre 1.895 issues y nueve preguntas por issue, Jev tardó 12,9 s frente a 28,9 s con Sonnet: aproximadamente 2,2x más rápido. Es bastante menos que el máximo de 193x publicado por TypeSafe, pero probablemente una referencia más útil para producto: incluso una mejora de 2x puede notarse mucho cuando una interfaz encadena varias decisiones.
Análisis documental
En crédito, seguros o compliance puedes recuperar primero documentos y después decidir:
El LLM puede seguir haciendo el análisis complejo. Jev puede ayudar a filtrar qué merece llegar hasta él.
Benchmark orientativo: cuando varias preguntas se realizan sobre el mismo documento, pasar de inferencias secuenciales de alrededor de 2-3 segundos a 250-400 ms es un rango razonable para este patrón, aproximadamente 5-10x menos latencia.
TypeSafe muestra precisamente el patrón de clasificar varios pasajes RAG antes de pasarlos al modelo generativo: classifying RAG passages
El efecto secundario también importa: si filtras mejor antes, reduces contexto innecesario en el LLM posterior.
Guardrails antes de ejecutar comandos o tools
Un agente propone:
Puedes evaluar:
y después dejar que una policy determine:
Benchmark de referencia: en el test externo sobre issues, Jev consiguió 96% de acierto frente al 94% de Sonnet cuando existía una etiqueta humana contra la que comprobar el resultado. El matiz interesante es que ambos modelos coincidían casi siempre en hechos relativamente objetivos (por ejemplo, distinguir bug de feature) y se separaban más cuando entraba juicio, como decidir si un ingeniero podía empezar a trabajar sin pedir más información. Para guardrails, ese patrón importa: señales concretas y acotadas pueden automatizarse; decisiones ambiguas deberían escalarse.
Pero Jev no debería ser el sistema de permisos.
Puede decir que algo parece peligroso. La autorización sigue estando en código.
Lo explicamos aquí: identidad, permisos y límites de los agentes de IA
El caso más interesante ahora mismo: navegar interfaces
Uno de los proyectos con más tracción alrededor de Jev es browser-use/jev-ultrafast.
La idea es bastante limpia.
El navegador transforma la página en elementos:
y Jev decide entre operaciones conocidas:
No necesita generar una descripción de lo que está viendo. Decide cuál es la siguiente acción y sobre qué elemento.
Para un asistente embebido dentro de un SaaS, el patrón es interesante: el LLM entiende qué quiere conseguir el usuario y Jev puede ayudar a resolver qué acción toca ahora.
Repositorio: github.com/browser-use/jev-ultrafast
Y dónde no lo usaríamos
Jev funciona peor cuando intentamos convertir artificialmente un problema de razonamiento en cien decisiones independientes.
El ejemplo más polémico ahora mismo es compactar memoria de agentes.
Hay proyectos que utilizan Jev para puntuar cada mensaje o tool call y decidir qué conservar:
¿esto sigue siendo relevante? (sí / no)
El problema es que relevancia y memoria no son lo mismo.
Decidir qué información necesita un agente más adelante puede depender de todo el razonamiento que ha ido acumulando. Una línea aparentemente irrelevante puede explicar por qué se descartó una hipótesis veinte pasos atrás.
Por eso no asumiríamos que:
¿este mensaje sigue siendo útil?
es equivalente a:
¿qué estado necesita conservar el agente para seguir razonando?
La segunda pregunta requiere bastante más que clasificación.
Proyecto que está experimentando con este patrón: github.com/tamaratran/fast-jev-compaction
Lo mismo ocurre con matemáticas, fechas, reglas exactas o permisos. Si sabes escribir la condición, usa código.
Y si necesitas generar, planificar, explorar hipótesis o mantener una cadena compleja de razonamiento, usa un LLM.
Las limitaciones conocidas de Jev 1.13 están documentadas aquí: docs.typesafe.ai/model-jaggedness/jev-1.13
"Jev no alucina" necesita bastante contexto
Una de las frases que más se está repitiendo es que Jev no alucina.
Eso es verdad únicamente bajo una definición muy concreta.
Si defines:
Jev no puede inventarse:
marketing
La salida está limitada al schema.
Pero puede escoger billing cuando la respuesta correcta era technical.
El ejemplo de strawberry que se ha hecho popular lo demuestra bien: se le pregunta cuántas r contiene la palabra y el modelo puede escoger una respuesta incorrecta entre las opciones permitidas. También puede cambiar de predicción entre ejecuciones.
Por tanto:
Jev evita outputs fuera del contrato. No evita inferencias incorrectas.
Para un developer, eso significa que confidence y probabilidades no son decoración.
Los thresholds anteriores son ilustrativos. Hay que calibrarlos según la distribución real del producto y, sobre todo, según cuánto cuesta equivocarse.
Documentación: docs.typesafe.ai/confidence
Y si una decisión cambia el comportamiento del sistema, debería quedar registrada en la traza: trazabilidad de agentes de IA
Qué está construyendo ya la comunidad
Hay tres proyectos que ayudan bastante a entender hacia dónde se está moviendo Jev.
Browser Use, Jev Ultrafast. Utiliza Jev para decidir acciones y elementos durante navegación web.
github.com/browser-use/jev-ultrafast
Fast Jev Compaction. Utiliza Jev para decidir qué partes del contexto conservar o eliminar en Claude Code. Tiene interés precisamente porque representa uno de los usos que creemos que conviene evaluar con bastante cuidado.
github.com/tamaratran/fast-jev-compaction
Vercel Eve. Utiliza Jev en su capa de evaluación para routing y decisiones relacionadas con tools.
Documentación de evaluación: evaluate.md
Que la comunidad experimente con navegación, memoria, routing y approvals es probablemente más interesante que otra demo de sentimiento positivo/negativo.
La regla para usar Jev bien
No preguntes:
"¿Puedo convertir esto en un Choice?"
Casi todo puede forzarse hasta parecer una clasificación.
Pregúntate:
"¿Tengo una decisión semántica, acotada, repetitiva y evaluable?"
Si tienes una regla exacta, usa código.
Si necesitas razonamiento o generación, usa un LLM.
Si tienes una decisión semántica estrecha que ocurre miles de veces, Jev merece una prueba.
Y si esa decisión puede cambiar datos, gastar dinero o ejecutar una acción, no conviertas una probabilidad en un permiso.
Jev no elimina el sistema alrededor del modelo.
Añade una pieza nueva dentro de él.
Convierte tu SaaS en AI-Native
Obten una prueba gratis solo con registrarte
Últimos blogs
