Orquesta de agentes de código: cómo hacer que la codificación multiagente realmente funcione

• La transición desde una forma de colaboración con un único asistente de IA y un bucle sincrónico hacia un modelo de orquestador, donde varios agentes operan de forma asincrónica con sus propias ventanas de contexto y alcance de archivos, está en marcha en 2026
• Tres patrones clave —subagentes (Subagents), equipos de agentes (Agent Teams) y delegación jerárquica— constituyen la estructura base de la codificación multiagente, y cada uno aporta efectos como paralelismo, especialización, aislamiento y aprendizaje compuesto
• La lista compartida de tareas y la mensajería peer-to-peer son los mecanismos centrales de coordinación en los equipos de agentes, lo que permite liberar dependencias automáticamente y evitar cuellos de botella
• En 2026, el ecosistema de herramientas se divide en tres capas: subagentes in-process (Tier 1), orquestadores locales (Tier 2) y agentes asincrónicos en la nube (Tier 3), y la mayoría de los desarrolladores combina las tres según el caso de uso
• El cuello de botella ya no está en la generación de código sino en la verificación (Verification), y las compuertas de calidad mediante aprobación de planes, hooks y AGENTS.md, junto con la revisión humana, son los factores clave que determinan la confiabilidad de un sistema multiagente

---

La transición actual: del conductor al orquestador

• Hasta hace 6 meses, la mayoría de los desarrolladores trabajaba de forma sincrónica con un único asistente de IA, y una sola ventana de contexto marcaba el límite superior del trabajo
• Hoy, los desarrolladores más productivos están pasando a coordinar de forma asincrónica varios agentes, cada uno con su propia ventana de contexto, alcance de archivos y área de responsabilidad
• Modelo conductor (Conductor): guía a un solo agente en tiempo real y de forma sincrónica; Claude Code CLI y el modo agente dentro del editor Cursor son herramientas representativas
• Modelo orquestador (Orchestrator): coordina de forma asincrónica varios agentes, cada uno con su propia ventana de contexto; Agent Teams, Conductor, Codex y Copilot Coding Agent son herramientas representativas
• Como orquestador, ahora se requieren nuevas habilidades: redactar especificaciones claras, descomponer tareas y verificar entregables

Las 8 etapas de la codificación asistida por IA

• [Orquestación]
  • L8 — Construir tu propio orquestador: implementar por cuenta propia una capa de coordinación escribiendo código para crear, enrutar y administrar agentes
  • L7 — Más de 10 agentes, gestionados manualmente: “Ups, esto se volvió un caos”. El contexto equivocado se pasa al agente equivocado, y empieza la pregunta: “¿Qué pasa si Claude Code ejecuta Claude Code?”
  • L6 — Multiplexación de agentes: como esperar aburre, se van lanzando agentes uno por uno, saltando entre varios flujos hasta llegar a un punto de no retorno
• [Agente primero]
  • L5 — Agente primero, IDE después: la conversación con el agente es el espacio de trabajo principal, y el IDE queda para revisar el código
  • L4 — El diff desaparece y manda la conversación: en vez de revisar cada diff, se observa el comportamiento del agente y uno se concentra en darle dirección
• [Era del IDE]
  • L3 — Modo YOLO: el agente se ejecuta libremente dentro del IDE, con mayor confianza
  • L2 — Agente dentro del IDE, aprobación manual de permisos: se autoriza personalmente cada cambio de archivo, con control totalmente manual
  • L1 — Sin IA: flujo de trabajo de desarrollo tradicional
• Según el marco de 8 etapas de uso de herramientas de IA que organizó Steve Yegge, la mayoría de los desarrolladores sigue estancada entre el nivel 3 y 4
• La capa de orquestación empieza a partir del nivel 6 y exige un conjunto de habilidades fundamentalmente distinto al que se desarrolla hasta el nivel 5
• Este contenido cubre los niveles 5 al 8

Los límites de un solo agente

