Un enjambre de agentes: qué es y cómo se diseña para producción

Un enjambre de agentes es un sistema descentralizado de agentes autónomos que, mediante reglas locales y coordinación ligera, reparte tareas complejas entre unidades especializadas en lugar de depender de un único modelo monolítico. Conviene usarlo cuando el trabajo se puede descomponer en subtareas paralelas con dependencias claras, como en pipelines de ingeniería o análisis de datos a gran escala. Un ejemplo típico: un agente planificador divide una migración de base de datos en decenas de commits que varios agentes trabajadores ejecutan en paralelo.

---

En resumen:

• Los enjambres de agentes funcionan mejor en tareas paralelizables con dependencias claras y su eficiencia disminuye si la coordinación supera los beneficios del trabajo distribuido.
• Patrones estructurales como planificador/trabajador, arquitecturas deliberativas y enfoques híbridos dependen de la complejidad de decisión y del coste de coordinación para decidir la mejor topología.
• La comunicación mediante protocolos pub/sub y gestión rigurosa de memoria compartida, permisos y trazabilidad mejoran la escalabilidad y seguridad en operaciones de enjambre en producción.
• Validar en piloto si las subtareas son verdaderamente independientes, mantener bajo coste de coordinación y usar pruebas automatizadas son claves antes de escalar un enjambre completo.
• agent-swarm.dev facilita la implementación con un ecosistema que integra agentes en contenedores, memoria persistente y reglas de gobernanza, permitiendo un despliegue seguro y controlado.

---

Tabla de contenidos

• Definición y fundamentos de un enjambre de agentes
• Algoritmos clásicos y patrones inspirados en la naturaleza
• Patrones de arquitectura y orquestación para desplegar un enjambre
• Comunicación, gestión de estado y escalado técnico
• Aplicaciones reales y lo que enseñan los experimentos medidos
• Implementación práctica: stack, gobernanza y métricas de validación
• Diseño en producción: seguridad, gobernanza y trazabilidad
• Ventajas y límites reales de un enjambre de agentes
• Perspectiva del autor: cuándo apostar de verdad por un enjambre
• Cómo despliega agent-swarm.dev un enjambre de agentes en producción
• Fuentes
• Preguntas frecuentes

Definición y fundamentos de un enjambre de agentes

Un enjambre de agentes no es lo mismo que un sistema multiagente genérico, aunque comparte su base teórica. La simulación multiagente describe entornos donde múltiples agentes autónomos interactúan y se adaptan, y ese marco cubre desde simulaciones económicas hasta videojuegos. Un enjambre es un caso particular: agentes numerosos, con roles a menudo simples o especializados, que producen comportamiento útil sin que exista un controlador central dando órdenes paso a paso.

La diferencia operativa importa para el diseño. En un sistema multiagente (MAS) general puede haber pocos agentes con lógica muy rica y negociación explícita entre ellos. En un enjambre, la potencia viene del número y de la repetición de patrones simples: cada agente ve solo su porción del problema, actúa con la información local disponible y confía en que el comportamiento colectivo emerja de la suma de esas acciones individuales.

Tres rasgos definen a un agente dentro de un enjambre:

• Autonomía: decide sus propias acciones sin esperar validación constante de un supervisor.
• Visión local: opera con el contexto que tiene a mano (una tarea, un archivo, un ticket), no con el estado completo del sistema.
• Proactividad: no solo reacciona a instrucciones, también identifica cuándo una subtarea está completa o bloqueada y actúa en consecuencia.

Esa combinación permite un mecanismo de coordinación que casi nunca se explica bien en la documentación de producto: la estigmergia. En lugar de que los agentes se hablen entre sí constantemente, modifican el entorno compartido (un archivo, una base de datos, un tablero de tareas) y ese entorno transmite la información. Las colonias de hormigas hacen esto con feromonas; un enjambre de agentes de software lo hace con commits, registros de estado o entradas en una memoria compartida. La interacción agente-entorno descrita en modelos basados en agentes/19%3A_Modelos_basados_en_agentes/19.03%3A_Interacci%C3%B3n_Agente-Medio_Ambiente) confirma que este tipo de coordinación indirecta reduce drásticamente la necesidad de mensajería explícita, algo crítico cuando se escala a cientos de trabajadores.

