Enrutamiento de agentes con Jev y LangChain

En un agente de IA, Jev se encarga de las pequeñas decisiones entre llamadas al LLM: qué herramienta o skill usar, qué modelo debe dar el siguiente paso, si el agente debe continuar o pasar el relevo y si una llamada a una herramienta parece demasiado arriesgada para ejecutarla. TypeSafe y sus socios documentan patrones para el enrutamiento por intención, la elección de modelo, las decisiones de continuar o parar y el control de riesgo de herramientas; no hay ningún patrón documentado para decidir reintentos. Antes de pasar cualquiera de estas decisiones de un LLM a Jev, reproduzca sus propias decisiones registradas con ambos y compare precisión, latencia y coste.

Esta guía recoge lo que muestra la documentación oficial de TypeSafe, LangChain, Vercel y Cloudflare a fecha de octubre de 2026, y marca con claridad cuándo describimos una idea de diseño y no una funcionalidad documentada. No hemos desplegado Jev en ningún sistema de cliente. Para el contexto sobre el modelo en sí, consulte qué es Jev.

¿Dónde están las decisiones de enrutamiento en un agente?

La mayoría de los agentes ejecutan un bucle: leer la tarea y el último resultado de una herramienta, decidir qué hacer a continuación, actuar y repetir. La parte de «decidir» suele esconder varias preguntas distintas que un LLM responde de forma implícita dentro de un único prompt largo. Un modelo de decisión las hace explícitas. El esquema siguiente es pseudocódigo neutral respecto al proveedor, no código de la API de Jev:

loop:
    state = compact summary of task, last tool result, step count
    answers = decision_model(state, [which_tool, needs_strong_model,
                                     tool_call_risky, should_continue])
    if any answer is below its confidence threshold:
        hand the step to an LLM or a person
    elif tool_call_risky is likely:
        refuse the call, or ask for approval
    else:
        run the chosen tool with the chosen model
    if not should_continue: stop

Dos indicaciones de la documentación de TypeSafe condicionan este diseño. Las preguntas deben ser atómicas: los juicios amplios se dividen en varias preguntas y se combinan en código. Y el estado debe ser breve: Jev «sufre de context rot» cuando el estado está lleno de detalles irrelevantes (Jev 1.13 jaggedness). Pasar la transcripción completa es un mal punto de partida; pase lo que necesita la decisión.

Enrutamiento por intención y por herramienta

El patrón de enrutamiento por intención de TypeSafe es el ejemplo oficial más claro. Una pregunta Choice clasifica la petición, una pregunta Score puntúa la complejidad y código normal decide adónde va: las consultas sobre el estado de un pedido, a código determinista; las preguntas sobre productos y devoluciones, a prompts de LLM especializados; las reclamaciones, a un LLM o a una persona según su complejidad. Lo que tiene baja confianza va a una persona. La función de enrutamiento, tal como está publicada:

def route_ticket(ticket_id, response):
    intent = response.answers["intent"]
    complexity = response.answers["complexity"]

    if intent.confidence < 0.5:
        # If we don't have enough confidence to classify, route to a human agent
        return route_to_human_agent(ticket_id)

    if intent.choice == "order_status":
        handle_order_status(ticket_id)
    elif intent.choice == "product_question":
        handle_with_llm(ticket_id, PRODUCT_SPECIALIST)
    elif intent.choice == "return_exchange":
        handle_with_llm(ticket_id, RETURNS_SPECIALIST)
    elif intent.choice == "complaint":
        low_confidence = complexity.confidence < 0.5
        # A higher complexity.score leans toward the "escalation needed" end of the scale.
        if complexity.score > 1 or low_confidence:
            # Too complex for safe automation, or we're not sure about the complexity; route to a human.
            route_to_human_agent(ticket_id)
        else:
            handle_with_llm(ticket_id, COMPLAINT_RESOLUTION)