• Sobrecarga de contexto: un único agente tiene un límite en la cantidad de información que puede contener, y una base de código grande supera fácilmente una sola ventana de contexto
• Falta de especialización: un agente que maneja la capa de datos, la API, la UI y las pruebas no pasa de ser un generalista; un agente dedicado solo a la capa de datos escribe mucho mejor código de base de datos
• Falta de coordinación: incluso si se agregan agentes auxiliares, no pueden comunicarse entre sí, compartir tareas ni resolver dependencias; cuantos más agentes se agregan sin primitivas de coordinación, más difícil se vuelve administrarlos
• Los subagentes resuelven los dos primeros problemas; los equipos de agentes resuelven los tres

Por qué multiagente

• Paralelismo (3x de rendimiento): agentes de frontend, backend y testing trabajan al mismo tiempo
• Especialización (contexto enfocado): cada agente solo conoce los archivos que le corresponden; un agente que solo conoce db.js escribe mejor código de base de datos que uno que trabaja con toda la base de código
• Aislamiento (ejecución segura): los Git worktrees le dan a cada agente un directorio de trabajo independiente, sin conflictos de merge
• Aprendizaje compuesto: el archivo AGENTS.md acumula patrones y precauciones entre sesiones, de modo que cada sesión mejora la siguiente
• Tres agentes enfocados rinden de forma consistentemente mejor que un solo agente generalista trabajando tres veces más tiempo

Patrón 1: subagentes — delegación enfocada

• Usar la herramienta Task para crear agentes hijos especializados desde el orquestador padre; es el patrón multiagente más simple y conviene probarlo primero
• Ejemplo concreto: si se le da a Claude Code el prompt “construye el gestor de marcadores Link Shelf con Express y SQLite”, el orquestador padre lo descompone en briefs para tres subagentes
  • Subagente de capa de datos: construye db.js y luego redacta el informe DATA.md
  • Subagente de lógica de negocio: construye validation.js y luego redacta el informe LOGIC.md
  • Subagente de rutas API: después de leer DATA.md y LOGIC.md, construye server.js
• Los dos primeros subagentes se ejecutan en paralelo e independientemente; el tercero empieza después de que se completen ambos informes; el padre administra manualmente el grafo de dependencias
• Límites de los subagentes: el padre debe administrar manualmente el grafo de dependencias, no hay mensajería peer-to-peer ni lista compartida de tareas entre agentes; si el control del alcance de archivos es laxo, pueden surgir conflictos
• El costo total es de alrededor de 220 mil tokens, en un nivel prácticamente neutro en costo

• Subagentes jerárquicos (equipos de equipos)

  • En vez de que el orquestador cree directamente 6 subagentes, crea 2 líderes de feature, y cada uno genera por su cuenta entre 2 y 3 especialistas
  • El orquestador padre solo administra dos agentes, manteniendo limpio el contexto; el líder de feature A recibe el brief “construir funcionalidad de búsqueda” y lo descompone por su cuenta
  • El principio es el mismo que en una organización real de ingeniería: un VP no asigna tareas directamente a cada ingeniero, sino que las canaliza a través de los tech leads

Patrón 2: Equipos de agentes — verdadero paralelismo

• Función experimental de Claude Code, activada con el comando export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• Arquitectura de 3 capas:
  • Líder del equipo (Team Lead): descomposición del trabajo, creación de la lista de tareas, integración de resultados
  • Lista de tareas compartida: seguimiento de estado (pending, in_progress, completed, blocked), dependencias y bloqueo de archivos
  • Compañeros de equipo (Teammates): instancias independientes de Claude Code, cada una con su propia ventana de contexto, ejecutándose en paneles divididos de tmux
• Los compañeros eligen tareas de forma autónoma desde la lista compartida y se comunican directamente mediante mensajería peer-to-peer sin pasar por el líder
• Cuando un compañero marca una tarea como completada, las tareas bloqueadas que dependían de ella se desbloquean automáticamente
• Se puede alternar la superposición visual de la lista de tareas con Ctrl+T

