El plano de decisión: por qué Jev cambia la arquitectura de los agentes empresariales

TL;DR

• El artículo anterior sobre Jev dejó una afirmación en el aire: la mayor parte del tráfico de IA en la empresa es enrutado, triaje, clasificación y filtrado — decisiones, no prosa.
• Si eso es cierto, el bucle monolítico de agente tiene la forma equivocada. Estás pasando tu lógica de bifurcación por un proceso de muestreo.
• Jev parte el agente en dos planos: un plano de decisión que nunca genera, y un plano de generación que no hace otra cosa — con una capa de control en código entre ambos.
• El flujo de control sale del lenguaje natural y vuelve al código, donde se puede testear, versionar y comparar con un diff.
• Las cifras de precisión son modestas en tareas hechas a medida (67,8% frente a 74,1% en el propio panel del proveedor). La arquitectura que se deduce es una cascada con escalado, no una sustitución.
• La calibración — no la velocidad — es lo que hay que testear antes de confiar.

La frase que necesitaba un producto

La frase que se quedó pegada del lanzamiento de Jev fue esta:

La mayor parte del tráfico de IA en producción de una empresa no es creativo. Es enrutado, triaje, clasificación y filtrado. Pasarlo por un motor autorregresivo es un error de categoría: pagas un párrafo para obtener una etiqueta, y heredas la latencia de un texto que nadie lee. Es algo así como encargar una memoria de 4.000 palabras para confirmar si las luces de la oficina están apagadas.

Eso era un diagnóstico. Describía una estructura de costes que casi todas las empresas tienen, no pueden ver y han aceptado en silencio. Lo que no traía era tratamiento.

Jev es el tratamiento: un modelo que recibe un estado y un conjunto de preguntas tipadas y devuelve respuestas tipadas — probabilidades sobre opciones que aportas tú, sin nada generado por el medio. Pero el modelo no es lo interesante. Lo interesante es qué le pasa a la forma de tu sistema cuando la capa de decisión deja de estar dentro del modelo de lenguaje.

Esa forma es lo bastante distinta de lo que la mayoría de los equipos ha construido como para recorrerla con calma.

La arquitectura que hemos construido en realidad

Casi todos los agentes en producción de una empresa hoy son un solo modelo haciendo cuatro trabajos:

1. Comprender el estado.
2. Decidir qué hacer después.
3. Ejecutar — normalmente emitiendo una llamada a herramienta como texto.
4. Narrar el resultado.

Los pasos 2 y 4 comparten motor, y ahí está el problema. En un bucle tipo ReAct, la bifurcación es prosa. El agente piensa “debería consultar primero el pedido del cliente” y luego emite get_order(...). La condición de parada también es prosa: alguna variante de “he completado la tarea” que tu harness busca con una expresión regular y espera parsear bien.

Así que piensa en qué son en realidad la mayoría de los agentes empresariales: el flujo de control está escrito en lenguaje natural e interpretado por un proceso de muestreo.

Es un sitio raro para guardar tu lógica de bifurcación. Y es caro de una manera muy concreta. Los tokens de salida son los caros. En un paso con forma de decisión pagas esos tokens de salida para obtener una etiqueta, y heredas la latencia de un párrafo que nadie va a ver nunca.

Ahora cuenta las decisiones de una sola ejecución de agente de soporte:

• ¿A qué cola pertenece esto?
• ¿Es un reembolso o un reemplazo?
• ¿Está este cliente autorizado para ese importe?
• ¿Se ha resuelto ya esto en otro sitio?
• ¿Es esta respuesta lo bastante buena para enviarla?

Cinco bifurcaciones. Prácticamente cero prosa. Hoy generas una o dos frases para obtener cada una — y la frase es la parte poco fiable, porque una edición del prompt de hace tres semanas puede cambiar en silencio cómo se resuelve la bifurcación.

Qué hace Jev, en un párrafo

