¿Por qué la orquestación multiagente no funciona bien?

Recientemente, el proyecto ‘Paperclip’, que promete permitir operar una “empresa de cero humanos” con IA, se volvió tema de conversación. Si organizas agentes como si fueran un organigrama empresarial, les asignas roles de CEO, líder de equipo y personal operativo, y defines la misión de la empresa y los proyectos detallados, empiezan a trabajar de forma autónoma. En apenas un mes superó las 40 mil estrellas en GitHub.

Antes de eso también estaba Gastown, que con un enfoque similar usaba la metáfora de una “ciudad” para los agentes, además de Claude Code Agent Teams de Anthropic y los agentes en la nube de Cursor; en toda la industria se ve claramente la tendencia de “hacer funcionar varios agentes como si fueran una organización”.

Yo tampoco pude resistir la curiosidad por esta tendencia y probé Gastown y Paperclip. Calculado en costo de tokens de API, gasté alrededor de $5,000. 🫠
Si voy directo a la conclusión: sí hubo algunas áreas donde claramente funcionó, pero las limitaciones fueron mucho más evidentes.

El costo en tokens fue de 5 a 10 veces mayor que con un solo agente, pero la productividad no aumentó en proporción, y se repitieron problemas como que los agentes perdieran el contexto, que el traspaso de trabajo se cortara a mitad del proceso, o que marcaran por sí solos resultados incorrectos como “completados”. Por eso ordené los problemas que experimenté y las ideas que obtuve a partir de ellos:

→ Los 3 cuellos de botella estructurales de la orquestación multiagente
→ Por qué la metáfora de la “ciudad” o la “empresa” no termina de funcionar
→ Qué tipo de estructura es robusta en la práctica
→ 5 criterios y una puntuación para identificar en mi trabajo qué áreas pueden delegarse a agentes

Espero que esto sea útil para quienes, en la era de los agentes, están pensando en “qué delegar y qué no delegar”.