• Mecanismos clave de los equipos de agentes

  • Lista de tareas compartida: cuando un compañero del backend marca la API de búsqueda como completada, la tarea bloqueada de escribir pruebas cambia automáticamente a estado pending; el bloqueo de archivos evita ediciones simultáneas
  • Mensajería entre pares: el agente de backend transmite directamente al agente de frontend el contrato de la API — "GET /search?q= returns [{id,title,url}]"; evita que el líder se convierta en un cuello de botella de coordinación
  • Cuando un compañero queda inactivo, el líder recibe una notificación automática

• Recomendaciones clave para los equipos de agentes

  • 3 a 5 compañeros es el punto óptimo; el costo en tokens aumenta linealmente según el tamaño del equipo
  • Aprobación del plan: si un compañero redacta un plan antes de implementar, el líder puede revisarlo y aprobarlo o rechazarlo; detectar problemas de arquitectura antes de que exista el código es mucho más barato
  • Tres compañeros enfocados rinden de manera consistentemente superior a cinco compañeros dispersos

• Consejos de confiabilidad para los equipos de agentes

  • Barandales para bucles + etapa de reflexión: establecer un límite MAX_ITERATIONS=8 para todos los compañeros; antes de cada reintento, forzar el prompt de reflexión "¿Qué falló? ¿Qué cambio concreto podría corregirlo? ¿Estoy repitiendo el mismo enfoque?" → reduce drásticamente la aparición de agentes atascados
  • Compañero @reviewer dedicado: asignar Claude Opus 4.6 (solo lectura) como reviewer, usando únicamente herramientas de lint, pruebas y escaneo de seguridad, con activación automática en cada evento TaskCompleted; proporción de 1 reviewer por cada 3 a 4 builders; el líder siempre recibe solo código ya revisado

Patrón 3: Orquestación a escala

• Cuando se gestionan 5, 10, 20 o más agentes en múltiples repos y funcionalidades, se necesita una herramienta de orquestación dedicada
• Tier 1 — subagentes y equipos en proceso: subagentes y equipos de agentes de Claude Code; una sola sesión de terminal, sin herramientas adicionales; empieza aquí
• Tier 2 — orquestadores locales: ejecutan múltiples agentes en worktrees independientes, manteniendo paneles de control, revisión de diff y control de merge; óptimos para 3 a 10 agentes en codebases conocidas; Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents
• Tier 3 — agentes asíncronos en la nube: asignas tareas, cierras la laptop y esperas el PR; se ejecutan en VMs en la nube; Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, Codex Web by OpenAI
• Para 2026, la mayoría de los desarrolladores usará las tres capas: Tier 1 (trabajo interactivo), Tier 2 (sprints en paralelo), Tier 3 (procesamiento nocturno del backlog)

Herramientas destacadas

• Conductor by Melty Labs

  • La forma más rápida de empezar con orquestación multiagente en Mac; ejecuta múltiples agentes de Claude Code y Codex en paralelo, cada uno en un git worktree independiente
  • Ofrece un dashboard visual y una UI de revisión priorizada por diff; solo pagas el costo de la API (gratis); exclusivo para macOS (Apple Silicon e Intel)
  • Ideal cuando necesitas trabajar en paralelo en 3 a 8 features dentro del mismo repo con supervisión visual

• Claude Code Web

  • Accesible en claude.ai/code; completamente basado en navegador, sin necesidad de terminal; conectas un repo de GitHub, ingresas la descripción de la tarea → se ejecuta en una VM en la nube administrada por Anthropic
  • Admite dirección intermedia, creación automática de PR y acceso desde app de iOS
  • Teams (terminal) es trabajar junto con los agentes, mientras que Web (navegador) es delegar e irte

• GitHub Copilot Coding Agent

  • Se distingue del modo agente de Copilot en el IDE (sincrónico e interactivo); el Copilot Coding Agent de GitHub es completamente asíncrono
  • Asignas cualquier issue de GitHub a @copilot o lo inicias desde el panel Agents → genera un draft PR en un entorno de GitHub Actions
  • Ejecuta su propio bucle de revisión antes del etiquetado; también se puede acceder a agentes de terceros como Claude Code y Codex desde el mismo panel; puede activarse desde Slack, Jira, Linear y Azure Boards