Envías un state — texto, JSON, un documento — y un conjunto de preguntas. Hay tres primitivas: choice (elegir una de hasta 255 opciones, devuelve choice más probabilities y confidence), score (situar el estado en una rúbrica ordenada de 2 a 10 niveles, devuelve score, legend y una distribución) y noul (la probabilidad de que una afirmación de sí/no sea cierta, devuelta como un único número). Todas las preguntas sobre un estado se evalúan en paralelo, así que hacer cinco cuesta apenas más que hacer una. No se genera nada: todas las respuestas posibles las enumeraste tú de antemano, y por eso la salida cumple su esquema por construcción.

La economía reportada por el proveedor: 70–500 ms de extremo a extremo, 0,042 $ por millón de tokens de entrada y salida gratuita, y cifras de carga de trabajo de 193,6x más rápido / 444,6x más barato. Trata este último par como un techo — un modelo que no emite nada es trivialmente rápido en cualquier benchmark de latencia. La afirmación duradera es el modelo de precios, porque se deduce de la arquitectura y no de una prueba de rendimiento.

Esa es la diferencia entre llamar a una función y encargar una memoria.

La partición: dos planos y una capa de control

Cuando las decisiones tienen su propio motor, el agente deja de ser un bucle y pasa a ser tres capas:

                        ┌───────────────────────────────────────┐
                        │           CONTROL LAYER               │
                        │               (code)                  │
                        │   thresholds · escalation · retries   │
                        │   audit log · deterministic backstops │
                        └──────┬─────────────────────────┬──────┘
                               │                         │
        ┌──────────────────────▼──────┐   ┌──────────────▼──────────────────┐
        │       DECISION PLANE        │   │        GENERATION PLANE         │
        │            (Jev)            │   │             (LLM)               │
        │─────────────────────────────│   │─────────────────────────────────│
        │  route      triage          │   │  write       synthesise         │
        │  classify   score           │   │  explain     reason             │
        │  gate       verify          │   │  code        plan               │
        │─────────────────────────────│   │─────────────────────────────────│
        │  typed · calibrated         │   │  free-form · unconstrained      │
        │  70–500ms · ~free           │   │  seconds · expensive            │
        │  no rationale               │   │  rationale included             │
        └─────────────────────────────┘   └─────────────────────────────────┘

Hay dos cosas que conviene notar en este dibujo.

El plano de decisión soporta la mayoría de las llamadas; el plano de generación soporta la mayoría de los tokens. Son dos facturas distintas. Separarlas te permite optimizar cada una contra lo que de verdad la limita: la latencia en la primera, la calidad por token en la segunda.

La arquitectura vive ahora en la capa de control, no en el modelo. Lo que devuelve a escena la frase de el abismo de la fiabilidad: un agente no es un LLM con herramientas, es un sistema donde el LLM es un componente. Jev convierte esa frase en literalmente cierta en vez de aspiracional, porque fuerza a que las decisiones de bifurcación salgan del modelo y entren en el código, donde puedes verlas.

Seis cosas que cambian

1. El flujo de control vuelve al código

Una bifurcación pasa a ser un valor tipado que lees y sobre el que actúas, en vez de una frase que esperas que sea estable.

Antes, la política de enrutado vivía en un system prompt: “Clasifica el ticket en una de estas categorías: facturación, técnico o cuenta.” Nadie podía revisarla, nadie podía compararla con un diff, y cualquier edición no relacionada del prompt podía perturbarla.

Después, el conjunto de opciones y los criterios se declaran de antemano y viven en control de versiones, junto al código que bifurca sobre ellos. Puedes hacer test unitario de la bifurcación. Puedes comparar un cambio de política con un diff y ver exactamente qué se movió.

La implicación incómoda es la útil: tus reglas de enrutado pasan a ser artefactos revisables, lo que significa que alguien tiene que revisarlos. Los equipos que han estado cambiando en silencio el enrutado de clientes editando un prompt tendrán que empezar a tratar eso como un cambio de política con revisión y aprobación. Es una mejora de gobierno, y durante un mes se sentirá como fricción.

2. Las comprobaciones previas a la acción reciben por fin un dato numérico

