Non cercare il modello migliore. Cerca il Tool Router.
Cada semana aparece un modelo nuevo. El landscape de los LLM se mueve rápido: nuevos pesos, nuevas ventanas, nuevos benchmarks. El resultado es que ningún modelo domina sobre todos — cada uno destaca en una franja.
Y sin embargo la pregunta que recibo más a menudo de los equipos técnicos es siempre la misma: "¿Qué modelo elijo?"
Es la pregunta equivocada.
El problema real: context bloat
Cuando construyes un agente AI productivo — no una demo, no un chatbot de helpdesk, sino un sistema que opera sobre código, documentos, APIs — te enfrentas a un límite arquitectónico antes incluso de tocar los límites del modelo. Cada tool que registras, cada schema MCP que cargas, cada instrucción de sistema que añades infla el contexto. Llegas a 200K tokens de ventana y los consumes todos antes de que el agente haya hecho nada útil.
El ecosistema SDK para agentes AI está convergiendo en un pattern que resuelve esto: el Tool Router. En lugar de cargar todos los tools en el contexto del agente, los organizas detrás de un router dinámico. El agente ve solo los tools relevantes para el task actual. El routing ocurre vía MCP con selección contextual. No es un experimento — es una arquitectura que el mercado está adoptando rápidamente.
Por qué el Tool Router supera el cambio de modelo
El razonamiento común es: si el modelo A no performa en un task, cambia al modelo B. LiteLLM lo hace fácil — unifica decenas de providers detrás de una única API. Pero cambiar de modelo es una operación costosa: distinto system prompt, distintos formatos de tool call, distintos límites de contexto, distinta latencia. Y el modelo B podría ser peor que el modelo A en otros tasks que en el cambio habías dado por sentados.
El Tool Router invierte la lógica. Mantén el modelo mejor para tu caso de uso dominante. Pero en lugar de ahogarlo en un contexto monolítico, dale acceso selectivo a los tools. Menos ruido, más precisión, menos tokens desperdiciados, menos costo por invocación.
Insight práctico: mapea tus tools como harías con los microservicios
Si estás construyendo un agente hoy, haz este ejercicio antes de escribir una línea de código:
1. Inventa tus tools por dominio, no por función. No "tool_leer_archivo" y "tool_escribir_archivo". Sino "tool_gestion_repo", "tool_analisis_log", "tool_deploy_staging". Cada dominio se convierte en un grupo MCP.
2. Define un router que active solo los grupos relevantes para el intent detectado. Si el usuario pide "analiza los errores en producción", el router activa solo el grupo de análisis — no el de deploy.
3. Mide los tokens de system prompt antes y después. Reducir el contexto inicial significa más espacio para el razonamiento efectivo del agente, menos alucinaciones por sobrecarga, respuestas más rápidas.
¿El costo? Una capa de routing más. ¿El beneficio? Un agente que escala horizontalmente sin explotar verticalmente.
El modelo es el motor. La arquitectura es el vehículo.
Un modelo potente con subagentes paralelos es un motor impresionante. Pero un motor V8 sobre un chasis que se hunde no llega a ninguna parte. El Tool Router es el chasis. Es lo que decide si tu potencia se convierte en movimiento o en calor disperso.
Si tu equipo está evaluando qué modelo adoptar y se atasca en los benchmarks — detente. La ventaja competitiva no está en el modelo. Está en la arquitectura de los tools.