¿Cuándo aporta ventaja real el enfoque distribuido frente a un solo agente potente? Cuando el problema es paralelizable en unidades de trabajo relativamente independientes y cuando el coste de mantener un contexto único gigante supera al coste de coordinar varios contextos pequeños. Si la tarea exige razonamiento secuencial estrecho sobre un único hilo de lógica, un enjambre añade complejidad sin beneficio. La pregunta que de verdad hay que hacerse antes de adoptar esta arquitectura no es «¿puedo dividir esto?», sino «¿la coordinación entre partes cuesta menos que hacerlo todo en un contexto compartido?».

Algoritmos clásicos y patrones inspirados en la naturaleza

Antes de que existieran los agentes basados en modelos de lenguaje, la inteligencia de enjambre ya llevaba décadas resolviendo problemas de optimización. Vale la pena conocer estos algoritmos porque las intuiciones que codifican siguen siendo relevantes al diseñar comportamiento emergente en sistemas de IA actuales.

La inteligencia de enjambre agrupa varias familias de algoritmos con un rasgo común: agentes simples, reglas locales, resultado colectivo complejo.

• Optimización por enjambre de partículas (PSO): cada partícula ajusta su posición en el espacio de soluciones según su mejor resultado histórico y el mejor resultado del grupo. Se usa en ajuste de hiperparámetros y problemas de optimización continua.
• Optimización por colonia de hormigas (ACO): los agentes depositan «feromonas virtuales» sobre rutas prometedoras, reforzando los caminos que otros agentes ya validaron. Funciona bien en problemas de rutas y planificación de redes.
• Algoritmo de luciérnaga (firefly): los agentes se atraen entre sí en proporción a su «brillo» (calidad de solución), útil en optimización multimodal donde hay varios óptimos candidatos.
• Evolución diferencial: combina y muta soluciones candidatas de forma vectorial, sin depender de gradientes, práctica cuando la función objetivo no es diferenciable.

Es importante no confundir estos algoritmos de optimización con las arquitecturas agentivas que hoy usan modelos de lenguaje para tareas de ingeniería o análisis. PSO y ACO buscan un óptimo numérico dentro de un espacio de búsqueda bien definido. Un enjambre de agentes de IA moderno, en cambio, coordina unidades que razonan, escriben código o analizan datos, con objetivos que no siempre se pueden reducir a una función matemática a minimizar. Los principios de coordinación se toman prestados, pero el dominio de aplicación es distinto.

Eso no significa que los riesgos algorítmicos desaparezcan. Tres problemas clásicos de la optimización por enjambre siguen apareciendo, con otra cara, en enjambres de agentes de IA:

1. Convergencia prematura: si todos los agentes comparten demasiada información demasiado pronto, el grupo entero converge hacia la primera solución razonable en lugar de explorar alternativas mejores. En un enjambre de codificación, esto se traduce en agentes que replican el mismo enfoque erróneo porque copiaron contexto de un compañero equivocado.
2. Óptimos locales: sin suficiente diversidad de exploración, el sistema se queda atascado en una solución subóptima que parece buena localmente. Un agente de revisión de código puede aprobar un patrón repetido sin cuestionar si existe una solución mejor.
3. Coste computacional: coordinar más agentes no es gratis. Cada mensaje, cada sincronización de estado y cada verificación cruzada consume tiempo de cómputo y, con modelos de lenguaje, tokens reales que se facturan.

Consejo profesional: *Antes de escalar un enjambre a decenas de agentes, prueba primero con tres o cuatro y mide cuánto tiempo se va en coordinación frente a trabajo productivo.

Patrones de arquitectura y orquestación para desplegar un enjambre

Elegir la topología correcta pesa más en el resultado final que elegir el modelo de lenguaje subyacente. Tres patrones cubren la mayoría de los casos reales.

1. Planificador/trabajador (planner/worker). Un agente principal, normalmente el modelo más capaz y caro disponible, descompone el objetivo en tareas discretas y las asigna a agentes trabajadores especializados. Los trabajadores pueden ejecutarse con modelos más rápidos y económicos porque su tarea es acotada. Los experimentos documentados por Cursor sobre la economía de los modelos en enjambres de agentes muestran que esta separación de roles mejora la eficiencia de contexto: el planificador mantiene la visión global mientras cada trabajador opera con un contexto reducido y específico, lo que baja el coste total sin sacrificar calidad en tareas bien delimitadas.

