Multi-Agent Coordination
Multi-Agent Coordination describe cómo varias ejecuciones agentes organizan trabajo hacia objetivos relacionados, gestionando dependencias, propiedad, comunicación, integración y conflictos. El foco no es simplemente que existan varios agentes, sino qué compromisos conectan sus acciones y cómo se mantiene una interpretación suficiente del trabajo compartido.
La definición de trabajo del Atlas abarca combinaciones jerárquicas, entre pares, con handoffs o con especialistas. No prescribe una topología ni un protocolo. Tampoco convierte multi-agent en una etapa superior de madurez: un único agente puede ser la solución más apropiada cuando dividir la tarea agrega coordinación sin aportar capacidad o evidencia relevante.
Qué se está coordinando
Una tarea puede contener objetivos compartidos y contribuciones distintas. Coordinar incluye decidir quién investiga, quién modifica, qué información necesita cada parte y cómo se interpreta el resultado combinado. La asignación nominal de roles no resuelve por sí sola dependencias o desacuerdos sobre el contrato.
También puede haber acciones sobre recursos comunes: archivos, entornos, herramientas o servicios externos. Una ejecución puede cambiar una condición que otra consideraba estable. El problema de coordinación incluye reconocer esos puntos de contacto y elegir qué información o límites necesitan mantenerse visibles.
No toda interacción requiere un sistema elaborado. Un encargo bien delimitado y un resultado integrado por un responsable pueden ser suficientes. La complejidad debería seguir las dependencias reales, no la posibilidad técnica de crear más participantes o adoptar un framework.
Ejecuciones, roles y modelos
Un sistema puede utilizar el mismo modelo en varias ejecuciones con contextos y herramientas distintos. También puede combinar modelos diferentes. La cantidad de modelos no determina cuántas responsabilidades agentes existen ni cómo se coordinan. Importa quién persigue qué objetivo y qué selección de acciones puede realizar cada ejecución.
Agent Profiles configura roles reutilizables; no demuestra que esos roles estén activos. Dos perfiles pueden configurar una sola ejecución en momentos distintos. Un subagente puede existir sin perfil persistente. La coordinación trabaja con ejecuciones y resultados efectivos, no con un catálogo de nombres de especialistas.
Las personas y los procesos organizacionales también pueden decidir prioridades, resolver conflictos y aceptar resultados. Coordinar agentes no elimina esas responsabilidades. Una instrucción para colaborar puede orientar el comportamiento, pero no reemplaza acuerdos explícitos cuando las acciones tienen efectos incompatibles.
Multi-agent y subagentes
Subagents and Delegation describe una relación de trabajo acotado donde el llamador conserva una responsabilidad más amplia. Puede formar parte de un sistema multiagente, pero no define todas sus estructuras. También pueden colaborar pares o transferirse control sin una jerarquía permanente.
La delegación puede simplificar propiedad del resultado al conservar un integrador claro. Aun así, necesita decidir cómo tratar respuestas parciales y qué hacer si dos contribuciones entran en conflicto. La jerarquía no garantiza que el coordinador tenga contexto suficiente o evalúe correctamente los resultados.
La coordinación tampoco exige concurrencia. Dos agentes pueden intervenir secuencialmente, con una transferencia explícita entre etapas. Parallel Agent Execution estudia el caso en que varias ejecuciones progresan concurrentemente, una decisión de ejecución que introduce condiciones adicionales.
Orchestrator–Workers y otras estructuras
Agentic Workflow Patterns agrupa Orchestrator–Workers como un patrón de descomposición, delegación y agregación. Un sistema que lo utiliza puede ser multiagente si sus workers son agentes. También puede utilizar tools, llamadas a modelos o procesos convencionales como workers, sin que todos sean ejecuciones agentes.
Multi-Agent Coordination es el problema más amplio de organizar varias ejecuciones. No todos los casos utilizan un orquestador central. Una estructura entre pares puede distribuir decisiones, mientras una jerarquía puede concentrar integración. Cada opción cambia qué información necesita cada participante y dónde se resuelven conflictos.
No se propone aquí un catálogo de arquitecturas nuevas. La elección debe considerar límites del trabajo, autoridad y costo de mantener coherencia. Un mecanismo central puede ser suficiente y claro; distribuirlo puede introducir comunicación y estado adicionales sin resolver un problema presente.
Objetivos y fronteras de trabajo
Cada contribución necesita una relación con el objetivo común. “Mejorar el módulo” puede llevar a refactorizaciones incompatibles entre participantes; “identificar consumidores afectados por este contrato sin editar” ofrece una frontera más evaluable. El encuadre debe permitir autonomía local sin perder restricciones globales.
También interesa conocer exclusiones y supuestos compartidos. Si una ejecución cree que puede modificar una interfaz y otra debe preservarla, la integración encontrará un conflicto que no es solo textual. Planning puede representar dependencias y decisiones pendientes, pero el artefacto debe mantenerse alineado con el encargo vigente.
Una división útil no requiere que todas las partes tengan el mismo tamaño. La granularidad puede seguir especialidad, riesgo o fronteras de recursos. Dividir para repartir trabajo de manera simétrica puede aumentar transferencias e impedir que una responsabilidad estrechamente relacionada se mantenga comprensible.
Propiedad, autoridad y aceptación
Coordinar requiere saber quién puede modificar un recurso y quién integra o acepta el resultado. Ser responsable de una investigación no concede permiso para aplicar cualquier corrección que parezca pertinente. Agent Permissions and Approval Boundaries conserva el alcance de autoridad de cada ejecución.
La propiedad puede ser temporal o limitada a una parte del trabajo. Si cambia, interesa comunicar qué decisión o transferencia la produjo. Un nombre como “owner” no sustituye definir qué acciones están incluidas. Tampoco una ejecución debería eludir una restricción propia solicitando a otro participante que realice la acción fuera del alcance permitido.
La aceptación del resultado global necesita condiciones y evidencia. Que cada participante marque su tarea como completa no demuestra que la combinación satisfaga el encargo. La integración conserva una responsabilidad propia y no debería desaparecer entre varios reportes locales favorables.
Dependencias y comunicación
Algunas partes pueden avanzar con un contrato estable; otras necesitan una decisión o resultado previo. Comunicar esa dependencia permite evitar trabajo basado en una interfaz todavía incierta. No hace falta enviar toda conversación a todos los participantes: interesa la información que puede cambiar su siguiente decisión.
Las referencias necesitan identidad y vigencia suficientes. Un mensaje sobre “la versión nueva” puede ser ambiguo si hay varias revisiones o cambios locales. Un participante puede continuar con contexto obsoleto aunque el artefacto correcto ya esté disponible. Context Engineering for Software Development ayuda a seleccionar y renovar esa información en tareas de software.
La comunicación tiene costo y puede producir desacuerdos o interpretaciones distintas. Agregar mensajes no garantiza coherencia. Una frontera clara de tarea y una fuente común del contrato pueden reducir la necesidad de coordinación continua más que una conversación extensa sin decisiones identificables.
Shared state y recursos comunes
Los participantes pueden compartir task state, memoria, artefactos, repositorio o servicios externos. Esas clases de estado cumplen funciones diferentes. Agent Memory conserva información para decisiones futuras; un tablero de trabajo puede representar responsabilidades actuales. Usar el mismo almacenamiento no vuelve idénticas sus semánticas.
Un agente puede leer una condición, otro modificarla y el primero actuar sobre la interpretación anterior. También pueden sobrescribirse cambios o duplicarse operaciones. No se redefinen aquí fundamentos de concurrencia; se identifican sus consecuencias para la coordinación del trabajo agente y la necesidad de conocer las fronteras compartidas.
Workspace Isolation for Coding Agents reduce ciertas colisiones de archivos y estado de control de versiones. No separa automáticamente bases de datos, puertos, credenciales o APIs. Un diseño que solo distribuye carpetas debe mantener visibles los efectos que todavía pueden interferir.
Integración y conflictos
Los resultados pueden complementarse, contradecirse o depender de supuestos distintos. La integración necesita conservar suficiente procedencia para evaluar esos casos. Una síntesis que mezcla conclusiones sin sus condiciones puede producir una respuesta global aparentemente coherente y técnicamente incorrecta.
Las discrepancias no se resuelven necesariamente por votación. Importan evidencia, contratos y autoridad de las decisiones. Dos agentes pueden compartir un error y un tercero identificar un límite real. Tampoco una respuesta más detallada demuestra mejor sustento. El responsable de integrar debe poder distinguir hallazgo, hipótesis y recomendación.
Cuando hay cambios de código, ausencia de conflicto textual no prueba compatibilidad semántica. Generated Code Verification necesita evidencia sobre el estado combinado pertinente. Las comprobaciones de cada parte pueden seguir siendo útiles sin representar por completo la versión integrada.
Resultados tardíos y cambios de alcance
Un resultado también puede llegar después de que cambió el alcance o el contrato compartido. No es necesariamente incorrecto en su revisión original, pero puede haber dejado de ser aplicable. Integrarlo sin contrastar esa base puede reintroducir una decisión retirada. La coordinación necesita distinguir resultado válido para un estado anterior de contribución vigente para el cierre actual, conservando la evidencia que permita entender la diferencia.
Esto importa cuando se reasigna trabajo después de una interrupción. La ejecución inicial puede terminar más tarde y devolver una propuesta que compite con la de su reemplazo. Elegir la última respuesta recibida no determina cuál corresponde usar. Interesan la revisión, el encargo y la evidencia de cada una. Puede ser razonable conservar hallazgos de ambas sin aplicar sus cambios juntos. También puede corresponder descartar una contribución fuera de alcance, explicando la decisión en lugar de presentar su ausencia como si nunca se hubiera ejecutado trabajo. La integración sigue siendo una responsabilidad explícita, no una consecuencia automática de recibir resultados.
Handoffs y protocolos
Agent Handoffs transfiere responsabilidad o control. Puede ser una herramienta de coordinación entre etapas o participantes, sin requerir una arquitectura jerárquica. La transferencia de información es necesaria en muchos casos, pero no demuestra por sí misma que alguien haya asumido el siguiente paso.
Agent2Agent Protocol ofrece interoperabilidad entre sistemas agentes. Puede transportar mensajes y trabajo relacionado, pero no define la asignación de responsabilidad del sistema completo. Protocolo y arquitectura son dimensiones distintas: comunicar por A2A no garantiza coordinación correcta ni es un requisito para colaborar localmente.
La misma separación aplica a MCP y ACP. Pueden integrar capacidades o clientes según el caso. No forman una pila obligatoria para un sistema multiagente y no sustituyen decisiones sobre propiedad, efectos y aceptación.
Fallos y recuperación
Una ejecución puede fallar mientras otras producen resultados válidos. La coordinación necesita decidir qué partes siguen siendo utilizables, qué depende del resultado ausente y si corresponde repetir, reasignar o detener trabajo. Reiniciar todo puede descartar progreso útil; continuar todo puede propagar una premisa inválida.
Agent Checkpoints and Recovery puede facilitar reanudación de participantes, pero restaurar uno no vuelve coherente todo el conjunto. Otro agente puede haber cambiado recursos o integrado un resultado posterior. La recuperación necesita reconciliar ese estado y considerar efectos externos antes de repetir operaciones.
Agent Tracing y los Development Context and Execution Records pueden preservar relaciones entre asignaciones, resultados e integración. No exigen razonamiento privado ni convierten una secuencia completa de eventos en prueba de corrección. Ayudan a determinar qué se sabe y dónde está la incertidumbre.
Ejemplo: contrato y consumidor
Una tarea modifica una respuesta de API y otra adapta un cliente. Ambas ejecuciones pueden comenzar con una propuesta común. Si una introduce un estado nuevo y la otra asume que el conjunto anterior era exhaustivo, los cambios pueden integrarse sin conflicto textual y fallar en el recorrido completo.
Coordinar requiere conservar el contrato vigente y comunicar qué decisiones cambian sus supuestos. Puede ser necesario ordenar ciertos pasos o mantener temporalmente compatibilidad. No se sigue que haga falta un sistema multiagente más complejo: una decisión explícita y un punto de integración pueden resolver la dependencia.
La verificación de la combinación debe relacionarse con la revisión integrada. Reportar dos suites verdes sobre estados distintos no demuestra que la funcionalidad compartida quedó respaldada. El ejemplo muestra una responsabilidad de coordinación que no se elimina separando agentes o workspaces.
Costo y criterio de uso
El trabajo distribuido puede duplicar exploración, consumir contexto adicional y agregar comunicación, integración y revisión. Parte de esa duplicación puede ser deliberada para contrastar evidencia; otra parte puede expresar una división deficiente. Conviene juzgarla por lo que aporta, no eliminarla automáticamente ni considerarla señal de rigor.
Más agentes no garantizan mejor resultado, menor latencia ni menor costo. El beneficio depende de qué partes admiten separación y de cuánto trabajo vuelve a concentrarse en integración. Un único agente puede ser más simple y suficiente. También puede haber razones válidas para varios participantes cuando las fronteras y contribuciones están claras.
Agent Evaluation puede examinar resultados, trayectorias y costos bajo condiciones comparables. La cantidad de participantes no sustituye esa evidencia. Multi-Agent Coordination conserva el problema de organizar responsabilidades y dependencias, sin transformarlo en una recomendación universal de arquitectura ni en un nivel de madurez.