Parallel Agent Execution
Parallel Agent Execution es la táctica de permitir que varias ejecuciones agentes progresen concurrentemente cuando el trabajo y sus dependencias lo admiten. Cada ejecución puede observar, seleccionar acciones y recibir resultados dentro de sus límites. El concepto se refiere a concurrencia del trabajo agente, no a exigir que cada operación utilice hardware al mismo instante ni a contar cuántos modelos diferentes hay.
La táctica puede reducir espera o separar investigaciones, pero introduce coordinación, consumo de recursos e integración. No implica mayor madurez y no garantiza menor latencia o costo. Su utilidad depende de cuánto trabajo puede avanzar independientemente y de qué incertidumbre o sobrecarga agrega reunir los resultados.
Paralelismo y coordinación
Multi-Agent Coordination organiza responsabilidades, dependencias y conflictos entre ejecuciones. Parallel Agent Execution agrega concurrencia a esa organización. Un sistema multiagente puede trabajar secuencialmente y seguir necesitando coordinación; varias tareas delegadas pueden ejecutarse concurrentemente dentro de una relación jerárquica.
La existencia de varios agentes no demuestra que estén progresando a la vez. Pueden estar en cola, detenidos por la misma dependencia o esperando un recurso único. La evidencia de ejecución necesita distinguir trabajo activo, espera y finalización, sin inferir paralelismo solo a partir de una configuración con varios participantes.
La coordinación conserva decisiones que el paralelismo no resuelve: quién integra, qué revisión se comparte y cómo se trata una discrepancia. Separar ejecución puede hacer más visibles esas necesidades, pero no elegir por sí mismo una solución correcta.
Agentes y herramientas concurrentes
Un agente puede emitir varias solicitudes de herramientas que el runtime ejecute concurrentemente. Eso no implica múltiples agentes. Tool Calling conserva la interacción de invocación y resultado; las herramientas pueden realizar operaciones predefinidas sin seleccionar una trayectoria agentic propia.
En Parallel Agent Execution hay varias ejecuciones con trabajo y continuidad propios. Pueden utilizar el mismo modelo y diferentes contextos, o modelos distintos. La identidad del modelo no determina la cantidad de agentes y el número de procesos tampoco basta para reconocer sus responsabilidades.
La distinción importa al interpretar costo y evidencia. Paralelizar tres lecturas de archivos no crea tres revisores independientes. Un agente que recibe esas salidas sigue pudiendo compartir el mismo supuesto equivocado al interpretarlas. La concurrencia de herramientas no garantiza diversidad de juicio.
Workflow Parallelization
Agentic Workflow Patterns trata Parallelization y Fan-out–Fan-in como patrones de control: distribuir trabajo entre ramas y reunir resultados. Las ramas pueden ser llamadas a modelos, herramientas, agentes o procesos convencionales. El patrón no requiere que todas sean ejecuciones agentes.
Parallel Agent Execution describe un caso específico de concurrencia de agentes, no un sinónimo de cualquier fan-out. Puede utilizar ese patrón de workflow, pero conserva preguntas sobre contexto, autoridad y continuidad de cada participante. Un workflow con ramas predefinidas puede ser suficiente sin delegar selección dinámica de acciones.
Tampoco se necesita una arquitectura de orquestación nueva para toda oportunidad de concurrencia. Si dos operaciones simples pueden ejecutarse con herramientas existentes, crear agentes adicionales puede agregar contexto y revisión sin resolver una incertidumbre relevante.
Elegir trabajo suficientemente independiente
La independencia depende de contratos, recursos y supuestos. Dos tareas en archivos distintos pueden cambiar la misma semántica; dos investigaciones sobre una interfaz pueden ser independientes si no modifican recursos y devuelven evidencia acotada. La división debe considerar qué podría invalidar el trabajo de otro participante.
Una frontera útil permite avanzar sin esperar decisiones frecuentes de otra rama. Si una tarea necesita constantemente el resultado de otra, el paralelismo puede ser nominal y aumentar coordinación. Puede ser mejor ordenar parte del trabajo y dejar concurrencia solo en las actividades que realmente no dependen entre sí.
Planning puede representar esas dependencias y condiciones de reunión. El plan sigue siendo revisable si aparece una restricción. No corresponde conservar la división inicial por fidelidad al artefacto cuando la evidencia muestra que las partes están más acopladas de lo previsto.
Contexto, autoridad y límites
Cada ejecución necesita información suficiente para su contribución. Copiar todo el historial puede duplicar consumo e incorporar instrucciones irrelevantes. Transferir solo una frase puede ocultar una restricción decisiva. Subagents and Delegation conserva la definición de encargos acotados y resultados esperados.
La autoridad también debe interpretarse por participante y acción. Una rama de investigación no obtiene permiso de editar porque otra tiene ese permiso. Agent Permissions and Approval Boundaries delimita qué puede ejecutar cada identidad y qué fronteras requieren otra autorización.
Varias ejecuciones simultáneas pueden amplificar un error compartido. Si todas parten del mismo contrato equivocado, la concurrencia no aporta independencia frente a esa premisa. La evaluación debe considerar qué evidencia distinta obtiene cada parte y cómo se revisa la combinación.
Workspace y recursos compartidos
Workspace Isolation for Coding Agents puede reducir colisiones de archivos, índices y cambios locales. No crea concurrencia por sí misma. Dos workspaces pueden utilizarse secuencialmente, y varias ejecuciones pueden interferir en recursos externos aunque sus carpetas estén separadas.
Puertos, datos de prueba, servicios, credenciales y rutas absolutas de salida pueden seguir siendo comunes. Una rama puede borrar un dato que otra necesita o producir un artefacto con el mismo nombre. El aislamiento debe evaluarse por sus límites efectivos, sin atribuir a un worktree propiedades de sandbox o de coordinación global.
Los cambios de código también pueden ser incompatibles sin pisar la misma línea. La separación física facilita atribuir contribuciones, pero todavía hay que integrar y comprobar el resultado pertinente. No convierte la ausencia de conflictos de merge en evidencia de corrección.
Reunión de resultados
El integrador necesita conocer qué terminó, qué quedó pendiente y de qué supuestos depende cada respuesta. Esperar todas las ramas puede ser necesario para un resultado combinado o innecesario si una decisión ya quedó respaldada. La condición de reunión debe seguir la tarea, no una regla universal de que todo fan-out siempre termina de la misma manera.
Una respuesta rápida puede ser útil y una respuesta tardía contener una restricción decisiva. Elegir automáticamente la primera o la mayoría no establece calidad. Importan evidencia y alcance. La síntesis debe conservar diferencias relevantes sin devolver al usuario una suma de reportes contradictorios sin interpretación.
Generated Code Verification conserva el juicio sobre un cambio de software concreto. Los checks de cada rama pueden aportar evidencia sin representar el estado integrado. Si una modificación altera condiciones de otra, puede ser necesario comprobar la combinación antes de afirmar cumplimiento global.
Fallos y cancelación
Una rama puede fallar mientras otras continúan. El sistema necesita decidir si su contribución era imprescindible, si puede obtenerse por otra vía o si corresponde detener el conjunto. Reiniciar todo por defecto puede desperdiciar progreso; ignorar la falla puede ocultar una condición de aceptación necesaria.
Cancelar una ejecución no demuestra que todos sus efectos externos se detuvieron. Una herramienta remota puede seguir trabajando o haber completado una operación antes de la cancelación. La recuperación necesita observar qué ocurrió antes de repetir escrituras o asumir que no hay cambios que integrar.
Agent Checkpoints and Recovery puede ayudar a reanudar una parte del trabajo, sin restaurar automáticamente un estado global coherente. Otras ramas pueden haber avanzado. La continuidad requiere reconciliar esas diferencias y conservar su evidencia.
Tiempo, costo y contención
Dividir trabajo puede reducir la parte secuencial, pero no elimina preparación, transferencia de contexto e integración. Un recurso compartido puede seguir limitando progreso. Más agentes pueden competir por herramientas o capacidad de ejecución y aumentar espera, incluso si cada tarea era razonablemente independiente desde el punto de vista conceptual.
La cantidad de participantes tampoco se convierte directamente en costo monetario o consumo de tokens. Las ejecuciones pueden tener longitudes y necesidades distintas. Conviene medir lo que realmente se utiliza y distinguir tiempo de herramienta, duración de tarea y tiempo de entrega. El cuerpo general de AI Economics conserva su propio alcance futuro.
El caso de investigación multiagente de Anthropic, de junio de 2025, utiliza subagentes concurrentes para explorar aspectos de consultas. Ilustra una división de investigación con contextos separados; no demuestra que paralelizar cambios de código o cualquier otra carga reduzca siempre latencia, costo o errores.
Qué comparación se está haciendo
Una comparación de ejecución concurrente y secuencial necesita considerar la misma tarea y un estado inicial pertinente. Si la alternativa paralela recibe contexto previamente preparado o omite integración, la diferencia de tiempo no mide solo la táctica. Conviene conservar qué trabajo se incluyó y qué condiciones variaron, sin exigir un experimento complejo para cada decisión pequeña.
El trabajo descartado también consumió recursos. Cancelar ramas después de obtener suficiente evidencia puede ser apropiado, pero ocultar sus intentos produce una imagen incompleta del costo. Del mismo modo, medir solo la rama más rápida omite preparación y reunión. Las conclusiones deben referirse a la dimensión realmente observada y reconocer cuándo no se dispone de una medición fiable del resultado completo, en vez de traducir cantidad de agentes o llamadas a ahorro asegurado.
Ejemplo: dos investigaciones y una decisión
Un agente necesita determinar si una modificación de contrato afecta una API y su consumidor. Puede delegar dos investigaciones de lectura sobre una base identificable, cada una con un resultado acotado. Las ramas pueden avanzar concurrentemente mientras ninguna modifica el contrato común.
Si ambas devuelven hallazgos, el integrador contrasta versiones y condiciones. Si una propone cambiar la semántica que la otra asumía estable, la siguiente etapa puede necesitar una decisión conjunta y trabajo secuencial. Mantener paralelismo allí por principio agregaría cambios basados en supuestos incompatibles.
El beneficio potencial se encuentra en explorar partes separables, no en eliminar la responsabilidad de decidir e integrar. Un único agente también podría resolver el encargo; elegir la táctica depende del costo de las fronteras y de la evidencia que se necesita obtener.
Observar y evaluar la táctica
Agent Tracing puede mostrar relaciones entre asignaciones, actividad, espera y resultados. No necesita imponer un orden textual único a todos los eventos ni registrar razonamiento privado. Debe permitir distinguir qué ejecuciones ocurrieron y cómo sus resultados contribuyeron al cierre.
Agent Evaluation puede comparar calidad, límites y recursos bajo condiciones apropiadas. Más paralelismo no es una mejora si reduce evidencia, duplica efectos o aumenta el costo de revisión sin beneficio pertinente. Tampoco una ejecución secuencial exitosa demuestra que cualquier división concurrente sería innecesaria.
Parallel Agent Execution es una elección de ejecución, no una jerarquía de madurez ni una garantía de productividad. Resulta útil cuando el trabajo es suficientemente separable y la integración conserva significado, autoridad y evidencia. En otros casos, la solución más simple puede ser avanzar secuencialmente con un solo agente.
Fuentes
- Anthropic: How we built our multi-agent research system, 2025-06-13: caso específico citado, sin generalizar sus resultados a toda tarea o arquitectura.