Qué es en realidad el enrutado de herramientas
Un agente decide qué herramienta llamar a continuación. Lee el estado actual de la tarea, considera las funciones que se le han dado y elige una. Ese paso se llama enrutado de herramientas y ocurre muchas veces dentro de una misma ejecución.
La mayoría de los agentes implementan el enrutado como una conversación. Las herramientas se describen en un prompt, se pide al modelo que elija una y la respuesta se analiza para recuperar el nombre de una función. Funciona con la frecuencia suficiente para publicarlo, y falla de maneras molestas de depurar.
Un modelo de decisión trata el enrutado como lo que es: una pregunta tipada con un conjunto fijo de respuestas permitidas. Las herramientas se convierten en las opciones, y el modelo devuelve una probabilidad para cada una.
Por qué el enrutado por conversación es frágil
Cuando el enrutado pasa por una conversación, el nombre de la herramienta llega dentro de prosa o de un fragmento de JSON a medio formar. Si el modelo inventa una función que no existe, el agente falla o cae en silencio a un valor por defecto.
El problema mayor es que la elección no está cuantificada. Obtienes un nombre sin confianza, así que no puedes distinguir un empate ajustado entre dos herramientas de un ganador claro, y no tienes dónde colocar una regla de respaldo.
Cada arreglo se convierte en una edición del prompt, y las ediciones del prompt son suposiciones. La lógica de enrutado acaba repartida entre ejemplos, instrucciones y analizadores en lugar de vivir en código revisable.
El esquema de una decisión de enrutado
Con un modelo de decisión, el estado es la conversación hasta el momento, el objetivo de la tarea y los resultados intermedios. El esquema es una pregunta de enumeración que lista las herramientas exactas que el agente puede llamar.
Clef y Clef-Flash leen ese estado y ese esquema juntos y devuelven una probabilidad por herramienta en una sola pasada. Clef es el modelo de precisión de 27B; Clef-Flash es el modelo de latencia de 9B, entrenado a partir de Qwen3.5-9B. Ambos admiten un contexto de 64k tokens e incluyen un codificador de visión.
El agente nunca ve un nombre de herramienta que no estuviera en la enumeración. La decisión de enrutado queda restringida antes de que el modelo se ejecute, lo que elimina toda una clase de errores en tiempo de ejecución.
La enumeración es el contrato completo. Si una herramienta aún no existe, no aparece en el esquema y el agente no puede llamarla. Cuando se publica una herramienta nueva, añades una opción y la despliegas de forma gradual como cualquier otro cambio de esquema.
Puntuar candidatas en lugar de generar texto
Como cada candidata se puntúa a partir de la misma evaluación del mismo estado, las probabilidades son directamente comparables. Una puntuación de 0,72 para buscar y 0,19 para base de datos es significativa de una forma en que dos respuestas en prosa separadas nunca lo son.
Esa comparabilidad te permite añadir una regla de margen: llamar a una herramienta solo cuando su probabilidad supera un umbral y saca una ventaja determinada a la siguiente. En caso contrario, el agente puede pedir una aclaración o detenerse.
También te permite registrar la distribución completa. Tras un incidente puedes ver si el modelo estaba dividido entre dos herramientas o si estaba seguro y sencillamente se equivocó, que es un problema distinto con un arreglo distinto.
Los argumentos son otra pregunta
Elegir una herramienta es solo la mitad de la decisión. Una vez seleccionada, el agente necesita argumentos, y también pueden expresarse como preguntas tipadas en la misma petición.
Una pregunta de número acotado puede fijar un tamaño de página o un límite. Una enumeración puede fijar un orden. Un campo de texto libre puede capturar una frase de búsqueda cuando el estado lo exige.
Ejecutar la selección y el relleno de campos en una sola pasada mantiene ajustado el bucle del agente y evita un segundo viaje de ida y vuelta que añadiría latencia a cada paso.
Cuándo no debe llamarse a ninguna herramienta
Un enrutador fiable debe poder decir que no. Algunos turnos necesitan aclaración, otros una respuesta final y otros que el agente se detenga por completo.
Añadir candidatas como pedir-aclaracion o finalizar entre las opciones da al modelo una vía legítima para rechazar la herramienta obvia. Sin esa salida de emergencia, una elección forzada produce disparates con seguridad.
Este único cambio corrige buena parte de los agentes desbocados, porque el modelo ya no tiene que inventar una llamada cuando ninguna está justificada.
Latencia dentro del bucle del agente
El enrutado ocurre en cada paso, así que su latencia se multiplica a lo largo de una ejecución. Un enrutador lento hace que todo el agente se sienta pesado incluso si cada herramienta individual es rápida.
Clef-Flash se creó justamente para esta forma de trabajo. Las cifras publicadas sitúan su latencia mediana en torno a 39 ms y su p95 cerca de 122 ms, con un precio de entrada reportado cercano a 0,09 dólares por millón de tokens.
Se ejecuta con unos 41 GB de VRAM en local, mientras que Clef necesita unos 85 GB, así que un bucle sensible a la latencia cabe en un único acelerador, y las ejecuciones de mayor precisión pueden escalar al modelo grande sin cambiar el esquema.
El almacenamiento en caché también ayuda. Las peticiones de enrutado para estados idénticos se pueden cachear, y la forma determinista de la salida hace que eso sea seguro de una manera que las respuestas en prosa no permiten.
Barreras de seguridad y auditabilidad
Un enrutador restringido es más fácil de proteger. Como el espacio de salida es fijo, puedes rechazar cualquier respuesta fuera de él antes de que llegue a tu ejecutor, y puedes limitar el número de veces que puede ejecutarse una herramienta concreta.
Las probabilidades también alimentan la política. Si la mejor herramienta es destructiva y su puntuación no es concluyente, el agente puede deferir a una persona en lugar de actuar. Esa regla es código de aplicación normal, no otro prompt.
Cada decisión de enrutado puede almacenarse con su distribución, su umbral y la herramienta elegida, lo que da un rastro de auditoría que explica el comportamiento del agente a posteriori.
Un patrón concreto
Imagina un agente de investigación con tres herramientas: buscar, descargar-pagina y resumir. En cada turno recibe el objetivo y lo que ha reunido hasta el momento.
El enrutador puntúa las tres herramientas más finalizar. Buscar gana al principio, descargar-pagina domina cuando ya existe una URL prometedora, y finalizar sube cuando el contexto reunido ya responde al objetivo. Todo es una petición por turno con una distribución que puedes umbralizar.
- Estado: objetivo, historial, resultados intermedios.
- Esquema: buscar, descargar-pagina, resumir, finalizar.
- Regla: actuar solo si el líder supera un umbral y un margen.
- Registro: la distribución completa por turno.
Enruta tu primera llamada de agente
La forma más rápida de probar la idea es describir un estado, listar las herramientas como opciones y leer las probabilidades. El playground hace exactamente eso sin configuración y sin código.
La documentación de la API cubre la forma de la petición y de la respuesta para integrarlo en un bucle real, y el artículo sobre modelos de decisión explica por qué las probabilidades tipadas superan a la prosa en este tipo de elección.