Pregunta a cualquiera que haya construido barandillas cómo funcionan y obtendrás una de dos respuestas. O son deterministas — regex, listas blancas, validación de esquema — o son una instrucción cuidadosa en el system prompt pidiendo al modelo que por favor tenga cuidado, lo cual no es un control, es un deseo.

Un puntuador calibrado te da una tercera opción. Un ejemplo documentado: un rm -rf ambiguo volvió clasificado como irreversible con probabilidad 0,56, y solo 0,33 de confianza en ese juicio. Un número sobre el que puedes poner un umbral, y un número que te dice que el propio modelo no está seguro — justo la firma que quieres en el camino hacia un humano.

Pero ojo con el riesgo de segundo orden, porque es fácil pasarlo por alto. Una barrera que lee texto controlado por un atacante es una superficie de ataque nueva. El contenido adversarial dentro del estado puede desviar las respuestas. Así que el plano de decisión añade una comprobación probabilística; no sustituye las deterministas. Si tu única defensa contra una llamada destructiva a herramienta es un modelo leyendo un documento que escribió un atacante, has movido el problema en lugar de resolverlo. La lista blanca se queda.

3. La matemática de la fiabilidad cambia de forma

El problema del compounding es real y no perdona: un agente con 95% de fiabilidad por acción acierta el 36% de las tareas de 20 pasos. El instinto es leer Jev como la solución a eso. No lo es, y la versión honesta es más interesante.

Jev es menos preciso que los modelos frontera contra los que compite por precio — en el propio benchmark del proveedor, en todas las tareas. Así que la forma de la mejora no es “cada paso ahora acierta el 99%”.

Es que el sistema ahora sabe cuándo no sabe. Un paso con 95% de precisión que reporta 0,4 de confianza es un paso que puedes escalar. Un paso con 95% de precisión que no reporta nada te obliga a confiar en él igual que en el que reporta 0,98. La calibración convierte un fallo invisible en una bifurcación visible, y una bifurcación visible es una que puedes rodear.

Dos advertencias honestas. La calibración es agregada: 0,9 no significa que esta respuesta sea correcta, significa que las respuestas que diste a 0,9 fueron correctas alrededor del 90% de las veces. Y es una propiedad que debes verificar con tus propios datos: una puntuación de confianza que no has testeado es decoración.

4. El coste se hunde, así que el fan-out pasa a ser el instinto barato

A 0,042 $ por millón de tokens de entrada y salida gratuita, un ticket de soporte de 300 tokens cuesta unos 0,0000126 $ — aproximadamente 1,26 $ por cada 100.000 tickets. A ese precio, la aritmética que ha dado forma a tus diseños durante dos años se invierte.

El instinto viejo: meterlo todo en un prompt, porque cada llamada extra al modelo es otro ida y vuelta y otra montaña de tokens. De ahí los prompts clasificadores enormes, las instrucciones de “haz estas cinco cosas en una sola respuesta” y el JSON frágil que parseas de la prosa.

El instinto nuevo: hacer trece preguntas estrechas sobre un mismo estado en una sola llamada. TypeSafe midió un lote de 13 preguntas como 12,2x más barato y 10x más rápido que trece llamadas secuenciales, y la latencia apenas se mueve al añadir preguntas, porque corren en paralelo contra una única lectura del estado.

Y no es solo más barato. Trece preguntas con sus propios criterios son trece unidades testeables, donde un prompt haciendo cinco trabajos es un bloque único e improbable. El fan-out barato es mejor ingeniería, no solo mejor economía.

5. Las decisiones entran por debajo del umbral de interacción

70–500 ms, la mayoría cerca de 100 ms, frente a segundos de un modelo frontera. Hay una línea real alrededor de los 300 ms: por debajo, una decisión puede estar en línea en el camino crítico y nadie lo nota. Por encima de un segundo, hay que diseñar alrededor de ella, esconderla tras un spinner o sacarla de la petición.

