Enrutar modelos ahorra tokens. Enrutar el trabajo ahorra la operación.

El enrutamiento de modelos se está volviendo estándar: mandar cada paso del trabajo de un agente al modelo más barato que pueda resolverlo. Es buena ingeniería y va a bajar tu factura. Pero una empresa no funciona con una factura de modelos. Funciona con trabajo que tiene dueño, regla y registro, y enrutar modelos no mejora nada de eso.

Lo que prometen los enrutadores

En una publicación del blog de NVIDIA del 11 de agosto de 2026, NeMo Switchyard se describe como una biblioteca open source de enrutamiento que envía cada paso de un flujo de agentes a un modelo adecuado para ese paso, ajustable por calidad, latencia o costo. NVIDIA dice que mantiene una precisión de nivel frontera y reduce el costo de completar tareas a casi un tercio del que tendría usar solo Opus 4.8, según sus propios benchmarks internos. La misma publicación recoge ahorros reportados por tres socios.

Léelas como lo que son: números del proveedor y de sus socios sobre sus propias tareas. Muestran la dirección, no lo que ahorrará tu operación. Y todas miden lo mismo: el precio de un paso, no si ese paso debería existir.

Lo caro no es el modelo

Piensa dónde está realmente el costo de una empresa. Una llamada a un modelo cuesta fracciones de centavo. Un traspaso equivocado, una solicitud sin dueño, un reporte que se rehace a mano cada mes: ahí se va el dinero. Un enrutador abarata la llamada. No puede decirte que esa llamada era el paso equivocado, ni que alguien está a punto de rehacer su resultado.

Enrutar modelos responde "¿qué cerebro debe hacer esto?". Enrutar el trabajo responde preguntas más difíciles:

• ¿Quién es dueño de este paso? Una persona o un rol con nombre, no "el agente".
• ¿Cuál es la regla? Qué significa terminado y cuándo debe detenerse y preguntar.
• ¿Dónde queda el resultado? El registro que lee el siguiente paso, para que nadie lo vuelva a escribir.
• ¿Qué pasa cuando falla? Una ruta de escalamiento que termina en una persona.

Nada de eso está en la configuración de un enrutador. Es diseño operativo y tiene que existir antes de que el enrutador valga algo.

Un paso más barato en un flujo roto sigue siendo un flujo roto

Si dos equipos llevan cada uno su propia versión de un pedido, un agente enrutado actualizará cualquiera de las dos más rápido y por menos dinero. El costo por llamada baja mientras el retrabajo se queda igual. Es la misma falla de la que ya hemos escrito: velocidad aplicada a un sistema que nadie rediseñó.

Y al revés también se cumple. En el caso de OCESA, Sentynel rediseñó la operación de reportes alrededor de la pregunta que cada persona se hacía, conectando venta de boletos, resultados de patrocinio, ratings y evidencia de medios. El registro del caso reporta −70% de costo operativo reportado, con la nota de que son resultados reportados del proyecto y la comparación de costos está normalizada. Ese resultado vino de cambiar cómo fluye el trabajo, no de elegir un modelo más barato para los mismos pasos.

El enrutamiento va al final

Nada de esto es un argumento contra los enrutadores. Con la operación ya diseñada son justo la herramienta correcta: cada agente corre dentro de un paso que le pertenece y el modelo capaz más barato hace el trabajo de pensar. Lo que importa es el orden. Rediseña primero la operación, pon agentes autónomos dentro de ella y solo entonces optimiza lo que cuesta cada paso.

Una primera prueba para esta semana: toma tu flujo de agentes más caro y lista sus pasos. Para cada uno, escribe el nombre de quien es dueño y la regla que dice que está terminado. Si no puedes llenar una fila, no tienes un problema de enrutamiento. Tienes un problema de diseño, y ningún modelo, barato o de frontera, lo va a resolver.