2. Arquitectura deliberativa. Aquí varios agentes con capacidades similares proponen soluciones en paralelo y un mecanismo de arbitraje (votación, puntuación, un agente juez) elige o combina la mejor. Este patrón encaja en tareas donde no hay una única forma correcta de proceder, como generar y evaluar variantes de una arquitectura de software antes de comprometerse a una.

3. Patrones híbridos. Combinan planificación central con negociación deliberativa en subgrupos. Un planificador de alto nivel reparte fases del proyecto, y dentro de cada fase los agentes trabajadores deliberan entre sí para resolver ambigüedades sin escalar cada decisión al planificador. Conviene este enfoque cuando el proyecto mezcla fases muy estructuradas (migraciones, despliegues) con fases que requieren juicio (diseño de API, resolución de errores ambiguos).

Independientemente del patrón elegido, casi todas las implementaciones serias comparten tres componentes de infraestructura. Un bus de mensajes que desacopla a los agentes entre sí y permite que la comunicación sea asíncrona en lugar de bloqueante. Una memoria compartida que persiste decisiones, resultados intermedios y contexto acumulado, evitando que cada agente tenga que redescubrir información que otro ya generó. Y un agente reconciliador, encargado específicamente de detectar y resolver conflictos cuando dos o más trabajadores modifican el mismo artefacto de forma incompatible.

La arquitectura de referencia de Google Cloud para sistemas de IA multiagente recomienda justamente esta separación: un agente coordinador que orquesta, subagentes especializados que ejecutan, y una capa de comunicación estandarizada entre ambos usando mecanismos como Pub/Sub y el protocolo A2A. La guía insiste en que la observabilidad debe diseñarse desde el principio, no añadirse después, porque depurar un fallo distribuido entre quince agentes sin trazas claras es prácticamente imposible.

Elegir entre estos patrones depende del coste de contexto de la tarea. Si dividir el trabajo en piezas pequeñas mantiene la calidad, planificador/trabajador suele ganar en coste. Si la tarea exige criterio y hay margen de ambigüedad legítima, un esquema deliberativo, aunque más caro, evita errores que salen más caros de corregir después.

Comunicación, gestión de estado y escalado técnico

La elección de protocolo de comunicación determina cuánto puede crecer un enjambre antes de volverse inmanejable. Los protocolos publicador/suscriptor (pub/sub) desacoplan emisores y receptores: un agente publica un evento y cualquier otro interesado lo consume, sin necesidad de conocerse mutuamente. Los protocolos agente a agente (A2A) estandarizan cómo un agente describe sus capacidades y negocia tareas con otro, algo especialmente útil cuando el enjambre mezcla agentes construidos con frameworks distintos. Los esquemas más antiguos como FIPA ACL formalizan actos de habla entre agentes (proponer, aceptar, rechazar), un enfoque más rígido pero predecible en sistemas cerrados.

Cada protocolo implica un trade-off entre flexibilidad y previsibilidad. Pub/sub escala mejor porque no requiere conocimiento mutuo entre agentes, pero complica la depuración porque el flujo de eventos no siempre es lineal. A2A facilita la interoperabilidad entre agentes heterogéneos y, según recoge la guía de arquitectura multiagente de Google Cloud, mejora directamente la observabilidad del sistema al estandarizar cómo se describen las capacidades de cada agente.

La gestión de memoria es, en la práctica, donde más enjambres fallan. Un agente sin acceso al historial de decisiones de sus compañeros repite trabajo o contradice lo que otro ya resolvió. Las técnicas que funcionan combinan:

• Una guía de campo o documento vivo que resume decisiones arquitectónicas y convenciones del proyecto, accesible para todos los agentes.
• Técnicas de grounding que anclan las respuestas de cada agente a fuentes verificables (código real, tickets, documentación) en lugar de a suposiciones.
• Control de versiones explícito sobre los artefactos que el enjambre modifica, con reglas claras de quién puede escribir qué.

El control de versiones merece atención aparte porque es donde aparecen los conflictos más costosos. Cuando varios agentes trabajan sobre el mismo repositorio o base de datos de forma simultánea, los conflictos de fusión dejan de ser una anomalía ocasional y se convierten en un evento esperado que hay que gestionar con reglas explícitas. Los experimentos de Cursor con enjambres a gran escala documentan precisamente esto: necesitaron mecanismos dedicados de reconciliación porque el control de versiones tradicional, pensado para colaboración humana con ritmo lento, no soporta bien la velocidad y el volumen de cambios que genera un enjambre activo.