La mayoría de las barandillas empresariales de hoy se muestrean o se difieren precisamente porque son demasiado lentas para ejecutarse en cada llamada. Así es como acabas diciendo en voz baja la frase que nadie quiere decir: revisamos alrededor del 5% de las llamadas a herramientas. Con la latencia del plano de decisión puedes revisarlas todas. En línea es la diferencia entre un control y una muestra.

6. El gobierno mejora y empeora en el mismo movimiento

Mejor: la política de decisión se convierte en un artefacto de primera clase. Las opciones y los criterios se declaran de antemano, así que un revisor lee la rúbrica en lugar de inferir la intención de un system prompt. Está versionada, se puede comparar con un diff, y no cambia porque alguien haya ordenado el prompt por motivos no relacionados.

Peor: no hay justificación por decisión, porque no hubo razonamiento. Y que la salida cumpla el esquema no es lo mismo que ser correcta — el modelo devolverá una etiqueta bien formada que enruta a la cola equivocada. La afirmación de “cero alucinación” es una garantía sobre el tipo, no sobre la verdad. Una barrera equivocada con seguridad es peor que ninguna barrera, porque falla en silencio y falla a escala.

Para decisiones que tocan regulación, auditoría o confianza del usuario, la ausencia de traza de razonamiento descalifica por sí sola. Para un salto de enrutado o la elección de una cola, nadie iba a leer la explicación de todos modos.

El problema de la precisión, dicho sin rodeos

Esta es la parte que decide si deberías prestar atención, así que merece ser directo.

En el propio panel del proveedor — 711 casos en cuatro tareas, con respuestas de referencia promediadas de dos modelos frontera en lugar de verdad de base — Jev puntuó 67,8% en total frente a 74,1% del mejor comparador. Procesamiento de facturas: 61,8% frente a 79,1%. Atención al cliente: 76,0% frente a 78,3%. La brecha es consistente en todas las tareas, y el proveedor la publica.

Pruebas independientes en una tarea de clasificación de doce pasajes con defectos plantados: Jev detectó 6 de 7; un modelo frontera detectó los 7 — a unas 25 veces la latencia y una fracción pequeña del coste, pero no en paridad, y no en paridad en lo que más importa, que es el recall sobre los defectos.

Así que: una sustitución ingenua pierde. Todos los gráficos de este sector son gráficos de latencia y coste. Si cambias el LLM por un modelo de decisión donde la precisión es la restricción activa, enviarás a producción un sistema peor que es más rápido y más barato, y finanzas estará encantada durante un trimestre.

Por eso la arquitectura que justifican las cifras no es una sustitución. Es una cascada:

   state ──▶ ┌──────────────┐  p ≥ threshold   ┌─────────────────┐
             │ DECISION     │─────────────────▶│  act            │
             │ PLANE (Jev)  │                  └─────────────────┘
             └──────┬───────┘
                    │ p < threshold
                    ▼
             ┌──────────────┐        ┌──────────────────────────┐
             │ ESCALATE     │───────▶│ GENERATION PLANE (LLM)   │
             │              │        │  or human reviewer       │
             └──────────────┘        └──────────────────────────┘
                    │
                    ▼
             log the probability vector

Jev decide primero, barato, sobre todo. Todo lo que quede por debajo del umbral sube un nivel. El vector de probabilidades se registra con cada decisión.

Obtienes el 70–80% de tu volumen a la economía del plano de decisión y conservas el juicio frontera para el resto — y lo obtienes porque el modelo barato reporta confianza calibrada en lugar de prosa plausible. Esa última cláusula es todo el truco. Un modelo barato que no puede decirte cuánto de seguro está no se puede cascadear; no tendrías señal sobre la que enrutar.

Dónde encaja y dónde no

El patrón de esa tabla no es el sector en el que estás. Es el coste de equivocarse, y si alguien va a preguntar alguna vez por qué.

Una forma de referencia

Tomemos la entrada de facturas de proveedor — la misma pregunta que hacía la demo original, ejecutada como sistema en producción y no como demo.