Para la selección de herramientas propiamente dicha, TypeSafe tiene dos cookbooks. El cookbook de function calling traduce el nombre de una función y sus argumentos de conjunto cerrado (literales y booleanos) a preguntas Choice y Noul, con una petición por comando. Los argumentos enteros, de texto libre y de fecha conservan sus valores por defecto, y eso marca dónde termina el enfoque: Jev elige la función, pero no rellena valores abiertos. El cookbook de sugerencia de skills usa dos peticiones a Jev para elegir como máximo una de 182 skills. En la prueba de la propia TypeSafe con 488 peticiones frente a Claude Haiku 4.5, la tasa de carga de la skill equivocada bajó del 16,8 % al 7,3 %, y la de cargar una skill cuando ninguna encajaba, del 9,8 % al 4,0 %. Es un resultado del proveedor sobre una tarea elegida por el proveedor.

Para los menús de herramientas importan dos límites. Un Choice admite como máximo 255 opciones, y la documentación de TypeSafe indica que Jev «tiende hacia la opción que aparece primero». Si su lista de herramientas tiene un orden fijo, compruebe si la primera herramienta gana más a menudo de lo que debería.

Elección de modelo con LangChain

LangChain mantiene el paquete langchain-typesafe (alfa, 0.0.1a3 en el momento de escribir esto), con un Runnable TypeSafeClassifier y dos clases de middleware marcadas como experimentales. ModelRouterMiddleware elige qué modelo ejecuta un paso. Este fragmento procede de la página del proveedor en LangChain:

from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import (
    ModelChoice,
    ModelRouterMiddleware,
)

router = ModelRouterMiddleware(
    choices={
        "fast": ModelChoice(
            model="openai:gpt-5.6-terra",
            criteria="Direct lookups, extraction, and localized changes with explicit targets.",
        ),
        "powerful": ModelChoice(
            model="openai:gpt-6-astra",
            criteria="Architecture, novel root-cause reasoning, and high-stakes decisions.",
        ),
    },
    instructions="Choose the least costly model that can complete the task safely.",
)

agent = create_agent("openai:gpt-5.6-terra", middleware=[router])

El ejemplo completo de esa página sigue con agent.invoke(...) y lee la ruta elegida en result["model_route"].choice. El enrutamiento entre modelos es también uno de los usos que propuso Armin Ronacher, CTO de Earendil, cuando TechCrunch le preguntó por Jev. La economía es fácil de razonar: la llamada al enrutador es barata, así que se paga sola si envía suficientes pasos al modelo más barato sin empeorar los resultados. Si lo consigue o no es justo lo que hay que medir. Nuestra comparativa de costes de LLM muestra la diferencia de precio entre gamas de modelos que aprovecharía un enrutador así.

Reintentos, continuación y escalado

Aquí la documentación es escasa, y conviene ser preciso. El contenido oficial de TypeSafe sobre reintentos se refiere al transporte: los SDK reintentan los errores 429 y 529 con backoff exponencial y respetan retry-after. No hay ningún patrón oficial para usar Jev a la hora de decidir si un agente debe reintentar un paso fallido.

El ejemplo documentado más cercano es la comprobación de continuar o parar de Vercel, en el changelog de su AI Gateway:

import { TypeSafeClient } from '@typesafe-ai/sdk';

const client = new TypeSafeClient({
  apiKey: process.env.AI_GATEWAY_API_KEY,
  baseURL: 'https://ai-gateway.vercel.sh/typesafe',
});

const result = await client.systemOne({
  state: 'The agent fixed the checkout bug and all tests pass.',
  questions: {
    continueWorking: {
      type: 'noul',
      instructions: 'Should the agent take another step?',
    },
  },
});

const shouldContinue = result.answers.continueWorking.noul >= 0.8;

Una decisión de reintento podría seguir la misma forma, y la presentamos solo como idea de diseño. Tras una llamada fallida a una herramienta, se plantean preguntas sí/no como si el error parece transitorio o si es probable que la misma llamada con otros argumentos funcione. El número de reintentos y el backoff se quedan en el código; la documentación de Jev dice que no cuenta de forma fiable. Si las respuestas son inciertas, escale en lugar de reintentar.