Un dato que cambia cómo se mide el progreso: en los ensayos de Cursor, la métrica que mejor predijo si un enjambre estaba avanzando de verdad no fue la actividad de los agentes, sino la tasa de commits que superaban pruebas automatizadas como sqllogictest. Contar mensajes o tareas «completadas» sin esa validación infla la sensación de progreso.

Para la tolerancia a fallos, un enjambre bien diseñado asume que algunos agentes fallarán o producirán resultados de baja calidad, y construye reintentos, límites de tiempo y agentes de verificación como parte normal del flujo, no como manejo de excepciones añadido después.

Aplicaciones reales y lo que enseñan los experimentos medidos

Los enjambres de agentes ya se aplican con resultados medibles en al menos tres dominios técnicos.

• Ingeniería de software: dividir una tarea de desarrollo en subtareas paralelas (implementar, testear, documentar) asignadas a distintos agentes trabajadores. Los ensayos de Cursor sobre la economía de modelos en enjambres muestran mejoras de eficiencia al asignar el rol de planificador a modelos más potentes y reservar los modelos económicos para los trabajadores, manteniendo el contexto de cada uno acotado a su subtarea.
• Visión por computador: en dispositivos de borde (edge devices) con recursos limitados, repartir el procesamiento de imagen entre agentes especializados mejora la adaptabilidad frente a condiciones cambiantes. Según recoge Ultralytics sobre inteligencia de enjambre en IA de visión, este enfoque distribuido gana eficiencia justo en los escenarios donde un único modelo central no puede procesar todo el flujo de datos en tiempo real.
• Pipelines de análisis de datos: agentes especializados en extracción, limpieza, transformación y validación trabajando en paralelo sobre distintos segmentos de un conjunto de datos, con un agente coordinador que consolida resultados al final.

Lo que estos casos comparten no es la tecnología, sino la lección de diseño: separar roles por coste y complejidad casi siempre gana a usar un único modelo potente para todo. El planificador razona sobre la estructura completa del problema; los trabajadores ejecutan piezas acotadas donde un modelo más rápido y barato basta.

Antes de comprometer presupuesto de ingeniería a un enjambre en producción, conviene validar tres cosas en un piloto pequeño:

• Divisibilidad real: comprobar que la tarea se descompone en subtareas verdaderamente independientes, no solo aparentemente paralelas.
• Coste de coordinación: medir cuántos tokens o cuánto tiempo se consume en comunicación entre agentes frente a trabajo productivo.
• Tasa de acierto verificable: usar pruebas automatizadas (suites de tests, validaciones de esquema) como criterio objetivo de éxito, no la impresión subjetiva de que el enjambre «parece» estar funcionando.

Si esas tres condiciones se cumplen en un piloto de una semana con dos o tres agentes, escalar suele merecer la pena. Si la coordinación domina el tiempo o los resultados no superan pruebas automatizadas de forma consistente, el problema está en el diseño de roles, no en el número de agentes.

Implementación práctica: stack, gobernanza y métricas de validación

Montar un enjambre de agentes desde cero exige decisiones de infraestructura antes de escribir la primera línea de lógica de coordinación. En el terreno de la simulación y modelado de agentes, frameworks como JADE (orientado a Java, con soporte para protocolos FIPA) o Mesa (en Python, popular para modelado basado en agentes) siguen siendo referencias académicas sólidas. Para orquestación de agentes con modelos de lenguaje en producción, el ecosistema actual incluye Ray para computación distribuida, AutoGen para conversación entre agentes y el kit de desarrollo de agentes de Google (ADK) como capa de integración con protocolos estandarizados. A eso se suma herramientas de mensajería tipo pub/sub para desacoplar componentes.

La gobernanza no es un añadido opcional. La guía de sistemas multiagente de Google Cloud recomienda un checklist mínimo antes de llevar un enjambre a producción:

• Definir permisos de acceso específicos por agente (IAM granular), nunca credenciales compartidas entre todos los trabajadores.
• Establecer puntos de supervisión humana en decisiones de alto impacto, no solo revisión posterior.
• Monitorizar continuamente el comportamiento de cada agente, con alertas ante desviaciones del patrón esperado.
• Evaluar de forma recurrente el desempeño del enjambre completo, no solo de agentes individuales.