Leer. Parsea de forma determinista donde el formato lo permita, y usa el plano de generación para el resto desordenado. La extracción es un trabajo de escritura; es genuinamente para lo que sirve el LLM.

Decidir. Una llamada, varias preguntas, evaluadas contra el mismo estado:

POST /v1/systemone
{
  "model": "jev-latest",
  "state": "<invoice text, PO reference, vendor history, prior payments>",
  "questions": {
    "routing":    { "type": "choice", "options": ["straight_through", "review", "reject"],
                    "criteria": "Straight through only when the PO matches exactly..." },
    "p_fraud":    { "type": "noul", "instructions": "This invoice is fraudulent." },
    "p_duplicate":{ "type": "noul", "instructions": "This invoice duplicates a prior payment." },
    "po_match":   { "type": "score", "levels": 5,
                    "criteria": "How well the line items match the purchase order." }
  }
}

Bifurca en código, sobre números y no sobre frases:

const { routing, p_fraud, p_duplicate, po_match } = await jev(state, questions);

// Los umbrales de abajo son ilustrativos. Prueba los tuyos antes de confiar en ninguno.
if (p_fraud.noul > 0.9 || p_duplicate.noul > 0.9) return reject();

if (routing.confidence < 0.7 || po_match.score < 3 || po_match.confidence < 0.6)
  return escalate({ reason: "low confidence", routing, po_match });

// El resumen para el revisor es trabajo de escritura — plano de generación.
if (needsReviewerNote) await llm.summarise(state, routing);

return straightThrough(routing);

Registra el vector de probabilidades con la decisión. Ese log es ahora tu rastro de auditoría, y es mejor que la prosa que nunca estabas leyendo: registra qué creía el sistema, con cuánta fuerza y qué umbral cruzó. Cuando un revisor anula una decisión, tienes el número exacto que la produjo — que además son los datos que necesitarás para ajustar el umbral después.

Fíjate en qué le ha pasado al flujo de control. Son sentencias if. Es testeable, revisable, y no cambia cuando alguien edita un prompt.

Qué hacer el lunes

1. Mide la proporción. Instrumenta treinta días de llamadas al LLM y etiqueta cada una como decisión o generación. Casi nadie tiene este número, y es todo el caso de negocio. En la mayoría de stacks empresariales aterriza entre el 60% y el 80% con forma de decisión. Medido, no afirmado.

2. Testea calibración, no precisión. Construye un conjunto etiquetado a partir de trazas de producción, agrupa las predicciones por confianza reportada y comprueba la tasa de acierto observada en cada grupo. Si tu grupo de 0,9 acierta el 60% de las veces, tienes un puntuador, no un modelo calibrado — y cada umbral que pongas sobre él es una corazonada disfrazada de número. Este único test determina si la cascada funciona.

3. Empieza por el cuadrante. Error barato, lentitud cara. Gánate el derecho a acercarlo a las decisiones que importan.

4. Escribe los umbrales en código y versiónalos. Los umbrales son política. La política que no está versionada no es política.

5. Conserva el LLM. Esto es una partición, no una sustitución. Cuando el tráfico de decisiones deja de competir con él por presupuesto, el plano de generación se vuelve más útil, no menos — porque por fin puedes permitirte darle el contexto y el cuidado que escribir de verdad merece.

El punto

La afirmación citable es 200x. La defendible es más estrecha y bastante más útil: la capa de decisión nunca fue trabajo del modelo de lenguaje, y las empresas llevan años pagando precios de generación para obtener una sentencia de bifurcación.

Cuando aceptas la partición, la arquitectura se reorganiza alrededor. Determinista donde puede. Generativa donde debe. Una probabilidad calibrada y un umbral explícito en medio — que es un sitio mucho mejor para poner una frontera que una frase en un system prompt.

La pregunta de las luces de la oficina no necesita una memoria. Necesita un interruptor, una política sobre quién puede tocarlo y un registro de quién lo hizo. Por primera vez, las tres cosas son algo que puedes comprar.

La afirmación interesante no es que un modelo se haya vuelto más rápido. Es que una capa de tu arquitectura estaba en el sitio equivocado.