Para los umbrales de escalado, el patrón de enrutamiento por confianza de TypeSafe muestra un flujo de banca por voz con un mínimo de confianza de 0,6 y aprobación automática de una transferencia solo por encima de 0,85. Tenga en cuenta que las respuestas Noul no tienen campo confidence, así que en las preguntas sí/no el umbral se aplica a la propia probabilidad, como en el >= 0.8 de Vercel. Una prueba independiente de AY Automate usó un corte de confianza de 0,80 para enviar los casos dudosos a GPT-5.6 Terra y alcanzó un 90,0 % de precisión con alrededor del 26 % del coste de Terra. Son sus cifras, con sus datos; sus umbrales tienen que salir de los suyos.

Control de riesgo de herramientas

El middleware experimental AutoModeMiddleware(tools=[...]) de LangChain «pide la probabilidad de que una llamada a una herramienta sea arriesgada o no esté suficientemente autorizada». Las llamadas que se consideran arriesgadas devuelven un ToolMessage de error en lugar de ejecutarse. Merece la pena repetir la advertencia de la propia LangChain: «Este middleware rechaza las llamadas arriesgadas. No solicita aprobación». Si su agente necesita un paso de aprobación humana, tendrá que construirlo usted.

La advertencia más importante es la inyección de prompts. La documentación de Jev dice que el estado son datos y que el modelo «no lo trata como hostil por defecto». VentureBeat informó de una prueba de Octomind en la que un campo falso de «preaprobado» bajó la probabilidad de bloqueo de rm -rf ~/.ssh de 0,76 a 0,48. La postura de Pydantic, citada en el mismo artículo, es la sensata: una protección basada en Jev «va junto a las comprobaciones deterministas, no en su lugar». En la práctica, eso significa listas de permitidos y denegados, validación de argumentos y comprobación de permisos en código primero, y Jev puntuando la zona gris que las reglas no cubren.

Notas de integración: LangChain, Vercel, Cloudflare y Pydantic

LangChain: langchain-typesafe se mantiene en el repositorio langchain-ai, pero está en alfa y las dos clases de middleware son experimentales. Cuente con cambios en la API.
Vercel AI Gateway: el modelo es typesafe-ai/jev, accesible a través del cliente de TypeSafe con una URL base de la pasarela (como arriba), de un endpoint HTTP /v1/evaluate o del AI SDK mediante @ai-sdk/typesafe-ai. Las páginas de Vercel no coinciden en el nombre de la función del AI SDK (experimental_evaluate en el changelog, experimental_decide en la guía de integraciones, más reciente), así que revise la documentación actual antes de copiar código. La API nativa de la pasarela llama boolean al tipo sí/no, con un campo .probability, donde TypeSafe usa noul. Vercel indica además que su framework de agentes eve usa Jev como modelo de evaluación por defecto.
Cloudflare Workers AI: la llamada es env.AI.run('typesafe/jev', { state, questions }) con el esquema de preguntas de TypeSafe (página del modelo). Cloudflare indica retención cero de datos y una ventana de contexto de 32.000 tokens, frente a los 64k por petición que declara TypeSafe.
Pydantic AI: TypeSafeModel y TypeSafeProvider mediante el extra pydantic-ai-slim[typesafe], con su propia clave de TypeSafe y sin streaming (Pydantic).

Sea cual sea la vía, fije la versión del modelo (jev-1.13.0) una vez ajustados los umbrales. El alias jev-latest cambiará.

Cómo evaluar Jev con su propio tráfico

Los benchmarks publicados no coinciden, y las evaluaciones de la propia TypeSafe puntúan frente a etiquetas generadas por dos LLM frontera, de modo que miden acuerdo, no acierto. Las únicas cifras que deberían decidir un cambio son las de su propio tráfico. Un método viable:

Extraiga decisiones registradas de las trazas de su agente: el estado en el momento de decidir, la elección que hizo su LLM actual y el resultado, cuando lo conozca.
Etiquete una muestra a mano, incluidos los casos difíciles y los costosos. Usar otro LLM como referencia repite el problema de los benchmarks de los proveedores.
Formule cada decisión como preguntas atómicas de Jev. Cuente con varias iteraciones: en la prueba de phishing resumida por Beri.net, dividir una pregunta amplia en cinco cambió el resultado más que la elección del modelo.
Reproduzca la muestra offline con Jev y con su LLM de referencia actual.
Compare por tipo de decisión: precisión o macro-F1, la matriz de confusión para los errores caros y la calibración. Ajuste los umbrales por pregunta; Beri.net comprobó que la calibración de Jev de serie no es fiable.
Mida la cobertura con cada umbral: qué parte resuelve Jev solo y qué parte se escala al LLM.
Mida la latencia p50 y p95 desde la región en la que despliega. Las cifras de los proveedores se tomaron desde la costa oeste de Estados Unidos.
Calcule el coste por cada 1.000 decisiones, incluidas las llamadas al LLM de los casos escalados.
Añada un conjunto adversarial con instrucciones inyectadas en el estado, sobre todo para las preguntas de riesgo de herramientas.
Ejecute en modo sombra sobre tráfico real antes del cambio y mantenga la vía del LLM como respaldo.

Si el resultado es ajustado, lo que suele decidir es el volumen de decisiones y lo caro que resulta cada tipo de error. Tiene una visión más amplia de los costes de los agentes en nuestro artículo sobre el coste de desarrollar un agente de IA, y las ventajas e inconvenientes generales en Jev vs LLM.

Preguntas frecuentes

¿Funciona Jev con LangChain?

Sí. LangChain mantiene langchain-typesafe, que incluye un Runnable TypeSafeClassifier y, de forma experimental, ModelRouterMiddleware para elegir modelo y AutoModeMiddleware para el control de riesgo de herramientas. El paquete está en alfa.

¿Puede Jev elegir herramientas para un agente de IA?

Sí, cuando las opciones son cerradas. El cookbook de function calling de TypeSafe traduce nombres de funciones y argumentos de conjunto cerrado a preguntas Choice y Noul, mientras que los argumentos enteros, de texto libre y de fecha necesitan otra fuente. Un solo Choice admite hasta 255 opciones.

¿Tiene Jev una política de reintentos integrada?

Solo para errores de transporte: los SDK reintentan las respuestas 429 y 529 con backoff. Decidir si un agente debe reintentar un paso fallido no es un patrón documentado de Jev, aunque Vercel muestra una comprobación relacionada de continuar o parar.

¿Es seguro usar Jev como única protección en las llamadas a herramientas?

No. El contenido inyectado en el estado puede alterar sus respuestas, como demostró una prueba de Octomind publicada por VentureBeat. Úselo junto con comprobaciones de permisos deterministas, y tenga en cuenta que el middleware de LangChain rechaza las llamadas arriesgadas, pero no pide aprobación.

¿Cómo debo fijar los umbrales de confianza para el enrutamiento?

Ajústelos por pregunta con sus propios datos etiquetados. Los patrones de TypeSafe usan 0,5, 0,6 y 0,85 en distintos ejemplos, y el ejemplo de Vercel usa 0,8 sobre una probabilidad Noul, pero cada valor se eligió para un ejemplo concreto.

Construir la capa de enrutamiento

Un modelo de decisión cambia la forma de un agente: la lógica de enrutamiento sale de los prompts y pasa a preguntas tipadas, umbrales y código que se puede probar. Eso puede abaratar el sistema y facilitar su auditoría, siempre que alguien se haga cargo de la evaluación y de las vías de respaldo. En AI Superior diseñamos y desarrollamos agentes de IA y aplicaciones LLM para clientes B2B, con enrutamiento entre modelos, evaluación offline y control de costes como parte de la arquitectura. Si está planteando esto para producción, consulte nuestros servicios de despliegue de LLM.

Enrutamiento de agentes con Jev: selección de herramientas, elección de modelo y reintentos