IA al Día
la manera eficiente de informarte
Volver al archivo
Herramientas 5 de junio de 2026 análisis 5 min de lectura

Orquestación multi-agente: cómo ejecutar coding agents en paralelo sin que se pisen

Sandcastle, Minimax Agent Teams, Claude Code Teams y seis frameworks compiten por el mismo problema: cómo hacer que múltiples agentes de IA trabajen juntos sin pisarse. Un recorrido por las arquitecturas, los costos y las trampas de la orquestación multi-agente.

Orquestación multi-agente: cómo ejecutar coding agents en paralelo sin que se pisen
Por IA al Día

Cuando un solo agente de IA no es suficiente, el siguiente paso lógico es usar varios. Pero poner dos agentes a trabajar en la misma base de código no es como poner dos desarrolladores a colaborar — es más como poner dos asistentes que no se hablan entre sí en la misma habitación, y esperar que no rompan nada.

La orquestación multi-agente se ha convertido en uno de los temas más activos del ecosistema de IA en 2026. Seis frameworks compiten por definir cómo se coordinan los agentes. Nuevas herramientas como Sandcastle resuelven el problema del aislamiento de entornos. Y los costos ocultos de la paralelización empiezan a hacerse visibles.

Sandcastle: aislamiento por contenedor

Sandcastle es una biblioteca TypeScript creada por Matt Pocock (@ai-hero/sandcastle en npm) que permite ejecutar múltiples coding agents en paralelo, cada uno en su propio contenedor Docker con su propia rama de git.

Cada agente se lanza con sandcastle.run(), recibe su propia copia del repositorio en una rama aislada dentro de un contenedor, y al terminar, Sandcastle fusiona los cambios. Soporta backends de Docker, Podman y Vercel Firecracker (microVMs). La metáfora es simple: tratar cada agente como un desarrollador temporal con su propia máquina virtual.

El video de YouTube que originó esta investigación lo llama “Docker Worktrees” — un portmanteau que combina Docker (contenedores) con git worktrees (ramas paralelas). No es exactamente git worktree en el sentido nativo, pero la idea es la misma: aislamiento total para que ningún agente contamine el trabajo del otro.

Minimax Agent Teams: Leader, Worker, Verifier

El 27 de mayo de 2026, MiniMax anunció su arquitectura de equipos de agentes como parte de la actualización Mavis. El diseño es explícito y estructurado:

  • Leader: traduce objetivos del usuario en una estructura de tareas, decide qué Workers ejecutar y en qué orden.
  • Workers: ejecutan subtareas específicas con herramientas y contexto especializados. Pueden correr en paralelo.
  • Verifiers: revisan el trabajo de los Workers de forma independiente, en un bucle adversarial — similar al control de calidad frente a desarrollo.

El sistema usa una máquina de estados (Team Engine) con ciclo produce → verify → done. Si la verificación falla, el nodo productor se despierta para rehacer el trabajo. Es lógica determinista, no basada en prompts.

MiniMax es honesto sobre los costos: identifica tres tipos — costo de handoff (reorganizar información entre agentes), costo de sharing (dar visibilidad a todos los agentes), y costo de agregación (fusionar salidas paralelas). Citan el paper “Cost of Consensus” que muestra 2.1-3.4x consumo de tokens en configuraciones homogéneas sin mejora de precisión.

El panorama de frameworks

La orquestación multi-agente tiene al menos seis enfoques compitiendo, cada uno con un modelo de coordinación diferente:

FrameworkModeloEditor
LangGraphBasado en grafos (supervisor)LangChain
OpenAI Agents SDKHandoff (transferencia entre agentes)OpenAI
CrewAIBasado en rolesCrewAI
AutoGen/AG2ConversacionalMicrosoft
Google ADKJerárquico (protocolo A2A)Google
Claude Agent SDKTool-use + MCPAnthropic

Claude Code también tiene su propio Agent Teams experimental, donde un Lead Agent crea un equipo, asigna tareas a Teammates con contextos aislados, supervisa el progreso y fusiona los resultados. Cada Teammate es una instancia completa de Claude Code con su propia ventana de contexto.

Los problemas que nadie ha resuelto aún

1. Costo de paralelización. Ejecutar N agentes en paralelo no cuesta N veces más — a menudo cuesta más por la sobrecarga de coordinación, verificación y fusión. La promesa de “paralelismo gratis” no existe en la práctica.

2. Conflictos semánticos. Sandcastle y git worktrees resuelven conflictos textuales (dos agentes modificando la misma línea), pero no los semánticos (dos agentes cambiando la misma función de formas incompatibles en archivos diferentes). La fusión de git detecta el primero, pero el segundo requiere revisión humana.

3. Estado compartido. ¿Cómo compartir contexto entre agentes sin saturar sus ventanas de contexto? ¿Cómo asegurar que un agente sabe lo que el otro hizo sin que eso triplique los tokens? Cada framework tiene una respuesta diferente, y ninguna es universal.

4. Evaluación multi-agente. Si es difícil evaluar un solo agente (como vimos en el artículo anterior sobre benchmarks), evaluar un sistema de múltiples agentes es un orden de magnitud más complejo. No existen benchmarks multi-agente aceptados.

Para qué sirve hoy

La orquestación multi-agente no es para todos los proyectos. Tiene sentido cuando:

  • Necesitas que un agente investigue mientras otro escribe código y un tercero revisa.
  • Trabajas con codebases grandes donde un solo agente pierde contexto.
  • Quieres paralelizar tareas independientes (tests, documentación, refactors aislados).

Para un desarrollador individual con un proyecto pequeño, un solo agente bien configurado probablemente sea más eficiente. Pero a medida que los equipos y los proyectos crecen, la orquestación multi-agente se está convirtiendo en una necesidad de infraestructura, no en un lujo experimental.


Fuentes: Sandcastle GitHub · MiniMax Agent Team Blog · GuruSup: Multi-Agent Frameworks 2026 · Claude Code Agent Teams · Addy Osmani: Code Agent Orchestra

Más en esta categoría