• Jules by Google

  • Agente de codificación asíncrona en la nube de Google, basado en Gemini; conectas un repo de GitHub → descripción de la tarea → Jules genera un plan → tras la aprobación, se ejecuta en una VM en la nube → devuelve un PR con todo el proceso de razonamiento y logs de terminal
  • Ofrece changelog en audio, interrupción de tareas en curso y Jules Tools CLI para canalizar issues de GitHub directamente
  • Lee automáticamente el AGENTS.md del repo sin configuración adicional

• OpenAI Codex Web

  • Cada tarea se ejecuta en un contenedor sandbox independiente con el repo de GitHub precargado
  • Tiene un ecosistema de superficies que conecta Web, CLI (open source), app de macOS, extensión de IDE e integración con GitHub a una cuenta de ChatGPT
  • La función Verifiable Evidence devuelve citas de logs de terminal y salida de pruebas para cada tarea, lo que permite auditar el historial de ejecución

• Cursor Cloud Agents + Glass

  • Permite iniciar agentes desde web, app de escritorio, Slack, Linear, GitHub, API y PWA (instalando cursor.com/agents)
  • Glass: la nueva interfaz de Cursor, que convierte la gestión de agentes en la pantalla principal y deja el editor anterior como herramienta secundaria accesible cuando hace falta
  • Refleja el patrón en el que el control plane se convierte en la experiencia principal en todo el ecosistema, y el editor pasa a ser un instrumento más dentro de él

• Vibe Kanban

  • Resuelve la "brecha de doomscrolling" (espacios vacíos de 2 a 5 minutos mientras trabajan los agentes); creas tarjetas de tareas y, al arrastrarlas a "In Progress", se generan su worktree y rama correspondientes
  • Permite revisar diff dentro del tablero y enviar feedback a agentes en ejecución; soporta Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI y más; multiplataforma (Mac, Windows, Linux), gratis, BYOK

Consejos para escalar

• Enrutamiento multi-modelo

  • No todas las tareas necesitan el modelo más caro; crea un archivo MODEL_ROUTING.md para definir el enrutamiento por rol:
    • Planificación·arquitectura → modelos económicos de Gemini/Claude/OpenAI
    • Implementación → Sonnet, Opus o Codex
    • Revisión → modelos de seguridad dedicados

• Scripts de ciclo de vida de worktree

  • Automatiza el trabajo repetitivo con tres alias de shell:
    • agent-spin <feature>: crea worktree + rama + inicia el agente
    • agent-merge <feature>: rebase + revisión + crea PR
    • agent-clean: elimina los worktrees terminados
  • Unas 12 líneas de bash; Conductor lo gestiona visualmente

• Permitir solo AGENTS.md escritos por humanos

  • Un estudio de ETH Zurich de Gloaguen et al. confirmó que los archivos AGENTS.md generados por LLM no aportan beneficios, y provocan una caída promedio de ~3% en la tasa de éxito, además de aumentar en más de 20% el costo de inferencia
  • Los archivos de contexto escritos por desarrolladores ofrecen una mejora de rendimiento de ~4%
  • Nunca permitas que un agente escriba directamente en AGENTS.md; el líder debe aprobar cada línea
  • Mantenlo conciso con secciones claras: STYLE, GOTCHAS, ARCH_DECISIONS, TEST_STRATEGY

Puertas de calidad: confía, pero verifica

• Tres puertas de calidad

  • Aprobación del plan: un miembro del equipo redacta el plan antes de empezar a programar → el líder lo revisa y lo aprueba o rechaza → implementación; corregir un mal plan cuesta muchísimo menos que corregir mal código
  • Hooks: verificaciones automatizadas en eventos del ciclo de vida; el hook TeammateIdle comprueba que todas las pruebas pasen antes de que el agente deje de trabajar; el hook TaskCompleted ejecuta lint y pruebas antes de marcar la tarea como terminada; si un hook falla, el agente sigue trabajando hasta aprobar
  • Aprendizaje compuesto mediante AGENTS.md: captura patrones descubiertos, precauciones y preferencias de estilo; todos los agentes lo leen al iniciar la sesión y se amplía en cada sesión

