¿Qué sucede cuando planeas un gran proyecto sin nadie al mando? La mayoría de los stacks de software asumen un único orquestador. Un proceso mantiene el estado, encola los trabajos y distribuye las tareas. Si ese coordinador se reinicia, todo el flujo de trabajo tropieza. Un nuevo proyecto cambia esa suposición por completo. Muestra cómo un enjambre de agentes de IA puede descomponer un objetivo como "planear un viaje de dos semanas a Japón" en un árbol de tareas completo sin que ningún nodo individual posea el plan completo en ningún momento.
¿Por qué construir un sistema sin líderes?
Es fácil razonar sobre los planificadores centralizados. Envías una solicitud a un servidor, este divide el trabajo y los trabajadores informan de vuelta. El problema es que el servidor se convierte en un cuello de botella cognitivo y físico. Él es el dueño de la verdad.
En una configuración distribuida, la verdad se convierte en una imagen compartida en la que la red converge a través de gossip. Esta implementación específica de Python conecta dos conceptos distintos. El primero es un bucle de refinamiento iterativo: un agente escribe una propuesta, otro la califica y un tercero la pule. El segundo es una capa de red peer-to-peer construida sobre libp2p, que permite que los agentes se descubran entre sí automáticamente sin necesidad de un registro o un equilibrador de carga. El resultado es un clúster donde los pares aparecen, proponen, votan y ejecutan sin que nadie actúe como director de orquesta.
Los cuatro roles
El sistema asigna a cada participante una de cuatro personalidades. No necesitas cuatro máquinas físicas. Pueden coexistir en una sola laptop o distribuirse en una red doméstica. Los roles son:
Decomposer. Este agente recibe el objetivo de alto nivel y propone una división en subobjetivos. Debido a que el sistema ejecuta múltiples decomposers en paralelo, podrías obtener tres recetas diferentes para el mismo viaje a Japón. Uno podría desglosar el viaje por geografía: Tokio, Kioto, Osaka. Otro podría dividirlo por actividad: transporte, alojamiento, comida, turismo. Un tercero podría secuenciarlo por días. La red considera todos ellos.
Scorer. Estos agentes actúan como el consejo editorial. Inspeccionan una división propuesta y la califican. Una puntuación refleja si los subobjetivos son lo suficientemente concretos, no se solapan y son colectivamente exhaustivos. Más importante aún, un scorer decide si una propuesta es lo suficientemente buena para ser aceptada. Sin su bendición, una división permanece en el limbo.
Executor. Una vez que el árbol alcanza nodos hoja lo suficientemente pequeños como para actuar sobre ellos, los executors compiten por reclamarlos. No esperan permiso de una cola central. En su lugar, utilizan un protocolo de marca de tiempo (timestamp) para decidir quién se queda con la tarea. El ganador ejecuta el trabajo mediante una llamada local a un LLM y transmite el resultado.
Observer. Este es el espectador discreto que toda red necesita. Escucha silenciosamente el gossip, reconstruye el árbol del plan a partir de la charla y muestra una instantánea legible. Como nunca habla, demuestra un punto importante: cualquiera que se una tarde puede descifrar el plan completo simplemente escuchando.
El gossip como fuente de verdad
La capa libp2p gestiona el descubrimiento y la mensajería. Los agentes se encuentran entre sí a través del descubrimiento de pares integrado en el protocolo y luego transmiten mensajes a un tema compartido. No hay una base de datos de registro, ni una caché de Redis que contenga el plan canónico.
Cada par mantiene su propia copia del árbol del plan y lo actualiza basándose en el gossip que escucha. Cuando un decomposer transmite una propuesta, todos los demás nodos la reciben, validan el formato y añaden la rama a su árbol local. Cuando los scorers emiten votos, el recuento se propaga de la misma manera. Si dos executors publican reclamaciones conflictivas para la misma tarea, el protocolo de marca de tiempo resuelve la colisión. La red se decide por la reclamación más temprana y descarta la tardía.
Con el tiempo, el árbol crece hacia abajo desde el objetivo original a través de capas de subobjetivos aceptados hasta llegar a tareas pequeñas y manejables. El proceso se asemeja al consenso de una blockchain, con la diferencia de que la carga útil es un itinerario de viaje o una especificación de software en lugar de un libro de contabilidad de monedas.
Votación y la carrera por la ejecución
La democracia es costosa, y este sistema paga el precio en latencia. Una división solo gana si suficientes scorers están de acuerdo. Ese umbral podría ser una mayoría simple o un quórum más estricto, dependiendo de cómo se configure el clúster. Los decomposers no dejan de proponer, por lo que la red a menudo evalúa varios árboles competidores a la vez. Finalmente, uno alcanza los votos necesarios y sus subobjetivos pasan de borrador a aceptados.
Executors add another layer of coordination. Because tasks are public on the gossip channel, multiple executors might try to grab the same attractive leaf node. The timestamp protocol acts as a tiebreaker. Each claim carries a monotonic timestamp, and the network honors the earliest one. The loser simply moves on to the next available task. This is crude, but it avoids the need for a centralized scheduler locking rows in a database.
Resilience by Design
The architecture earns its keep when things break. If a decomposer crashes after proposing half the subgoals, the surviving decomposers continue offering splits. The plan does not stall waiting for a respawn. If a scorer drops off the network, the remaining voters can still reach quorum as long as you sized the cluster appropriately.
The real payoff is late joins. A new agent that boots up halfway through does not need a snapshot or a