Le pides a tu asistente de IA que investigue el producto de un competidor, resuma los hallazgos, redacte un documento comparativo y lo envíe por correo a tu equipo. Un solo agente puede hacer cada uno de estos pasos — pero hacerlos bien, en secuencia, manteniendo el contexto a lo largo de las cuatro tareas, empuja contra los límites de lo que una sola sesión de agente maneja con soltura. La ventana de contexto se llena. El agente pierde el hilo de los pasos anteriores. La calidad del resultado final se degrada porque el modelo está haciendo malabares con demasiadas preocupaciones simultáneamente.
Este es el problema que los enjambres de agentes resuelven. En lugar de un agente haciendo todo, un agente coordinador divide la tarea en subtareas y delega cada una a un agente especialista. El agente de investigación busca en la web y devuelve hallazgos estructurados. El agente de redacción toma esos hallazgos y redacta el documento. El agente de correo envía el resultado. Cada agente opera en su propio contenedor, con su propia ventana de contexto, enfocado en una sola cosa.
La idea no es nueva — CrewAI y AutoGen llevan más de un año explorando patrones multi-agente. Lo diferente del enfoque de NanoClaw es que cada agente en el enjambre se ejecuta en su propio contenedor aislado, lo que significa que las garantías de seguridad y aislamiento que aplican a las conversaciones de un solo agente se extienden automáticamente a los flujos de trabajo multi-agente.
Cómo funcionan los enjambres en NanoClaw
La arquitectura de enjambres de NanoClaw está construida sobre una primitiva simple: un agente puede lanzar otros agentes. Cuando Claude Code se ejecuta dentro de un contenedor, una de sus herramientas disponibles es la delegación de agentes — la capacidad de describir una subtarea y hacer que NanoClaw lance un nuevo contenedor para manejarla. El agente padre recibe el resultado cuando el agente hijo completa.
La orquestación ocurre de forma natural a través del propio razonamiento de Claude. No defines un grafo de flujo de trabajo ni configuras roles de agentes en un archivo YAML. Describes lo que quieres, y Claude decide si manejarlo directamente o delegar partes a sub-agentes. La decisión se basa en el mismo razonamiento que hace que Claude sea bueno descomponiendo problemas complejos — reconoce cuándo una tarea tiene componentes independientes que se beneficiarían de atención enfocada.
En la práctica, esto se ve como un árbol de contenedores. El contenedor raíz recibe tu mensaje, decide que necesita investigación web y redacción de documentos, lanza dos contenedores hijos, espera sus resultados y sintetiza una respuesta final. Cada contenedor hijo tiene su propio contexto CLAUDE.md, su propio espacio de trabajo montado y su propio conjunto de herramientas. El agente de investigación tiene navegación web habilitada; el agente de redacción tiene acceso de escritura al espacio de trabajo compartido. Ninguno puede acceder al contexto o herramientas del otro.
Por qué el aislamiento por contenedores importa para los enjambres
La mayoría de los frameworks multi-agente ejecutan todos los agentes en el mismo proceso. Los agentes de CrewAI comparten un runtime de Python. Los agentes de AutoGen comparten un hilo de conversación. Esto funciona para demos, pero crea problemas a escala que son difíciles de arreglar después.
El primer problema es el radio de explosión. Si un agente en un enjambre encuentra una inyección de prompt — un sitio web malicioso que intenta secuestrar el comportamiento del agente — la inyección queda contenida en ese único contenedor. No puede afectar al agente padre, no puede acceder a los contextos de otros agentes hijos, y no puede leer el historial de conversación del usuario original. El contenedor comprometido se destruye cuando completa, y el agente padre recibe cualquier salida que haya producido (que el padre puede evaluar en calidad antes de usar).
El segundo problema es la contención de recursos. Los agentes en un proceso compartido compiten por la misma ventana de contexto, la misma memoria y la misma CPU. En NanoClaw, cada contenedor tiene sus propios recursos. Un agente de investigación que está navegando páginas web pesadas no ralentiza a un agente de redacción que está elaborando un documento. Los contenedores se ejecutan concurrentemente en hilos separados, y la gestión de recursos del host se encarga de la planificación.
El tercer problema es el alcance de credenciales. Un agente de investigación necesita acceso web pero no debería tener permisos de escritura en disco. Un agente de gestión de archivos necesita acceso a disco pero no debería tener acceso web. En un framework de proceso compartido, aplicar estos límites requiere comprobaciones de permisos a nivel de aplicación que pueden eludirse. En NanoClaw, los límites son montajes de contenedor — el agente de investigación literalmente no puede escribir en disco porque no hay ninguna ruta con permisos de escritura montada en su contenedor.
Patrones prácticos de enjambres
Los patrones que emergen del uso real son más interesantes que la arquitectura teórica. El más común es el patrón de investigar-y-sintetizar: un agente padre lanza 3-5 agentes de investigación para investigar diferentes aspectos de una pregunta en paralelo, recopila sus hallazgos y produce una respuesta sintetizada que es más exhaustiva de lo que cualquier agente individual podría producir en una sola pasada.
El segundo patrón común es redactar-y-revisar. Un agente escribe un primer borrador, luego lanza un agente revisor con instrucciones de criticarlo. El feedback del revisor vuelve al agente original (o a un nuevo agente de redacción) para revisión. Esto produce resultados notablemente mejores que la generación en una sola pasada, porque el agente revisor tiene una ventana de contexto fresca y puede evaluar el borrador sin la carga cognitiva de haberlo escrito.
El tercer patrón es la especialización de herramientas. Algunas tareas requieren herramientas que son costosas o arriesgadas — navegación web, ejecución de comandos de shell, modificaciones del sistema de archivos. Un agente padre puede delegar estas operaciones a agentes hijos con acceso específico a herramientas, manteniendo su propio contexto limpio y sus propios permisos mínimos. El padre nunca toca directamente el sistema de archivos ni la red; solo procesa los resultados que los agentes hijos devuelven.
Los límites de los enjambres
Los enjambres no son gratis. Cada agente hijo es una llamada separada a la API de Claude, lo que significa costes de tokens separados. Un enjambre que lanza cinco agentes de investigación cuesta aproximadamente cinco veces más que un solo agente haciendo toda la investigación. Para preguntas simples — "¿qué tiempo hace?" o "traduce esta frase" — los enjambres son puro overhead.
La latencia también se acumula. Incluso con ejecución en paralelo, el agente padre tiene que esperar a que el hijo más lento complete antes de poder sintetizar resultados. Un enjambre de cinco agentes donde uno tarda 30 segundos en navegar un sitio web lento significa que el usuario espera 30 segundos más el tiempo de síntesis, independientemente de lo rápidos que fueran los otros cuatro.
NanoClaw maneja esto de forma pragmática. Claude decide cuándo usar enjambres basándose en la complejidad de la tarea — las preguntas simples obtienen respuestas directas, las solicitudes complejas de múltiples partes se delegan. El usuario no configura el comportamiento de enjambres; simplemente hace preguntas, y el sistema escala su enfoque para ajustarse a la complejidad. El objetivo no es usar enjambres en todas partes — es usarlos donde genuinamente producen mejores resultados de lo que un solo agente podría.
El futuro multi-agente no se trata de reemplazar agentes individuales. Se trata de darles a los agentes individuales la capacidad de pedir ayuda cuando la necesitan, de una forma que sea segura, aislada y transparente. El modelo de contenedor-por-agente de NanoClaw hace eso posible sin los compromisos de seguridad que vienen de ejecutar múltiples agentes en un entorno compartido.