Gestionar dependencias entre agentes en un orquestador
Cuando varias tareas dependen entre sí, ¿cómo sabe el agente en qué orden ejecutarlas? Estrategias para definir dependencias explícitas en el orquestador y evitar que el agente las deduzca.
El problema de las dependencias implícitas
Cuando un orquestador lanza varios agentes en paralelo para acelerar el trabajo, la pregunta más importante no es cuántos agentes lanzar — es en qué orden deben ejecutarse las tareas. Si dos agentes trabajan sobre recursos interdependientes sin conocer esa relación, los resultados son impredecibles.
Los conflictos más comunes: dos agentes modifican el mismo archivo y el último en escribir sobreescribe el trabajo del primero; un agente espera un output que el otro todavía no ha generado y opera sobre datos incompletos; las ramas de git creadas por cada agente entran en conflicto al abrir sus respectivas PRs. Todos estos problemas tienen la misma causa raíz: las dependencias no estaban definidas explícitamente.
Las dependencias implícitas no desaparecen porque no se documenten. Solo cambian de lugar: de ser un problema de diseño del orquestador, a ser un problema de debugging de producción.
Tipos de dependencias entre tareas
No todas las dependencias son del mismo tipo. Identificar el tipo correcto permite saber si hay que serializar la ejecución, coordinar el acceso a archivos o simplemente definir un contrato antes de que los agentes empiecen:
Dependencia de datos
La tarea B necesita un output generado por la tarea A para poder ejecutarse. La tarea A debe completarse primero.
Ejemplo: Generar el schema de base de datos (A) antes de implementar los endpoints que lo usan (B)
Dependencia de archivo
Las tareas A y B modifican el mismo archivo. Ejecutarlas en paralelo genera conflictos de escritura.
Ejemplo: Dos agentes que modifican el mismo archivo de rutas o el mismo schema de tipos
Dependencia de contrato
La tarea B implementa un endpoint o función que la tarea A consume. El contrato debe estar definido antes.
Ejemplo: El endpoint de autenticación (A) debe estar definido antes de que el módulo de usuarios (B) pueda llamarlo
Cómo definir dependencias en el orquestador
El orquestador debe mantener una lista de tareas con sus dependencias explícitas. Antes de lanzar cualquier subagente, construye el grafo de dependencias y ejecuta las tareas en orden topológico — primero las que no tienen dependencias, luego las que dependen de las completadas, y así sucesivamente.
// orchestrator-tasks.json — definición de tareas con dependencias explícitas
{
"sprint": "MAR-650",
"tasks": [
{
"id": "task-001",
"title": "Definir schema de base de datos",
"depends_on": [],
"agent": "backend-agent",
"ticket": "MAR-651"
},
{
"id": "task-002",
"title": "Implementar endpoints de producto",
"depends_on": ["task-001"],
"agent": "backend-agent",
"ticket": "MAR-652"
},
{
"id": "task-003",
"title": "Implementar tests de integración",
"depends_on": ["task-001", "task-002"],
"agent": "testing-agent",
"ticket": "MAR-653"
},
{
"id": "task-004",
"title": "Actualizar documentación de API",
"depends_on": ["task-002"],
"agent": "docs-agent",
"ticket": "MAR-654"
}
]
}Con este grafo, el orquestador puede ejecutar task-001 primero, luego task-002 y task-004 en paralelo (cuando task-001 termine), y finalmente task-003. El agente no necesita deducir nada — el orden está definido.
Anti-patrón: dejar que el agente deduzca el orden
Si el orquestador no define las dependencias, el agente intenta deducir el orden correcto leyendo el código del repositorio. Esto funciona a veces — los modelos son capaces de inferir dependencias de código — pero introduce problemas sistemáticos:
Patrón recomendado: dependencias explícitas en el ticket
La forma más robusta de gestionar dependencias en un sistema agéntico es definirlas en el propio ticket. Añadir un campo depends_on en los tickets de Jira o Linear hace que el orquestador pueda leer el grafo directamente del gestor de proyectos, sin necesidad de un archivo de configuración separado.
Añadir campo depends_on en el ticket
Lista de IDs de tickets que deben completarse antes. El orquestador lo lee antes de lanzar los subagentes.
Incluir la dependencia en los criterios de aceptación
Por ejemplo: "DADO QUE task-001 ha completado el schema, CUANDO se implementen los endpoints, ENTONCES deben usar los tipos definidos en el schema".
El orquestador construye el grafo antes de lanzar
Consulta la API del gestor de proyectos, construye el DAG de tareas y ejecuta en orden topológico. Ningún subagente se lanza sin que sus dependencias estén completas.
La regla de oro: si el orden de ejecución importa, documentarlo explícitamente. El agente puede ser muy inteligente, pero no tiene acceso al conocimiento implícito del equipo sobre qué depende de qué. Esa información debe estar en el sistema, no en la cabeza de las personas.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.