En resumen
Los enjambres de agentes de IA dividen un único objetivo en tres roles: un planificador que descompone el trabajo en tareas, ejecutores (workers) que desarrollan esas tareas en paralelo en espacios de trabajo aislados, y verificadores que ponen a prueba cada cambio antes de darlo por definitivo. El planificador y el verificador utilizan el modelo más avanzado; los ejecutores emplean modelos más económicos y rápidos. Este patrón fracasa cuando los ejecutores comparten archivos, los verificadores dan el visto bueno a ciegas o nadie pone un límite al presupuesto.
Por qué los enjambres de agentes de IA vuelven a ser noticia
Google ha lanzado la disponibilidad general de Gemini 4 Carbon y ha presentado un adelanto de /swarm en Google Antigravity, una función que convierte un único prompt en un equipo coordinado de agentes. En palabras de Google, Carbon asume el «diseño arquitectónico, la coordinación y la auditoría», en combinación con «modelos más rápidos y ligeros en espacios de trabajo aislados en paralelo y verificadores antagónicos (adversarial) que prueban cada cambio».
Esa descripción define un patrón que puedes implementar con los modelos que ya utilizas hoy en día. Esta guía detalla los tres roles, por qué la inversión se concentra en planificar y verificar, en qué puntos suelen fallar los enjambres y cómo coordinar uno mediante un tablero compartido. Si ya trabajas con varios agentes de código, Sharkly asigna a cada uno una tarea (Task), un registro de ejecución y un paso de revisión, que es básicamente lo indispensable para un enjambre.
¿Qué es un enjambre de agentes de IA?
Un enjambre de agentes de IA es un conjunto de agentes que dividen un objetivo común en tareas independientes y las ejecutan de forma simultánea. Un agente diseña y distribuye el trabajo, varios agentes lo ejecutan en paralelo y uno o más agentes validan cada resultado antes de integrarlo. Cada rol tiene una función acotada y un traspaso de tareas claramente definido.
Anthropic describió esta misma arquitectura en 2024 como el patrón orquestador-trabajadores (orchestrator-workers): un modelo central desglosa la tarea, delega partes y recopila los resultados. El verificador es la adición más reciente y, a la vez, el rol que la mayoría de los equipos suele omitir.
Un enjambre no consiste simplemente en «muchos agentes haciendo el mismo trabajo». Colocar a cinco agentes con el mismo prompt sobre el mismo repositorio produce una condición de carrera, no un equipo. La separación de roles es lo que realmente define al enjambre. Para obtener una visión integral sobre cómo se coordinan, consulta qué es la orquestación de agentes de IA.
Los tres roles: planificador, ejecutores y verificadores
Cada rol responde a una pregunta diferente y necesita su propio contexto.
| Rol | Pregunta a la que responde | Modelo habitual | Lee | Escribe |
|---|---|---|---|---|
| Planificador | ¿Cuáles son las partes y quién asume cada una? | El más potente disponible | El objetivo, el mapa del código base | Lista de tareas, criterios de aceptación |
| Ejecutor (Worker) | ¿Cómo desarrollo esta parte concreta? | Más rápido y económico | Una tarea concreta y sus archivos | Un diff en su propio espacio de trabajo |
| Verificador | ¿Cumple este cambio lo estipulado en la tarea? | El más potente disponible | La tarea, el diff, el resultado de las pruebas | Aprobación, o rechazo motivado |
¿Qué hace el planificador?
El planificador transforma un objetivo amplio en tareas concretas que no se solapan. Un buen plan delimita qué archivos puede tocar cada tarea, define la prueba que confirma su resolución y establece el orden adecuado cuando existen dependencias. Si dos tareas necesitan modificar el mismo archivo, el planificador las fusiona en una sola o las organiza en secuencia.
¿Qué hacen los ejecutores?
Los ejecutores desarrollan una sola tarea cada uno, en paralelo, y nada más. Cada ejecutor cuenta con su propio entorno de trabajo, normalmente un git worktree: una copia local independiente del mismo repositorio en su propia rama. Ese aislamiento es el que hace posible que tres agentes modifiquen código a la vez sin pisarse entre sí. Más detalles al respecto en agentes paralelos en worktrees aislados.
¿Qué hacen los verificadores?
Los verificadores intentan demostrar que una solución es incorrecta. La palabra que emplea Google es «antagónico» (adversarial), y es muy acertada: el verificador ejecuta las pruebas, examina el diff en contraste con los requisitos de la tarea y detecta cualquier atajo indebido del ejecutor. Un verificador que se limite a comprobar si «pasan los tests» pasará por alto a un ejecutor que haya modificado los tests para que pasen.
Por qué el modelo más costoso se reserva para planificar y auditar
Planificar y verificar implican lecturas breves con un impacto crítico. Construir código requiere generar muchas líneas con un riesgo relativamente bajo por cada línea individual. Esta asimetría es la que determina qué modelo asignar a cada fase.
Un planificador redacta apenas unos cientos de líneas con especificaciones de tareas. Un verificador redacta un veredicto. Ninguno genera un volumen masivo de salida, por lo que pagar un precio prémium por token apenas incrementa el gasto total. Los ejecutores, en cambio, generan la inmensa mayoría de los tokens; por tanto, emplear modelos económicos en esa etapa es donde se logra el mayor ahorro.
Además, los errores escalan de forma muy distinta. Un mal plan desorienta a todos los ejecutores, y un verificador indulgente dará luz verde a cualquier cambio defectuoso. Un ejecutor débil solo genera un mal diff, el cual será interceptado por el verificador. Conviene invertir el mejor criterio donde las consecuencias de un fallo se multiplican.
El propio posicionamiento de Google ratifica esta estrategia. Señala que Gemini 4 Argon «sigue siendo la opción ideal para la gran mayoría de tareas de ingeniería de software y trabajo de conocimiento», mientras que Carbon utiliza más tokens «para explorar exhaustivamente, razonar en profundidad y sostener bucles de verificación prolongados». Carbon cuesta 2 $ por millón de tokens de entrada y 10 $ por millón de tokens de salida hasta el 30 de noviembre de 2026, pasando luego a 4 $ y 20 $. Para examinar a fondo las características de cada modelo, lee Gemini 4 Carbon para agentes de código y Gemini 4 Argon para agentes de código. Este mismo razonamiento se aplica a cualquier combinación de modelos; consulta Crews de modelos mixtos con workers económicos y un revisor prémium.
Dónde suelen fallar los enjambres de agentes de IA
La mayor parte de los fallos en un enjambre se originan en tres carencias: estado compartido, validaciones superficiales y ausencia de presupuesto límite.
¿Por qué los agentes se sobreescriben entre sí?
Dos ejecutores modifican el mismo archivo porque el plan no indicó lo contrario. Sin espacios de trabajo aislados, la última escritura se impone y el trabajo del primer ejecutor se pierde. Con aislamiento, ambas modificaciones subsisten hasta la fusión (merge), donde inevitablemente entran en conflicto. La solución empieza en la planificación: asigna la responsabilidad de los archivos por tarea y ejecuta de forma secuencial aquellas tareas que coincidan en los mismos ficheros.
¿Por qué los verificadores aprueban sin revisar a fondo?
Un verificador que revisa el resumen redactado por el propio ejecutor en lugar del diff está evaluando una declaración de intenciones, no el trabajo real. Lee que «todos los tests pasan» y asume que es cierto. Facilita al verificador el diff directo y la salida real de los tests, nunca el auto-informe del ejecutor. Utiliza además un modelo distinto al de los ejecutores, para evitar que comparta sus mismos puntos ciegos. El artículo sobre agentes de revisión de código con IA profundiza en lo que un agente revisor puede y no puede comprobar.
¿Cómo se disparan los costes en un enjambre?
Cada rechazo provoca un nuevo ciclo de desarrollo y otra revisión; por tanto, una tarea rechazada tres veces multiplica por cuatro el coste de ambas fases. Diez ejecutores en bucle de rechazo durante toda la noche pueden devorar el presupuesto de una semana. Limita los reintentos por tarea (dos es un límite por defecto razonable), restringe la concurrencia de ejecutores y deriva la tarea a un humano si se agota el último reintento.
Existe un cuarto problema oculto tras los anteriores: si la planificación, las ejecuciones y los veredictos conviven en la misma ventana de contexto, resulta imposible auditar el resultado con garantías. Siempre se necesita alguien externo al enjambre que lo supervise.
Cómo gestionar un enjambre de agentes de IA en un tablero compartido
No necesitas una herramienta especializada en enjambres para poner uno en marcha. Solo requieres tareas, espacios de trabajo aislados y un control de calidad (gate). Un tablero compartido te ofrece las tres cosas y mantiene el historial visible para el equipo.
- Crea una tarea principal para el objetivo general. El planificador la analiza y genera el plan en forma de subtareas, definiendo para cada una los archivos implicados y la prueba de aceptación.
- Asigna estrictamente una tarea a cada ejecutor. Una tarea, un agente, una rama. Si dos subtareas comparten algún archivo, unifícalas antes de empezar.
- Ejecuta cada tarea en su propio directorio. Un worktree por ejecución mantiene separadas las modificaciones simultáneas.
- Incorpora un estado de Revisión antes de Hecho (Done). Ninguna tarea debe pasar a Hecho basándose únicamente en el testimonio del ejecutor.
- Asigna la revisión a un agente verificador con un modelo más potente. Analiza el diff y la salida de los tests, tras lo cual aprueba la tarea o la devuelve justificando el motivo.
- Sitúa a una persona en el último paso. El verificador filtra la lista; un humano valida y acepta el resultado final.
Así se traslada esta dinámica a Sharkly. Un Crew es un equipo reutilizable de personas y agentes coordinado por un agente líder. Al asignar la tarea principal al Crew, el líder se activa primero: lee la tarea, convoca a los agentes miembros para partes específicas y recopila sus resultados. Ese orden jerárquico garantiza que ningún ejecutor empiece antes de que el plan esté listo.
Los agentes en modo de directorio de trabajo temporal obtienen una carpeta aislada por cada tarea, y las ejecuciones sobre repositorio pueden crear un worktree limpio, impidiendo que los ejecutores en paralelo compartan archivos. Cada agente opera en el Runtime que configures, permitiendo que el líder y el revisor utilicen un modelo de mayor capacidad que los ejecutores.
El control de calidad es un estado dentro del flujo de trabajo de la tarea. Un agente puede dejar la tarea a la espera de validación humana, y ese traspaso aparece reflejado en el módulo Task Chats de la barra lateral, como detalla la documentación sobre ejecución de tareas con agentes. Los fallos o bloqueos se notifican en la bandeja de entrada (Inbox). Los agentes investigan, programan, prueban e informan. Las personas definen la estrategia, autorizan acciones y dan el visto bueno final. Puedes empezar a usar Sharkly gratis: conecta un Computer, configura dos agentes y encarga a un Crew una tarea sencilla. Para profundizar en el componente humano, lee diseñar la revisión para agentes paralelos.
Cuándo no necesitas un enjambre de agentes de IA
Evita el enjambre cuando el trabajo no pueda dividirse. Un arreglo de un bug puntual, un refactor de un solo archivo o un razonamiento encadenado prolongado se resuelven más rápido con un solo agente potente y un revisor. Con menos de tres tareas independientes, los costes de coordinación suelen superar los beneficios del trabajo en paralelo.
Usa un enjambre cuando el objetivo admita división en componentes que toquen archivos distintos: una migración entre varios paquetes, la incorporación retroactiva de tests en diferentes módulos o una modificación de API replicada en diez servicios. Google destaca las «migraciones entre múltiples paquetes» y la «investigación de causas raíz entre subsistemas» como tareas que Carbon maneja con soltura en configuraciones multiagente.
Conclusión
Un enjambre de agentes de IA no consiste en un único prompt gigantesco, sino en tres funciones: planificar, construir y verificar. Destina tu modelo más avanzado al plan y al veredicto, modelos económicos a la construcción, y registra cada resultado en un formato comprensible para las personas. Empieza con una tarea principal, tres ejecutores y un verificador. Para poner en práctica este flujo con los agentes que ya tienes, conecta un Computer a Sharkly y asigna trabajo a tu primer Crew.
Preguntas frecuentes
¿Cuál es la diferencia entre un enjambre de agentes y la orquestación multiagente?
La orquestación es la disciplina global de coordinar múltiples agentes. Un enjambre es un patrón concreto de orquestación con funciones fijas: un planificador, ejecutores en paralelo y verificadores. Todo enjambre está orquestado; no toda orquestación es un enjambre.
¿Cuántos agentes debe tener un enjambre de IA?
Lo ideal es comenzar con un planificador, tres ejecutores y un verificador. Incorpora más ejecutores únicamente si las tareas continúan siendo independientes y la capacidad de revisión no se desborda. Añadir más ejecutores de los que puedes auditar solo traslada el cuello de botella al verificador.
¿Pueden el planificador y el verificador ser el mismo agente?
Pueden utilizar el mismo modelo base, pero deben ejecutarse por separado y con contextos independientes. Un planificador que audita su propio plan tiende a sesgarse y aprobarlo. Un verificador nuevo evaluará el diff sin las presunciones previas del planificador.
¿Hace falta Google Antigravity para coordinar un enjambre de agentes?
No. Aunque /swarm es una vista previa disponible en Antigravity, el patrón en sí solo requiere desglose de tareas, espacios de trabajo aislados y un paso de revisión. Puedes implementarlo mediante git worktrees y un tablero kanban con los agentes de código que ya utilices habitualmente.
¿Qué impide que los ejecutores del enjambre editen el mismo archivo?
El plan asigna la propiedad de los archivos para que las tareas no choquen entre sí, y los espacios de trabajo aislados mantienen las modificaciones de cada ejecutor en ramas separadas hasta su integración. Incorporar una regla de CODEOWNERS añade un mecanismo de control adicional durante la revisión.