Para medir si un enjambre funciona de verdad, dos métricas operativas destacan sobre las demás: la tasa de commits válidos por agente y el porcentaje de tareas que superan suites de pruebas automatizadas. Ambas aparecen documentadas en los ensayos de ingeniería de Cursor como indicadores más fiables que el volumen de actividad bruto. A eso conviene sumar la latencia de coordinación, es decir, cuánto tiempo pasa entre que una subtarea queda lista y el siguiente agente la recoge.

Consejo profesional: *No midas el éxito de un enjambre por cuántos agentes tienes activos. Mide cuántos de esos agentes producen commits o resultados que superan una prueba automatizada sin intervención humana posterior.

agent-swarm.dev implementa buena parte de este stack de forma directa: un agente principal que descompone objetivos, trabajadores especializados ejecutándose en contenedores aislados, memoria compartida persistente y control de permisos por rol. Los ejemplos de sesiones reales muestran cómo se ve esta coordinación aplicada a tareas de ingeniería concretas, y la guía de orquestación multiagente para arquitectos de producción detalla decisiones de diseño equivalentes a las descritas aquí.

Diseño en producción: seguridad, gobernanza y trazabilidad

Llevar un enjambre de laboratorio a producción cambia las prioridades. Ya no basta con que el sistema funcione: hay que poder auditar por qué tomó cada decisión, quién (o qué agente) la tomó, y revertirla si es necesaria.

La trazabilidad empieza por registrar cada acción de cada agente con su contexto asociado: qué información tenía disponible, qué modelo usó y qué salida produjo. Sin ese registro, diagnosticar un fallo distribuido entre una docena de agentes se convierte en arqueología de logs sin garantía de encontrar la causa.

La seguridad exige tratar a cada agente como una identidad con permisos propios, no como una extensión genérica del usuario que lo lanzó. Un agente con acceso de escritura a un repositorio no debería tener automáticamente acceso a credenciales de producción, y viceversa. La arquitectura de referencia de Google Cloud es explícita en este punto: la gestión de identidad y acceso debe diseñarse por agente, con revisión periódica de qué permisos siguen siendo necesarios.

La supervisión humana, finalmente, no debe desaparecer solo porque el sistema es autónomo. Los puntos de aprobación antes de acciones irreversibles (despliegues, borrado de datos, cambios en producción) siguen siendo la salvaguarda más simple y más efectiva contra errores emergentes que ningún test cubrió.

Ventajas y límites reales de un enjambre de agentes

La escalabilidad es la ventaja que más se vende y la que menos se entiende. Un enjambre bien diseñado permite añadir capacidad de procesamiento sumando agentes trabajadores, algo mucho más barato que ampliar el contexto de un único modelo hasta el límite. Pero esa escalabilidad no es lineal: cada agente adicional añade también carga de coordinación, y a partir de cierto punto el coste de sincronizar supera el beneficio de paralelizar.

La sobrecarga de comunicación es la limitación más citada en la práctica. Cuantos más agentes necesitan compartir estado, más tráfico de mensajes, más tokens consumidos en contexto compartido y más superficie para inconsistencias. Los patrones de estigmergia y memoria compartida existen precisamente para mitigar esto, pero no lo eliminan.

El comportamiento emergente es, a la vez, la mayor fortaleza y el mayor riesgo del enfoque. Permite que el sistema resuelva problemas que nadie programó explícitamente, combinando acciones simples de forma inesperadamente eficaz. También significa que un enjambre puede producir resultados colectivos que ningún agente individual «decidió» y que resultan difíciles de prever en pruebas antes del despliegue. Diseñar límites claros, puntos de verificación y agentes de auditoría no es opcional cuando se acepta este tipo de emergencia.

Perspectiva del autor: cuándo apostar de verdad por un enjambre

La señal más fiable de que un equipo está listo para un enjambre no es el tamaño del presupuesto de IA, es la madurez de sus pruebas automatizadas. Si no tienes una suite fiable que te diga objetivamente si un cambio funciona, un enjambre de agentes solo multiplica el ruido: producirás más código, más análisis, más commits, pero sin forma barata de saber cuáles son buenos.

