Imagina un solo con todas las herramientas y la tarea "implementa esto, revísalo y asegúrate de que pasen los tests". Aparecen cuatro problemas. El agente que escribió el código decide si el código es bueno, como un estudiante que corrige su propio examen. Para cuando llega la revisión, su memoria de la tarea está llena de intentos fallidos. Conserva acceso total de escritura incluso mientras "revisa". Y cuando el resultado es malo, nadie puede saber si falló la planificación, la construcción o la verificación.
Un reparte ese trabajo entre varios agentes, cada uno con su propio rol, instrucciones, herramientas y a menudo modelo. Bien hecho, resuelve los cuatro problemas; mal hecho, multiplica el costo sin mejorar nada. Esta lección cubre cómo dividir el trabajo en roles, por qué los límites de cada rol deben estar construidos en el sistema y no escritos en sus instrucciones, cómo verificar el trabajo con controles que el modelo no puede discutir y cuándo conviene un solo agente.
Dividir por rol
Un equipo de agentes necesita dos decisiones: qué roles existen y cómo pasa el trabajo entre ellos. Cada paso de un agente al siguiente es un (traspaso). El diagrama muestra las disposiciones comunes: un pipeline, donde cada agente pasa al siguiente y un revisor puede devolver el trabajo; un líder que reparte el trabajo; y agentes en paralelo cuyos resultados se combinan.
- Pipelinecada agente pasa al siguiente
- A, luego B, luego C
- Un revisor puede devolver el trabajo
- Líder y trabajadoresun agente reparte el trabajo
- El líder decide quién hace qué
- Los trabajadores le reportan
- Paralelovarios agentes a la vez
- Una tarea dividida en partes
- Resultados combinados al final
Un pipeline es fácil de seguir y de reanudar tras una caída. Un líder que decide sobre la marcha es flexible, pero más difícil de testear y de acotar en costo. Los agentes en paralelo ahorran tiempo solo si sus tareas son de verdad independientes, por ejemplo si no editan los mismos archivos.
Para trabajo de código, los roles clásicos se ven así. La última columna es la que más importa:
| Rol | Hace | No debería poder |
|---|---|---|
| Lead | planifica y reparte el trabajo | editar código |
| Implementer | escribe el cambio | aprobar su propio trabajo |
| Reviewer | lee el cambio, pide correcciones | escribir ni ejecutar nada |
| Tester | corre los tests, informa si pasan o fallan | editar archivos |
Límites construidos, no escritos
Decirle al Reviewer "eres de solo lectura" no lo vuelve de solo lectura. El modelo es justo lo que intentas controlar; no puede ser también el control. La forma confiable es no darle nunca la herramienta a ese rol: si el Reviewer no tiene una herramienta para escribir, ningún texto puede convencerlo de escribir.
| Prohibición escrita | Prohibición construida |
|---|---|
| instrucción: "no escribas archivos" | la herramienta de escritura no está en su lista |
| el modelo ve la herramienta | el modelo nunca la ve |
| un texto persuasivo puede convencerlo | no hay nada que convencer |
| una violación puede pasar inadvertida | un intento queda en el registro como herramienta desconocida |
Los handoffs merecen el mismo cuidado. Pegar toda la salida de un agente en las instrucciones del siguiente crece sin fin y mezcla ruido con señal. docket pasa en cambio un resumen corto y estructurado, con un de tamaño (ver Contexto, routing y costo), y toma la lista de archivos cambiados de git, no del modelo (DOCKET Architecture). Si un dato se puede leer del mundo real, no se lo pidas al modelo.
Controles que el modelo no puede discutir
El Implementer dice "listo, los tests pasan". ¿Cómo lo sabes? Con un gate (control de paso): una condición que se verifica fuera del modelo antes de que el trabajo avance. Hay tres tipos útiles:
- Decide un comando. Después del cambio, el sistema corre la verificación del propio proyecto, como su suite de tests. Si falla, la tarea falla, diga lo que diga el agente.
- Un veredicto con formato estricto. El Reviewer debe responder aprobando o pidiendo cambios de forma explícita, y el Tester, con pasa o falla. Una respuesta que el sistema no puede leer con claridad cuenta como falla, nunca como éxito.
- Aprueba una persona. Un operador debe dar el visto bueno antes de que el paso siga.
En docket
- Leadplanifica; nunca edita código
- Implementerescribe el cambio
- Control: el comando de verificación del proyecto
- Reviewerlee el cambio, da un veredicto
- Control: aprobar o pedir cambios
- Testercorre los tests, da un veredicto
- Control: pasa o falla, sin segundo intento
"pedir cambios" devuelve la tarea al Implementer, una vez por defecto
Ese límite importa: sin un tope, un Reviewer exigente y un Implementer incapaz dan vueltas, y gastan, para siempre. Y donde un comando pueda decidir, deja que decida; reserva la verificación con modelos para lo que ningún comando puede comprobar.
Eso es la verificación independiente: quien verifica no produjo el trabajo, no comparte su contexto y no tiene sus herramientas. Un Reviewer que puede escribir tiende a "arreglar" en lugar de pedir cambios, y entonces nadie revisa lo que escribió. Además lee el cambio, que puede contener texto hostil, y lo que ese texto logre depende por completo de las herramientas que tenga el Reviewer.
Cuándo es mejor un solo agente
Cada agente extra suma llamadas al modelo, tiempo de espera, un handoff que pierde algo de información y una cosa más que puede fallar. "Suena más avanzado" no es una razón.
| Beneficio | Costo |
|---|---|
| revisión independiente | más llamadas, más espera |
| cada rol recibe solo el acceso que necesita | roles mal diseñados bloquean trabajo legítimo |
| contexto enfocado | información perdida en cada handoff |
| fallas más fáciles de ubicar | más estados y más código de coordinación |
| controles que el modelo no puede saltarse | los modelos pequeños suelen fallar el formato del veredicto |
El README de docket apunta en la misma dirección: comienza solo con un Lead y un Implementer, y suma un Reviewer o un Tester únicamente cuando haya un control puntual para el que los necesites.
Otra frontera: la tarea misma
Esa es otra forma válida de dividir el trabajo: el tablero decide qué trabajo existe y en qué orden, y el agente decide cómo se hace.
En Tack
- Ítem del tableroqué hacer y en qué orden
- Run with agentel ítem cruza la línea
- Agente de códigodecide cómo, sus ayudantes incluidos
- Registro en el ítemel intento, sus eventos, sus resultados
En la práctica
- Exige una razón concreta para cada rol extra: un control que hoy falla, o un acceso que hoy es demasiado amplio.
- Pon los límites de cada rol en el sistema, no en las instrucciones. Revisa qué herramientas puede alcanzar de verdad cada rol.
- Prefiere un comando a la opinión de un modelo como control de paso, siempre que un comando pueda decidir.
- Decide dónde va la línea: coordinar roles dentro de tu propio sistema, o entregar tareas completas a un agente externo que observas desde el borde.
Para profundizar
La documentación de docket y de Tack profundiza en ambas formas de dividir el trabajo (en inglés):
- Agent Teams (Pods) es la guía central de docket: los roles y qué puede editar cada uno, cómo el pipeline corre un turno real de agente por paso y los controles entre pasos.
- Workflow guide sigue a un pod desde su creación hasta un cambio confirmado en git, y muestra pipelines a medida con pasos en paralelo, retrabajo acotado y la aprobación de una persona.
- Agent Runners & Fleet Execution explica cómo Tack le entrega un ítem a un agente de código, qué puede y qué no puede prometer cada agente soportado y qué funciona de punta a punta hoy.
Para llevar
- Dividir el trabajo en roles ataca la autocorrección, el contexto saturado y el exceso de acceso, a cambio de costo y coordinación.
- Los límites de un rol se imponen quitando herramientas, no con instrucciones que el modelo puede ignorar.
- Los handoffs deben ser resúmenes cortos y estructurados, llenados con datos reales cuando se pueda.
- Los controles verificados fuera del modelo, con las respuestas ambiguas contadas como fallas, hacen visible el trabajo malo.
- Empieza con el sistema mínimo y agrega roles solo cuando una necesidad medida lo pida.
Comprueba lo aprendido
¿Por qué quitarle al Reviewer la herramienta de escritura es más fuerte que prohibirle escribir en sus instrucciones?
El modelo nunca ve la herramienta, así que ningún texto puede persuadirlo de usarla, y cualquier intento aparece como herramienta desconocida. Una instrucción solo funciona si el modelo decide obedecerla.
La respuesta de un Reviewer contiene "aprobar" y también "pedir cambios". ¿Qué debería hacer el sistema y por qué?
Tratarla como ilegible y bloquear el avance, igual que un rechazo. Contar una respuesta ambigua como éxito dejaría pasar trabajo malo cada vez que el modelo se confunde.
¿Cuándo conviene un solo agente?
Cuando ningún control concreto ni ninguna frontera de acceso justifica otro rol, o cuando las subtareas comparten mucho contexto y dependen unas de otras. En esos casos, más agentes suman costo y handoffs con pérdida sin mejorar el resultado.