Preguntas frecuentes

¿Por qué Jev cambia la arquitectura de los agentes?

Porque la mayor parte del tráfico de agentes en la empresa tiene forma de decisión — enrutado, triaje, clasificación, filtrado — y hoy cada una de esas decisiones la produce un modelo autorregresivo generando texto. Eso convierte tu flujo de control en lenguaje natural interpretado por un proceso de muestreo. Cuando las decisiones tienen su propio motor, pasan a ser valores tipados sobre los que tu código bifurca, lo que devuelve el flujo de control al software, donde se puede testear, versionar y revisar.

¿Qué es un “plano de decisión” en la arquitectura de agentes?

Es la capa de un agente responsable de las elecciones estructuradas en lugar de la prosa: qué cola, qué modelo, qué herramienta, si esto es seguro, si esto es suficientemente bueno. En la arquitectura Jev se separa del plano de generación (que escribe, razona y sintetiza) y ambos se unen mediante una capa de control en código que sostiene los umbrales, las reglas de escalado y el log de auditoría. El plano de decisión soporta la mayoría de las llamadas; el de generación, la mayoría de los tokens.

¿Puede Jev sustituir al LLM de mi agente?

No, y intentarlo empeorará tu sistema. En el propio benchmark del proveedor Jev puntúa 67,8% frente a 74,1% del mejor LLM comparable, y 61,8% frente a 79,1% en procesamiento de facturas; las pruebas independientes encontraron que detectaba 6 de 7 defectos plantados donde un modelo frontera detectaba los 7. La arquitectura que justifican las cifras es una cascada: el modelo de decisión se encarga de todo aquello en lo que tiene confianza, y los casos de baja confianza escalan al LLM o a un humano.

¿Cómo debería fijar los umbrales de confianza?

En código, con los valores en control de versiones, y solo después de testear la calibración con tus propios datos etiquetados. Agrupa las predicciones por confianza reportada y comprueba la tasa de acierto observada en cada grupo. Si el grupo de 0,9 acierta el 60% de las veces, ningún umbral tiene sentido todavía. Como la calibración es agregada, una confianza de 0,9 significa que las respuestas dadas a 0,9 fueron correctas alrededor del 90% de las veces — no que ninguna respuesta concreta sea correcta.

¿Cuál es el riesgo de usar un modelo de decisión como barandilla?

Tres. El contenido adversarial en el estado puede desviar las respuestas, así que una barrera probabilística que lee texto controlado por un atacante es una superficie de ataque nueva — conserva la lista blanca determinista. Que la salida cumpla el esquema no es lo mismo que ser correcta: el modelo puede devolver una etiqueta bien formada que enrute al destino equivocado, y la afirmación de “cero alucinación” va sobre el tipo de salida, no sobre la verdad. Y no hay traza de razonamiento, así que una barrera equivocada falla en silencio. Equivocarse con seguridad es peor que no tener barrera cuando ocurre a escala.

¿Qué casos de uso empresariales encajan mejor con Jev?

Empieza donde un error cuesta poco y la lentitud cuesta cara: triaje y enrutado de tickets de soporte, enrutado de modelos dentro del bucle del agente, puntuar y verificar la salida del LLM, y barreras para llamadas a herramientas respaldadas por comprobaciones deterministas. El procesamiento de documentos y facturas encaja de forma condicional, con el escalado tratado como obligatorio. La planificación a largo plazo, la síntesis, la generación de código y cualquier decisión que requiera una justificación auditable no encajan en absoluto.

Sobre el autor

Vinci Rufus es tecnólogo y escritor, centrado en construir sistemas de IA fiables y arquitecturas de agentes. Escribe sobre los retos prácticos de las implementaciones de IA en producción y sobre los patrones arquitectónicos que separan a un agente de demo de un sistema listo para producción. Su trabajo cubre el modelo que se niega a escribir, el abismo de la fiabilidad en los agentes de IA y el diseño de flujos de trabajo agénticos.