Divides una tarea grande en cinco tarjetas kanban, cinco agentes empiezan a trabajar en paralelo y todos entregan a tiempo. Luego lo fusionas todo y te das cuenta del problema: dos workers inventaron por su cuenta respuestas distintas a la misma pregunta de diseño, un archivo fue remezclado por tres tarjetas a la vez y nadie revisó nada — porque «revisar» nunca formó parte del bucle. Es la parte más dolorosa de la colaboración multiagente, y es exactamente lo que arregla un grupo de PRs fusionados el 10 de agosto de 2026 (#83412, #83423, #83424, #83428): Hermes kanban ahora tiene un ciclo de revisión de primera clase, más tres salvaguardas contra el caos. Aquí tienes todo el flujo — desde entregar el trabajo a revisión hasta que te lo devuelven — y las convenciones que mantienen honestos a los agentes en paralelo.

El bucle de revisión: implementador → review lane → veredicto

Las tarjetas kanban ahora tienen una fase de revisión de verdad. Cuando un implementador termina, entrega el trabajo mediante kanban_request_review:

kanban_request_review(
  task_id="T-42",
  summary="Implemented the export feature; verified with 3 sample files",
  reviewer="code-reviewer"    # optional
)

summary es obligatorio — le dice al revisor qué se ha construido y cómo se ha verificado; reviewer es opcional; el contenido enviado se redacta automáticamente. La tarjeta pasa al review lane, donde un perfil de revisor la recoge y la skill sdlc-review se carga automáticamente. El revisor emite uno de tres veredictos:

Veredicto	Acción	Significado
Aprobar	kanban_complete	Se cumplen los criterios de aceptación, la tarea se cierra
Solicitar cambios	kanban_comment + kanban_request_changes(reason=...)	Quedan defectos corregibles; la tarjeta vuelve al implementador original
Escalar	kanban_block	Se necesita una decisión humana o un requisito externo

La procedencia se conserva: si el implementador corrige la tarjeta y vuelve a solicitar la revisión sin nombrar a un revisor, se enruta de nuevo al mismo perfil de revisor — sin reasignaciones aleatorias, con contexto de revisión continuo.

Lentes de revisión rotatorias: ronda 1 lectura en frío, ronda 2 ejecútalo, ronda 3 audita el contrato

La skill sdlc-review tiene un diseño ingenioso: cada ronda examina el trabajo con una lente distinta en lugar de repetir la misma inspección. El número de ronda es el número de intentos previos de changes_requested más uno (ronda 1 = cero devoluciones, ronda 2 = una, y así sucesivamente):

• Ronda 1 — Artefacto: lee el diff o el entregable en frío, antes del resumen del implementador; forma un juicio independiente, compáralo después con la narrativa de entrega e investiga cada discrepancia;
• Ronda 2 — Ejecución: descarga el trabajo y ejecútalo de verdad mediante terminal — compila, prueba y ejercita el comportamiento descrito tú mismo en lugar de volver a leer el artefacto;
• Ronda 3+ — Contrato: vuelve a leer el cuerpo de la tarea original de la tarjeta y sus criterios de aceptación, audita el entregable estrictamente contra ellos y verifica que cada punto de cada ronda anterior de request_changes se haya incorporado de verdad.

El mismo principio se aplica cuando despliegas revisores paralelos ad-hoc mediante delegate_task: da a cada revisor un brief distinto (uno solo con el diff, otro con el contexto completo, otro de checkout-and-run) en lugar de briefs idénticos. Los briefs idénticos producen veredictos correlacionados y hallazgos duplicados; las lentes variadas cubren más clases de defectos por el mismo coste de revisión.

Salvaguarda 1: propiedad de las decisiones — un propietario por pregunta

El modo de fallo clásico de los multiagentes es el «split brain»: dos workers resuelven por su cuenta la misma pregunta de diseño con respuestas distintas. Un nuevo contrato de propiedad de decisiones en KANBAN_GUIDANCE bloquea ese camino directamente:

• Las decisiones de diseño pertenecen al orchestrator y se toman antes del fan-out;
• Ninguna pareja de tarjetas de un mismo subárbol puede decidir la misma cuestión;
• El cuerpo de cada tarjeta hija debe contener las decisiones de las que depende — porque los workers no pueden ver el contexto de sus hermanas.

El ejemplo de la documentación lo dice perfectamente: una tarjeta exportadora y una tarjeta importadora no deben «inventarse» cada una el formato de archivo. El orchestrator elige el formato primero y lo plasma en los cuerpos de ambas tarjetas, de modo que los dos workers escriben contra el mismo contrato y nada choca en el momento del merge.

Salvaguarda 2: hotspots de colisión — marca, no te amontones

Las ediciones paralelas del mismo archivo chocan; la nueva convención lo gestiona por adelantado. Cuando un worker nota que el archivo que va a tocar sigue atrayendo conflictos de las tarjetas hermanas, deja un kanban_comment que empieza por hotspot: (p. ej. hotspot: src/config.py — three cards are editing this file) y lo expone en los metadatos de finalización. Un orchestrator que ve 2+ marcas en una misma ruta crea una tarjeta de descomposición — sacando ese archivo caliente de la cola antes de despachar más trabajo que lo toque. Para los conflictos que ya han ocurrido, arbitra el merge-reconciler.

La conclusión

En conjunto, estos cambios convierten kanban de «despachar trabajo, recoger resultados» en un bucle de desarrollo completo: revisión, perspectivas rotatorias, propiedad de las decisiones y aviso temprano de conflictos. El punto dulce es obvio — repositorios donde varios agentes trabajan en paralelo y la calidad necesita un control; un único agente haciendo tareas pequeñas no necesita un flujo de trabajo tan pesado. Para la superficie completa de comandos de kanban, consulta la referencia de comandos de hermes-kanban; para más convenciones en entornos multiagente, también escribimos sobre la cadena de directorios de AGENTS.md.