Sistemas multi-agente

Imaginemos un único agenteAgente Sistema en el que un modelo, dentro de un bucle, elige la siguiente acción hasta decidir que terminó o alcanzar una condición de parada. con todas las herramientas y la tarea "implementa X, revisa que esté bien y verifica que los tests pasen". Aparecen cuatro problemas: el mismo agente que escribió el código decide si está bien (conflicto de intereses); cuando llega a revisar, su contexto está lleno de intentos fallidos (contexto contaminado); tiene permiso de escritura incluso mientras "revisa" (privilegio máximo todo el tiempo); y si el resultado es malo no sabemos si falló la planificación, la implementación o la verificación (fallas opacas).

Un sistema multi-agenteSistema multi-agente Varios agentes con roles, herramientas y a veces modelos distintos, coordinados mediante handoffs. reparte ese trabajo entre roles. Bien hecho, resuelve esos cuatro problemas. Mal hecho, multiplica el costo y agrega puntos de falla sin mejorar nada. Veamos cómo distinguir un caso del otro.

Dividir por rol

Pipeline              Orquestador-worker        Paralela
A ──► B ──► C             Orquestador           ┌─► B ─┐
                        ┌─────┼─────┐         A ┼─► C ─┼─► E
Con rework              ▼     ▼     ▼           └─► D ─┘
A ──► B ──► R ──► T     B     C     D
      ▲     │
      └─────┘

La elección no es estética. Un pipeline es fácil de razonar, trazar y reanudar tras un fallo. Un orquestador dinámico es flexible, pero más difícil de acotar en costo y de testear. El paralelismo reduce latencia solo si las subtareas son de verdad independientes (no escriben los mismos archivos).

Los roles clásicos para trabajo de código:

El pod de docket

Lo central es cómo se hace cumplir cada rol. La plantilla del Reviewer dice "read-only", pero eso no es lo que lo hace read-only.

Handoffs tipados

Concatenar toda la salida de un agente en el prompt del siguiente crece sin límite y mezcla ruido con señal. docket pasa un HandoffArtifact (src/docket/core/handoff.py), un modelo Pydantic que rechaza campos extra, con summary, files_changed, diff_ref y verdict. files_changed no lo declara el modelo: sale de git. Si un dato se puede obtener del mundo real, no se le pregunta al modelo. Cada rol tiene además un presupuestoPresupuesto Límite duro sobre tokens, llamadas, tiempo o dinero, aplicado antes de gastar el recurso. de tokensToken Unidad de subpalabra con la que el modelo lee, escribe y cobra. para el handoff (token_budget en archetypes.py) y los campos se descartan en un orden fijo (DROP_ORDER) cuando no caben; el detalle está en Contexto, routing y costo.

Gates que el modelo no puede convencer

Un Implementer dice "listo, los tests pasan". ¿Cómo lo sabemos? Con un gate: una condición evaluada fuera del modelo.

Tres reglas generales salen de aquí:

• Una salida ambigua es un fallo, no un éxito.
• Los ciclos de corrección necesitan techo, o un Reviewer exigente y un Implementer incapaz iteran (y gastan) sin fin.
• Prefiere evidencia mecánica a juicio del modelo. Si un comando puede decidir, que decida el comando; un Tester con modelo es para lo que un comando no puede verificar.

La verificación independiente significa que quien verifica no es quien produjo, no comparte su contexto y no tiene sus herramientas. Un Reviewer que puede escribir tiende a "arreglar" en vez de pedir cambios, y entonces nadie revisa lo que escribió. Además lee el diff, que puede contener texto hostil: lo que ese texto logre depende enteramente de las herramientas del Reviewer.

Cuándo un solo agente es mejor

Cada agente adicional agrega llamadas al modelo, latencia, un handoff donde se pierde información y un punto de falla. "Suena más avanzado" no es una razón.

La recomendación del README de docket coincide con la literatura seria: empieza con el pod mínimo y agrega Reviewer o Tester cuando un gate de calidad concreto justifique los turnos extra.

Tack: el equipo como frontera

Es otra forma legítima de dividir: el tablero decide qué trabajo existe y en qué orden; el harness decide cómo se hace. La frontera del "equipo" es el ítem.

Para CTOs

• Exige una razón concreta para cada rol adicional: un gate que hoy falla o un privilegio que hoy sobra.
• Verifica que los límites de rol estén en el código (registry, sandboxSandbox Frontera de aislamiento con un modelo de amenazas explícito sobre archivos, procesos, red, credenciales y kernel.), no en el prompt.
• Pide un verifyCmd o equivalente mecánico antes de aceptar cualquier gate basado en la opinión de un modelo.
• Decide dónde vive la frontera: orquestación dentro de tu runtime o delegación a un harness externo que trazas desde fuera.

Para llevar

• Multi-agente resuelve conflicto de intereses, contexto contaminado y privilegio excesivo, a cambio de costo y coordinación.
• Los roles se hacen cumplir quitando herramientas del registry, no con instrucciones en el prompt.
• Los handoffs deben ser estructuras tipadas, con datos obtenidos del mundo real cuando sea posible.
• Los gates mecánicos y los veredictos estrictamente parseados convierten una mala respuesta en una falla visible.
• Empieza con el sistema mínimo y agrega roles solo cuando una necesidad medida lo pida.

Comprueba lo aprendido