LLM13 – A mi la orquestación no me funciona

El pasado viernes estuve hablando con algunos compañeros sobre la escala de adopción de IA de Steve Yegge, y sobre donde estaba yo. Hoy vamos a hablar de orquestación, de multi-agentes y de por qué a fecha de hoy, al menos para mí, la orquestación no funciona.

Qué es (en teoría) la orquestación

Volviendo a la escala Yegge, si partimos del mundo en el que no hay IA, pasamos al autocompletado, de ahí a agentes en el IDE, de ahí a agentes que trabajan solos de principio a fin, a múltiples agentes… la orquestación ocurre como paso natural ante nuestra incapacidad de gestionar multiples agentes a la vez, y es delegar procesos completos en un agente para que a su vez este agente delegue en otros.

En los últimos meses, empresas como Anthropic o Cursor han mostrado dos ejemplos bastante espectaculares del uso de orquestadores. Anthropic construyó un compilador y Cursor construyó un navegador web. Sin centrarnos en cuan completos estaban ambos productos, la narrativa mostraba el ejemplo de lo que se podía hacer con cientos de agentes.

Los que llevamos mucho tiempo en esto no podemos dejar de ver los parecidos con las demos técnicas que hacían empresas como Microsoft para mostrar sus productos, y nombres como Contoso, Northwind y Adventure Works le sonarán a más de uno.

Esto es una demo técnica de lo que se puede conseguir, y desafortunadamente, como muchas otras, a veces es una solución en busca de un problema.

Quis custodiet ipsum codicem?

Mi problema con estos «productos» es que, además de generar titulares, producen cientos de miles de líneas de código, que son el resultado de decisiones tomadas por varios agentes, en el contexto de una tarea más o menos ambigua.

Una de mis mayores aspiraciones es que el software que hago se use, y que con el uso venga el aprendizaje sobre exactamente qué necesitan los usuarios. Ese aprendizaje y nuestra capacidad de adaptarnos implica que el código que creamos sea mantenible y previsible.

Para ello queremos que nuestros programas sean lo más pequeños posibles, lo más fáciles de modificar, y que las decisiones que hemos tomado a lo largo del tiempo queden lo más claras posibles.

Muchas veces los programas nos sobreviven (en algun lugar sigue funcionando código que escribí en 2015), pasan por múltiples equipos y se pierde cierto contexto, y es un proceso suficientemente frustrante que incluso hice un libro sobre él.

Los productos que salen como resultado de orquestación de agentes son equivalentes a recibir una pieza de software creada por otro equipo, y si algo no queremos hacer es estar lidiando cada día con un proceso de handover diferente.

A fecha de hoy, y con las herramientas que tenemos, mi flujo de trabajo se puede explicar con un concepto bastante viejo: 7±2.

7±2

Mi día a día es bastante dinámico, y paso de proyectos que duran semanas a resolver o colaborar en incidencias que duran minutos, y eso implica tener en tu memoria de trabajo varios «frentes abiertos». Hemos hablado de este concepto en el pasado con Offboarding, es la base de sistemas como GTD, pero se puede resumir en el famoso 7±2, que es el límite cognitivo de la mente humana definido por Miller en 1956.

Paradójicamente, este límite lo podemos aplicar de una manera bastante directa al trabajo con agentes, y eso nos ayuda a fijar un límite máximo y tener expectativas realistas.

Veamos un caso práctico: Mi flujo de trabajo consiste en unos cuantos agentes, mi aplicación de documentos de Markdown, e innumerables pestañas en el navegador donde tengo las incidencias, las pull requests, etc.

Si partimos que el máximo absoluto son 9 agentes eso implicaría que solamente estoy trabajando con agentes en un día laborable, pero también está slack abierto (-1), está el email (-1), tenemos reuniones (-1), y así el número de agentes, y por tanto tareas con los que trabajo «en paralelo» quedan entre 4 y 6, y eso en un buen día.

Los límites de la delegación

Otra manera de pensar este límite está relacionada con nuestra capacidad para delegar actividades, y lo hemos visto en muchos ejemplos de la industria. Amazon es famoso por los 2-pizza teams, unidades individuales de máximo 10 personas. Spotify tiene los squads, que son grupos multidisciplinares que gestionan un vertical entre 6 a 12 personas.

Si pensamos en los agentes como roles a los cuales delegamos tareas, y hemos hecho el trabajo de crear agentes especializados (algo que, de momento, no me ha funcionado), este matiz también nos aplica, ya que queremos trabajar con un equipo suficientemente pequeño para mantener el control del contexto.

No importa que el número de agentes sea 4 o 10, lo importante es que sea finito, y si tenemos un número finito de agentes, para qué necesitamos un orquestador?

«Unless you know better ones»

Otra de las ideas que han «hecho callo» tras más de 10 años en Amazon es la idea de que los principios, tanto los de la empresa como los de los equipos, son moldeables a nueva información, y muchas veces cuando definimos procesos ponemos esa coletilla, dejando la puerta abierta a mejoras y manteniendo el enfoque pragmático.

Con ese enfoque llevo casi un año trabajando con LLMs, he pasado de tener un chat que me contestaba en pocos segundos a pasar la mayor parte de mi tiempo definiendo un problema y delegar la ejecución. Sonnet y Opus 4.6 son un orden de magnitud mejores que Sonnet 3.7, y cada nueva versión de los modelos me permite hacer más, y mi manera de trabajar se irá adaptando a los cambios.

Es posible que acabe usando orquestación en el futuro, pero de momento me voy a quedar con mi contexto limitado, mis días productivos con 4 agentes y con la tranquilidad de que personas que saben lo que hacen como Boris Cherny (creador de Claude Code) y Diego Muñoz (Staff Engineer en Spotify y buen amigo) usan pocos agentes.LLM13 – A mi la orquestación no me funciona