Cuando pensamos en agentes de inteligencia artificial, tendemos a imaginar un LLM tomando todas las decisiones. El agente analiza una situación, decide qué herramienta utilizar, ejecuta una acción, observa el resultado, vuelve a consultar al modelo y decide qué hacer después. Funciona. Pero probablemente estamos utilizando modelos generativos para muchas decisiones que no necesitan generación.
Ahí es donde resulta interesante Jev, el modelo System One desarrollado por TypeSafe AI. Su propuesta es sencilla: separar dos cosas que habitualmente estamos mezclando dentro de nuestros agentes. Pensar y generar no es lo mismo que decidir.
El problema de utilizar un LLM para todo
Imaginemos un agente encargado de preparar diariamente un informe sobre inteligencia artificial. Podría tener disponibles varios agentes especializados: un agente de investigación, uno encargado de redactar, otro de revisar, y diferentes herramientas para acceder a fuentes o guardar información.
En algún momento el sistema tendrá que responder preguntas como:
¿Tenemos ya suficientes fuentes? ¿Debe continuar investigando? ¿Es momento de redactar? ¿El documento está preparado para revisión?
Una arquitectura habitual consiste en enviar nuevamente todo el contexto a un LLM para que responda. Pero hay algo extraño en ese diseño: estamos utilizando un modelo capaz de programar, redactar, razonar o analizar documentos complejos simplemente para decidir entre research / write / review. Y repetimos este patrón continuamente.
En un agente con decenas o cientos de pasos, una parte considerable de las llamadas al modelo puede terminar dedicada simplemente a clasificar, seleccionar, puntuar o decidir.
La propuesta de Jev
Jev está diseñado precisamente para este tipo de decisiones. No pretende sustituir a Claude, GPT, Gemini o cualquier otro modelo generativo. De hecho, sus limitaciones forman parte del diseño.
Jev recibe información sobre el estado actual del sistema y una serie de preguntas previamente definidas, y devuelve respuestas estructuradas acompañadas de probabilidades. No está pensado para escribir un informe, generar código o explicar extensamente su razonamiento. Está pensado para cosas como:
¿Qué agente debería actuar ahora? ¿Este documento es relevante? ¿Debemos continuar? ¿Esta operación necesita aprobación?
El resumen de la propuesta es directo: el LLM crea el trabajo; Jev decide qué ocurre después.
Tres tipos de decisiones
Jev plantea tres mecanismos especialmente útiles para sistemas de agentes.
Choice
Selecciona una opción dentro de un conjunto definido. Por ejemplo:
¿Qué agente debe continuar?
- researcher
- writer
- reviewerEl resultado no es texto libre, sino una selección junto con su distribución de probabilidades y nivel de confianza.
Score
Evalúa algo utilizando una escala definida previamente. Por ejemplo:
¿Qué relevancia tiene esta fuente?
0 - irrelevante
1 - parcialmente relevante
2 - directamente relevanteEsto resulta especialmente interesante para pipelines de recuperación de información, RAG o clasificación documental.
Noul
Responde una pregunta binaria mediante una probabilidad entre 0 y 1. Por ejemplo:
¿Este comentario puede publicarse?
¿Esta acción necesita aprobación humana?Un valor próximo a 0,5 puede utilizarse precisamente para detectar incertidumbre y escalar la decisión a otro modelo o a una persona.
Una arquitectura diferente para los agentes
La consecuencia interesante aparece cuando llevamos esta separación a una arquitectura completa:
┌─────────────┐
│ Estado │
└──────┬──────┘
│
▼
┌─────────────┐
│ Jev │
│ decisión │
└──────┬──────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Researcher Writer Reviewer
LLM LLM LLM
│ │ │
└─────────────┼─────────────┘
│
▼
nuevo estado
│
└──────► JevJev actúa como una capa de decisión. Los modelos generativos continúan haciendo aquello para lo que son buenos: investigar, razonar, programar, escribir, interpretar información compleja. Mientras que una capa mucho más pequeña puede encargarse de: enrutar, clasificar, puntuar, aprobar, detener, escalar.
Y finalmente debería existir una tercera capa que muchas veces olvidamos: el código tradicional. Si sabemos que un agente nunca debe ejecutar más de diez acciones, no necesitamos preguntárselo a ninguna IA. Lo implementamos:
if actions >= 10:
stop()Esto nos lleva a una arquitectura bastante razonable:
- •LLM → genera y razona
- •Jev → decide
- •Código → ejecuta y aplica reglas deterministas
Casos prácticos: cuando la separación paga dividendos
Browser Use: navegar sin quemar tokens
Uno de los casos más llamativos publicados alrededor de Jev es su integración con Browser Use. Un agente que controla un navegador debe decidir continuamente qué hacer: hacer clic, seleccionar un elemento, introducir información, navegar, finalizar. Además, las acciones disponibles cambian después de cada interacción con la página.
Browser Use utiliza Jev para seleccionar la siguiente acción y el elemento correspondiente, mientras reserva un pequeño LLM para situaciones en las que realmente necesita generar texto. En la demostración citada, el agente encontró vuelos en aproximadamente 7 segundos, con un coste declarado de 0,0039 dólares. Conviene interpretar correctamente el resultado: encuentra resultados de vuelos, no realiza la reserva, y algunas operaciones del navegador quedan fuera de ese cálculo. Lo importante, por tanto, no es únicamente el número: es la arquitectura.
Clasificar más de mil papers por ocho céntimos
Otro ejemplo resulta incluso más ilustrativo. En una prueba se clasificaron 1.018 artículos de investigación sobre IA con el siguiente pipeline:
Paper
│
▼
DeepSeek V4 Flash
│
│ resumen
▼
Jev
│
│ clasificación entre 24 temas
▼
CategoríaEl coste comunicado para la clasificación realizada por Jev fue de 0,08 dólares, con una latencia mediana end-to-end de 256 ms por artículo. DeepSeek realiza la tarea generativa: resumir. Jev realiza la tarea discriminativa: clasificar. No necesitamos utilizar el mismo modelo para ambas cosas.
Clasificar 500 emails en segundos
También se ha mostrado Jev clasificando 500 correos electrónicos en segundos por unos 3,5 céntimos. Cada mensaje puede convertirse en un estado sobre el que decidir entre acciones previamente definidas:
reply
research
wait
reviewA partir de ahí el resultado puede enviarse al agente correspondiente:
Email
│
▼
Jev
│
├── reply ─────► agente de respuesta
│
├── research ──► agente investigador
│
├── wait ──────► cola
│
└── review ────► humanoLa IA generativa solo entra en funcionamiento cuando realmente hace falta.
Elegir el propio modelo y reducir el contexto
Supongamos que nuestro sistema dispone de varios modelos: un modelo pequeño y barato, uno generalista, uno de razonamiento y uno especializado. No todas las peticiones necesitan pasar por el modelo más potente. Una capa de decisión podría analizar la tarea y decidir:
petición sencilla
│
▼
modelo barato
petición compleja
│
▼
modelo avanzadoLangChain ya ha mostrado este patrón utilizando Jev para enrutar tareas entre modelos con diferentes capacidades y costes. En sistemas que realizan miles o millones de operaciones, esta separación puede tener un impacto importante en coste y latencia.
Hay otro caso particularmente interesante: los agentes acumulan contexto rápidamente (mensajes, resultados de herramientas, búsquedas, llamadas a APIs, archivos, observaciones intermedias). Tradicionalmente podemos pedir a otro LLM que resuma todo ese contexto. Pero quizá tampoco necesitemos generar un resumen: podemos puntuar cada elemento según su relevancia y eliminar aquello que ya no resulta necesario.
Una demostración citada utiliza Jev precisamente para analizar llamadas a herramientas de una sesión de Claude y reducir un contexto cercano al millón de tokens hasta aproximadamente 86.000, mediante selección de relevancia en lugar de resumirlo generativamente. Es otra manifestación del mismo principio: antes de pedir a un LLM que genere algo, deberíamos preguntarnos si realmente necesitamos generación.
Esto no significa sustituir los LLM
Es probablemente la distinción más importante. Jev no sustituye a los modelos generativos, los complementa. Podemos pensar en tres niveles:
┌───────────────────────────────┐
│ LLM │
│ investigación · código · texto│
│ razonamiento · planificación │
└───────────────────────────────┘
│
▼
┌───────────────────────────────┐
│ Decision model │
│ route · score · approve · stop│
└───────────────────────────────┘
│
▼
┌───────────────────────────────┐
│ Código │
│ ejecutar · validar · persistir│
│ límites · permisos │
└───────────────────────────────┘Esto obliga a diseñar los agentes de una manera algo más disciplinada. No todo necesita IA generativa. Y no todo necesita siquiera IA.
El coste cambia radicalmente (con matices)
Según la información publicada para Jev 1.13, su precio es de 0,042 dólares por millón de tokens de entrada, sin coste por tokens de salida. Eso significa que, suponiendo decisiones de 1.000 tokens de entrada, 10.000 decisiones representarían aproximadamente 0,42 dólares de inferencia de Jev.
Pero quedarse únicamente con ese dato sería un error. El coste que realmente importa en un agente no es «¿cuánto cuesta esta llamada?», sino «¿cuánto cuesta completar correctamente la tarea?». Una decisión extremadamente barata que envíe al agente por el camino equivocado puede provocar después varias llamadas caras a otros modelos. Por eso estas arquitecturas necesitan métricas.
La confianza tampoco es una garantía
Jev devuelve probabilidades y niveles de confianza, lo que permite implementar patrones interesantes:
confidence > 0.90
│
▼
ejecutar
0.70 - 0.90
│
▼
consultar modelo avanzadoPero existe una distinción fundamental: confianza no significa precisión. Un sistema de producción debería calibrar esos umbrales utilizando ejemplos reales del propio dominio. También necesita límites de acciones, límites de gasto, persistencia del estado y mecanismos independientes para comprobar que una acción realmente se ejecutó. Conviene separar siempre la decisión de «hemos terminado» de la comprobación efectiva del resultado.
De agentes basados en prompts a arquitecturas de agentes
Durante los últimos años hemos dedicado mucho tiempo a mejorar prompts. Pero los sistemas de agentes empiezan a plantear otro tipo de problema. Ya no se trata solamente de conseguir que un modelo responda correctamente. Hay que diseñar:
- •Estados
- •Herramientas
- •Permisos
- •Decisiones
- •Modelos
- •Rutas
- •Verificaciones
- •Persistencia
- •Observabilidad
- •Límites de coste
En otras palabras, estamos pasando progresivamente del prompt engineering al agent engineering. Y tecnologías como Jev son interesantes no necesariamente porque vayan a convertirse en un estándar, sino porque hacen explícita una separación arquitectónica que probablemente veremos cada vez más: generar, decidir y ejecutar son problemas diferentes. Un LLM no tiene por qué resolver los tres.
En JULDITEC vemos este mismo patrón cuando diseñamos flujos de automatización con n8n e integraciones de IA para nuestros clientes: no todo el pipeline necesita generación de texto, y separar la lógica de decisión del razonamiento generativo suele traducirse en sistemas más rápidos, más baratos y más fáciles de auditar.
Quizá la pregunta que deberíamos hacernos cuando diseñamos nuestro próximo agente no sea únicamente «¿qué modelo utilizamos?», sino ¿en qué puntos necesitamos realmente un modelo generativo? Esa diferencia puede determinar cuánto cuesta nuestro agente, cuánto tarda en responder y, sobre todo, lo fácil que resulta entender y controlar lo que está haciendo.