Agentes de IA sin correa: por qué toca olvidarse del enrutamiento rígido

Imagine que construye un laberinto complejo de condiciones lógicas, donde cada giro depende de la respuesta de un modelo de lenguaje. Pasa semanas escribiendo ramas del tipo «si el usuario preguntó por precios, ve al agente A; si preguntó por la API, al agente B». Eso es el enrutamiento rígido, o la orquestación, sobre el que hoy se sostienen la mayoría de los sistemas multiagente y de las soluciones avanzadas de RAG. El enfoque parece lógico y seguro, pero en la práctica se convierte en una pesadilla para el desarrollador y en un cuello de botella para la propia red neuronal. Intentamos imponer a una inteligencia flexible la estructura rígida de la programación clásica, y ahí empiezan los problemas.

El contexto es sencillo: cuando los LLM irrumpieron en nuestro stack, no sabíamos cómo controlarlos. La orquestación se convirtió en el fusible que evitaba que el modelo alucinara o se perdiera en un enorme volumen de datos. Creamos despachadores que clasificaban las consultas y las pasaban a trabajadores muy especializados. Pero cuanto más complejas se volvían las tareas, más a menudo se equivocaban esos despachadores. Un error en la fase de enrutamiento es fatal en un sistema así: si la consulta va a la rama equivocada, toda la cadena posterior de agentes produce basura inútil. Hemos levantado frágiles castillos de naipes hechos de prompts que se derrumban ante cualquier pregunta fuera de lo común.

La industria ha comprendido ahora que hay que cambiar de paradigma. Pasamos de los guiones rígidos a la planificación dinámica. En lugar de fijar la ruta de antemano, damos al agente un conjunto de herramientas y un objetivo general. Los modelos actuales, de nivel GPT-4o o Claude 3.5, son lo bastante listos para decidir por sí mismos qué herramienta invocar a continuación a partir de los resultados intermedios. Esto elimina el «planificador central», que antes era el único punto de fallo. Los agentes empiezan a trabajar como un equipo de profesionales bien coordinado, no como un grupo de becarios que esperan instrucciones desde arriba.

¿Por qué importa justo ahora? Porque las tareas de negocio se han vuelto demasiado no lineales. Los clientes no hacen preguntas siguiendo una plantilla. En un sistema sin enrutamiento rígido, un agente puede empezar a buscar en una base de datos, comprobar que la información no basta, decidir por sí mismo pedir una aclaración al usuario o recurrir a otra herramienta, sin volver al principio de la cadena. Esto ahorra tokens, reduce la latencia y, sobre todo, hace que el sistema resista mejor los imprevistos. Por fin empezamos a usar los LLM como motores de razonamiento y no como procesadores de texto con función de clasificación.

Por supuesto, renunciar a la orquestación asusta a quienes están acostumbrados a controlar por completo la lógica de la aplicación. Surge la cuestión de la seguridad y la previsibilidad. Pero la práctica muestra que unos prompts de sistema bien ajustados y una arquitectura de herramientas adecuada funcionan con más fiabilidad que miles de líneas de código con condiciones. Vemos cómo grandes actores y bibliotecas de código abierto como LangGraph empiezan a admitir grafos cíclicos y más libres en lugar de cadenas lineales. Es señal de que la era de los «scripts de IA» se acerca a su fin y deja paso a una autonomía real.

En última instancia, el paso a sistemas sin enrutamiento rígido supone reconocer que ya no podemos, ni debemos, microgestionar la inteligencia artificial. Si confiamos en un modelo para generar código o analizar documentos jurídicos, ¿por qué tememos confiarle la elección del siguiente paso dentro de una tarea dada? El futuro es de los sistemas adaptativos que se ajustan al usuario sobre la marcha, en lugar de obligarlo a recorrer un pasillo trazado de antemano.

Lo esencial: pasamos de la era de los «algoritmos de IA» a la de la «intuición de IA», en la que las reglas rígidas solo estorban al resultado. ¿Está listo para soltar el control a cambio de eficiencia?