El riesgo organizativo que menos se discute es cultural, no técnico: equipos que tratan al enjambre como una caja negra infalible dejan de revisar el trabajo con el mismo rigor que aplicarían a un compañero humano. Eso es exactamente al revés de lo que exige un sistema con comportamiento emergente. Mitigarlo pasa por mantener puntos de supervisión humana explícitos, no por confiar en que «funcionó la última vez».

Mi recomendación práctica es empezar con un piloto de dos o tres agentes sobre una tarea real y acotada, medir la tasa de aciertos contra pruebas automatizadas durante al menos una semana, y solo entonces decidir si escalar el número de agentes o el alcance de las tareas. La tentación de saltar directamente a un enjambre de veinte agentes suele salir cara.

— Ez.-

Cómo despliega agent-swarm.dev un enjambre de agentes en producción

agent-swarm.dev es el sistema operativo que convierte todo lo descrito arriba en infraestructura lista para usar, sin que el equipo tenga que ensamblar bus de mensajes, memoria compartida y control de permisos desde cero.

Un agente principal descompone el objetivo, asigna subtareas a trabajadores especializados (Claude Code, Codex, pi-mono, Open Code, Devin AI, entre otros) que se ejecutan en contenedores Docker aislados, y mantiene memoria compartida que se acumula entre ejecuciones en lugar de reiniciarse cada vez. Las integraciones cubren cientos de plataformas, incluidas Slack, Linear, GitHub, Turso y OpenAI, así que el enjambre se conecta directamente al flujo de trabajo que el equipo ya usa en lugar de exigir uno nuevo. Si tu equipo ya identificó qué tareas son divisibles y qué pruebas automatizadas validarán el resultado, el paso lógico es revisar las Agent-swarm y arrancar un piloto directamente desde Agent-swarm.

Fuentes

Para profundizar en los fundamentos y en la evidencia empírica citada, tres referencias destacan sobre el resto. La arquitectura de referencia de Google Cloud para sistemas de IA multiagente cubre patrones de coordinación, protocolos A2A y prácticas de seguridad con detalle técnico suficiente para un equipo que empieza desde cero. Los experimentos de Cursor sobre la economía de modelos en enjambres de agentes aportan datos reales de rendimiento y las lecciones aprendidas sobre control de versiones y roles planificador/trabajador. La entrada de Wikipedia sobre inteligencia de enjambre sigue siendo el mejor punto de partida para entender los algoritmos clásicos que inspiran estos sistemas. La guía de sistemas multiagente de Google Cloud y el análisis de Ultralytics sobre inteligencia de enjambre en visión artificial completan el panorama con aplicaciones prácticas fuera del desarrollo de software.

• Sistema de IA multiagente en Google Cloud | Cloud Architecture Center
• Enjambres de agentes y la nueva economía de los modelos · Cursor

Preguntas frecuentes

¿Qué es la teoría de enjambre?

La teoría de enjambre estudia cómo agentes simples, siguiendo reglas locales sin control central, generan comportamiento colectivo complejo, como el que se observa en colonias de hormigas o bandadas de aves y que hoy se aplica a sistemas de agentes de IA.

¿Cuáles son los tipos de inteligencia artificial según su capacidad?

La clasificación más citada distingue IA de tarea limitada (la que existe hoy), IA general teórica, superinteligencia artificial teórica y una cuarta categoría de sistemas con autoconciencia, que sigue siendo puramente especulativa.

¿A qué se refiere el término inteligencia de enjambre?

Se refiere al comportamiento colectivo inteligente que emerge cuando muchos agentes autónomos interactúan mediante reglas locales, sin coordinación central directa, como describen algoritmos clásicos como PSO y ACO.

¿Qué diferencia a un enjambre de agentes de un sistema multiagente clásico?

Un sistema multiagente puede tener pocos agentes con lógica compleja y negociación explícita; un enjambre depende de agentes numerosos y relativamente simples cuya coordinación surge de reglas locales y del entorno compartido, como implementa agent-swarm.dev con su arquitectura planificador/trabajador.

Recomendación

• QM vs agent-swarm.dev — Agent Fleet vs Coordinated Swarm
• Agent Swarm Blog: Technical Deep Dives & Architecture Notes
• Your AI Workflow Has Too Many Agents | agent-swarm.dev
• Hermes vs agent-swarm.dev — One Agent vs a Standing Team