• El cuello de botella se mueve a la verificación

  • Los agentes pueden generar resultados impresionantes a una velocidad asombrosa; la parte difícil es tener certeza de que esos resultados sean correctos
  • Que las pruebas pasen antes del cambio no garantiza que detecten regresiones causadas por el cambio
  • Los agentes pueden escribir pruebas técnicamente válidas, pero que omiten casos importantes
  • Debido a los límites de la ventana de contexto, los agentes que trabajan en codebases grandes pueden pasar por alto restricciones importantes fuera de su vista actual
  • Un entorno inestable que para un desarrollador individual es un caso molesto de borde se convierte en un bloqueador sistémico cuando 40 agentes enfrentan al mismo tiempo esa misma prueba inestable
  • Hasta que la infraestructura de verificación alcance la capacidad de generación, la revisión humana no es un costo adicional opcional sino un sistema de seguridad

Ralph Loop y agentes que se mejoran a sí mismos

• Patrón Ralph Loop

  • Popularizado por Geoffrey Huntley y Ryan Carson; es el patrón detrás de “entregar mientras duermes”; la herramienta independiente de Carson ralph (snarktank/ralph) implementa el bucle central, mientras que el proyecto Antfarm añade orquestación multiagente sobre OpenClaw
  • Ciclo de 5 pasos: Pick(selecciona la siguiente tarea en tasks.json) → Implement(realiza los cambios) → Validate(ejecuta pruebas·tipos·lint) → Commit(hace commit y actualiza el estado de la tarea si las verificaciones pasan) → Reset(reinicia el contexto del agente y pasa a la siguiente tarea)
  • Idea clave: al reiniciar en cada iteración, se evita la acumulación de confusión; las tareas pequeñas y de alcance claro producen menos alucinaciones y código más limpio que un único prompt gigantesco
  • Protecciones: pasar errores como retroalimentación para reintentos automáticos, pero detener y reasignar si se atasca más de 3 veces; trabajar siempre en ramas de feature; fijar límites de iteración, tiempo y tokens; el agente crea el PR → revisión humana antes del merge
  • Mantén 4 canales de memoria entre reinicios de contexto: historial de commits de git, registro de progreso, archivo de estado de tareas (tasks.json) y AGENTS.md como memoria semántica de largo plazo

• Hacer que los agentes sean más inteligentes con el tiempo

  • Autorreflexión con REFLECTION.md: después de cada tarea, obligar a escribir “qué fue sorprendente, un patrón para agregar a AGENTS.md y una mejora al prompt”; el líder revisa y fusiona los aprendizajes aprobados
  • Presupuesto de tokens y criterios de terminación: establecer límites por agente (por ejemplo, frontend 180 mil tokens, backend 280 mil tokens); pausa automática al 85% del presupuesto y aviso al líder; si se atasca más de 3 veces en el mismo error, se detiene y se reasigna a un agente nuevo
  • Beads / memoria persistente: el patrón “beads” de Gastown — un registro inmutable, basado en git, de todas las decisiones y resultados con procedencia completa; los agentes consultan beads anteriores mediante un grafo de tareas y un data plane direccionable por SQL; no es un RAG vectorial simple, sino memoria institucional estructurada y consultable

La disciplina que hace funcionar todo esto

• El cuello de botella humano no era un bug, sino una feature

  • Cuando escribes código a velocidad humana, sientes el dolor temprano; fallan pruebas, llegan observaciones en code review, descubres duplicación — el dolor es inmediato, así que corriges sobre la marcha
  • En una tropa de agentes orquestados no existe ese cuello de botella natural; errores pequeños (mal olor de código, duplicación, abstracciones innecesarias) se amplifican en cadena a una velocidad imposible de alcanzar
  • Como estás fuera del loop, no sientes el dolor hasta que la arquitectura ya no permite nuevas funciones
  • Por eso existen todas las puertas de calidad (aprobación del plan, hooks, presupuesto de tokens, revisión humana): sin ellas, la programación con agentes te lleva a un callejón sin salida

• Delega tareas, pero conserva el juicio

  • Qué sí delegar a los agentes: tareas bien delimitadas con criterios claros de aprobación/rechazo, boilerplate, migraciones, scaffolding de pruebas, explorar enfoques que no tendrías tiempo de probar directamente
  • Qué debes conservar tú: arquitectura y diseño de API (los agentes han aprendido mucha mala arquitectura de los datos de entrenamiento y pueden aplicar patrones enterprise tal cual a una startup), decidir qué no construir (decir No es una capacidad que los agentes no tienen), revisar la salida de los agentes con el contexto de todo el sistema
  • Si pierdes el entendimiento de tu propio sistema, pierdes la capacidad de corregirlo, extenderlo y detectar cuando falla

• La especificación es apalancamiento

  • Cuando orquestas 50 agentes en paralelo, el pensamiento ambiguo no solo ralentiza, sino que se amplifica en decenas de ejecuciones paralelas
  • La diferencia entre un resultado mediocre y uno sobresaliente depende casi por completo de la calidad de la especificación
  • Una especificación ambigua amplifica errores en toda la flota; una especificación precisa con arquitectura clara, límites de integración, casos de borde e invariantes se amplifica en implementaciones precisas en todo el sistema
  • El trabajo mecánico de tipear código se está automatizando; el trabajo cognitivo de entender el sistema se amplifica a través de toda una flota de trabajadores autónomos

El modelo de fábrica

• Ya no se trata solo de escribir código, sino de construir una fábrica que produce software
• Línea de producción de 6 pasos: Plan(redactar especificaciones con criterios de aceptación) → Spawn(crear el equipo y asignar agentes) → Monitor(revisar el progreso cada 5~10 minutos y resolver bloqueos, sin estar encima) → Verify(ejecutar pruebas y revisar código; la verificación es el cuello de botella) → Integrate(fusionar ramas y resolver conflictos) → Retro(actualizar AGENTS.md con nuevos patrones; aprendizaje compuesto)
• Consejos prácticos:
  • Define un límite de WIP: no ejecutes más agentes de los que realmente puedes revisar con sentido; el punto óptimo es 3~5
  • Define criterios de terminación: si se atasca más de 3 veces en el mismo error, detén y reasigna
  • Check-ins asíncronos: revisa el progreso cada 5~10 minutos; deja que los agentes trabajen con autonomía
  • Un dueño por archivo: evita que dos agentes editen el mismo archivo; los conflictos destruyen la velocidad

5 patrones para empezar hoy

1. Descomponer en subagentes: crea agentes hijos enfocados con briefs específicos y propiedad de archivos usando la herramienta Task; no requiere configuración; empieza hoy mismo
2. Paralelismo con equipos de agentes: activa CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1; crea un líder + 3 miembros del equipo; coordina con una lista de tareas compartida
3. Aislamiento con Git worktree: dale a cada agente su propio worktree; sin conflictos de fusión; Conductor lo maneja automáticamente
4. Puertas de calidad para generar confianza: exige aprobación del plan para cambios riesgosos; agrega hooks que ejecuten pruebas al completar tareas; no confíes en la salida del agente sin validación
5. Aprendizaje compuesto con AGENTS.md: documenta patrones, advertencias y preferencias de estilo; se lee y actualiza en cada sesión; el conocimiento se amplifica de forma compuesta

[kurthong]

No sé si es una característica de los ingenieros, pero no entiendo por qué se extienden tanto con discursos que suenan plausibles pero sin profundidad. A mí también me interesaba el tema, así que lo leí con detalle, pero no tiene sustancia.

[stroke33]

La razón definitiva para usar hardcore clco: con multiagentes, armar mi propia orquestación

Ahora mismo estoy operando 5 agentes, pero los tokens se me van rapidísimo y dan ganas de llorar.