Cinco agentes no forman un equipo: construir un harness de producto con Hermes

Montar cinco agentes es fácil. Conseguir que construyan el mismo producto sin pisarse, inventarse el alcance ni revisar su propio trabajo es otra cosa.

Después de construir varios productos con Hermes, he terminado utilizando una estructura que se parece menos a «hablar con una IA» y más a montar un pequeño equipo de producto. Lo llamo harness especializado en un producto: perfiles con responsabilidades explícitas, modelos elegidos según el trabajo, reglas compartidas, un orquestador y un tablero Kanban que conserva el estado entre sesiones.

Añadir agentes aumenta la capacidad de producir trabajo, pero también puede multiplicar el ruido, las contradicciones y los cambios fuera de alcance. Un harness robusto convierte una idea en tareas verificables y evita que cada agente improvise su propia versión del producto.

Empezar por la idea, no por los perfiles

El punto de partida puede ser poco más que una intención: un videojuego web, un plugin financiero, una herramienta interna o un servicio todavía sin especificar. Antes de decidir cuántos agentes hacen falta, conviene explicar a Hermes qué producto queremos construir, qué sabemos ya y qué decisiones no están tomadas.

Yo incluiría, como mínimo:

• el problema o la oportunidad;
• las capacidades visibles que imaginamos;
• el stack existente, si lo hay;
• el repositorio y sus fuentes de verdad;
• los límites de alcance conocidos;
• el nivel de riesgo del dominio;
• las fases que van desde ideación hasta release;
• la forma en la que queremos revisar y aceptar el trabajo.

Con ese contexto, podemos pedir a Hermes que proponga el roster. El prompt no debería limitarse a «crea varios agentes». Tiene que pedir responsabilidades que no se solapen, criterios para elegir modelo y esfuerzo de razonamiento, mecanismos de coordinación y una verificación final.

Este es un punto de partida reutilizable:

Quiero construir un harness permanente de desarrollo para <producto>.

Contexto del producto:
- Problema y usuarios: <descripción>
- Repositorio: <ruta o URL>
- Stack actual: <tecnologías>
- Fuentes de verdad: <README, roadmap, ADRs, especificaciones>
- Restricciones: <límites de alcance, seguridad, privacidad, plataforma>
- Flujo esperado: ideación, investigación, diseño, implementación,
  pruebas, revisión independiente, documentación y release.

Analiza el producto y propón una serie de perfiles Hermes especializados.
Para cada perfil define:
- nombre estable;
- misión y límites;
- tareas que puede aceptar y tareas que debe rechazar;
- entradas necesarias y artefactos de salida;
- skills y herramientas mínimas;
- modelo y esfuerzo de razonamiento recomendados, justificando coste
  frente a complejidad;
- relación con el resto de perfiles.

Incluye siempre un perfil orquestador del producto. Debe utilizar un modelo
más capaz y un esfuerzo de razonamiento mayor que los trabajadores, mantener
la visión global, descomponer iniciativas, crear dependencias en Kanban,
asignar por especialidad y comprobar la evidencia antes de cerrar. No debe
implementar tareas que pueda delegar ni iniciar una fase nueva sin autorización.

Incluye también un perfil de feedback. Debe escuchar las fuentes aprobadas de
feedback de usuarios, clasificar cada señal con su contexto, evidencia, urgencia
y confianza, detectar patrones y entregar síntesis priorizables al orquestador.
No modifica el roadmap ni abre implementación por su cuenta: el orquestador
decide qué se aprueba, se descarta, se investiga o se delega.

Antes de crear nada, presenta el roster, los solapamientos, los riesgos y la
arquitectura del board para que pueda aprobarlos. Después de la aprobación,
crea y configura los perfiles, añade descripciones útiles para el routing,
verifica modelos y esfuerzo, y prueba cada identidad en una sesión nueva.
No hagas commit, push ni deploy sin permiso explícito.

La pausa antes de crear los perfiles merece la pena. Es más barato corregir un organigrama en una tabla que descubrir después que tres agentes se consideran propietarios de la misma parte del código.

El orquestador debe pensar más y tocar menos

Siempre reservo el modelo más potente y el mayor esfuerzo de razonamiento para el perfil orquestador. No porque tenga que escribir el código más difícil, sino porque toma las decisiones con mayor radio de impacto.

El orquestador interpreta una iniciativa, consulta el estado real del repositorio, decide qué especialistas necesita, crea el grafo de tareas, establece dependencias y evalúa si la evidencia permite cerrar. Un error suyo puede mandar a varios perfiles en la dirección equivocada. Ahorrar demasiado en este punto sale caro.

También le impongo una restricción: orquestar no es implementar. Si el perfil coordinador termina corrigiendo componentes, escribiendo tests y revisando su propio resultado, desaparece la separación de responsabilidades. Se convierte en un agente generalista con ayudantes ocasionales.

Los especialistas pueden utilizar modelos más ajustados al tipo de tarea. Un perfil de investigación o producto necesita sintetizar información ambigua. Un ingeniero requiere precisión sobre el código y disciplina con los tests. Un perfil documental puede trabajar con un modelo más económico en tareas mecánicas, aunque debería subir de nivel cuando tenga que reconstruir decisiones o contratos públicos. Seguridad, integridad de datos y revisión final no son buenos lugares para recortar razonamiento.

No hay una tabla universal. El catálogo de modelos cambia y cada producto tiene riesgos distintos. La regla que sí mantendría es esta: asignar capacidad según el coste de equivocarse, no según lo vistoso que parezca el rol.

Perfiles que forman un equipo, no una colección

Un roster inicial podría incluir:

No todos los productos necesitan todos los perfiles desde el primer día. Separaría un rol cuando tenga un conocimiento propio, un tipo de evidencia diferente o deba revisar a otro con independencia. Si dos perfiles reciben las mismas tareas y producen el mismo artefacto, probablemente sobra uno.

La especialización también tiene un límite. Un agente llamado frontend, con una descripción genérica y acceso a todas las herramientas sigue siendo, en la práctica, un generalista. El valor aparece cuando su contrato explica dónde empieza y termina su autoridad.

El feedback necesita un perfil que escuche antes de priorizar

El loop de producto mejora mucho cuando hay un perfil dedicado a revisar las fuentes donde los usuarios ya están hablando. Puede escuchar de forma continua un canal de Telegram, conversaciones de HubSpot, respuestas de Google Forms u otra fuente aprobada. Su función no es acumular mensajes ni convertir cada petición en una tarea: transforma feedback disperso en señales comparables.

Para cada señal conservaría el origen, la fecha, el problema o necesidad que describe, el segmento afectado cuando se conozca y el enlace a la evidencia. Después la clasificaría por tema, frecuencia, impacto potencial, urgencia y confianza. Así el equipo puede distinguir una incidencia repetida de una idea interesante pero aislada, o una petición literal de la necesidad real que hay detrás.

El perfil entrega al orquestador una síntesis corta y trazable: patrones detectados, ejemplos representativos, preguntas abiertas y una propuesta de siguiente paso. El orquestador conserva la decisión: puede aprobar una investigación, descartar una señal, pedir más evidencia o delegar una iniciativa en producto, diseño, ingeniería o QA. Esa separación evita que una integración externa gobierne el roadmap y mantiene la priorización ligada a la estrategia, el alcance autorizado y la evidencia disponible.

También conviene definir el contrato de cada fuente antes de conectarla: qué datos puede leer el perfil, cuánto tiempo se conservan, qué información debe anonimizarse y quién puede acceder a la evidencia original. Escuchar de forma continua solo aporta valor si el loop sigue siendo seguro, auditable y capaz de cerrar el ciclo con una decisión explícita.

La descripción del perfil es parte de la asignación

En Hermes, cada perfil mantiene su propia configuración, sesiones, memoria, skills y personalidad. La descripción permite al decompositor automático de Kanban y a los perfiles que coordinan el tablero decidir qué trabajo encaja con cada especialista.

La descripción es una etiqueta de asignación, no una barrera. No restringe herramientas, permisos ni acceso al repositorio. Los límites de conducta también deben aparecer en SOUL.md y, cuando el riesgo lo exija, reforzarse mediante configuración, permisos o aislamiento real.

Una descripción débil sería:

Experto en desarrollo frontend.

Una descripción útil sería:

Implementa y revisa interfaces Astro y React del producto, con foco en
accesibilidad, estados, responsive y pruebas de navegador. No modifica reglas
de dominio ni contratos de backend; bloquea la tarea si faltan criterios de
aceptación o una API estable.

La segunda permite asignar mejor. Las instrucciones y los controles adicionales deben encargarse de que el perfil rechace lo que queda fuera de su función. Esto evita uno de los fallos más comunes en sistemas multiagente: que cualquier perfil acepte cualquier tarjeta porque técnicamente tiene acceso al repositorio.

Conviene verificar las descripciones después de crearlas y probar cada perfil en una sesión nueva. Que un comando haya terminado sin error no demuestra que el agente haya entendido su identidad, use el modelo previsto o entregue el resultado al perfil correcto.

SOUL.md dice quién es; AGENTS.md, qué necesita el producto

La identidad y las reglas del proyecto no deberían mezclarse.

SOUL.md pertenece al perfil. Define quién es ese agente, cómo se comunica, qué responsabilidad conserva y qué no debe hacer. El SOUL.md del orquestador puede indicarle que no implemente. El del revisor puede decirle que no debe corregir sus propios hallazgos. El del investigador puede recordarle que una referencia interesante no entra automáticamente en el roadmap. Son instrucciones para el modelo, no una frontera de seguridad.

AGENTS.md pertenece al repositorio. Contiene arquitectura, convenciones, comandos, fuentes de verdad, comprobaciones y restricciones que debe respetar cualquier agente que trabaje en el producto. Hermes carga el archivo del directorio de trabajo al empezar la sesión y descubre progresivamente los AGENTS.md de subdirectorios mientras opera. Por eso configurar terminal.cwd o iniciar al trabajador en el repositorio correcto es parte del harness, no un detalle operativo.

También conviene recordar la prioridad de los archivos de contexto. Hermes carga un solo tipo: .hermes.md o HERMES.md tienen prioridad sobre AGENTS.md, que a su vez va antes de CLAUDE.md y las reglas de Cursor. Un archivo más específico puede ser útil, pero también puede ocultar sin querer las reglas portables del proyecto. La solución es decidir una estrategia y comprobar qué contexto ve realmente una sesión nueva.

Un AGENTS.md útil para este tipo de entorno debería cubrir:

• propósito y límites del producto;
• fuentes de verdad y qué hacer cuando se contradicen;
• arquitectura e invariantes;
• estructura del repositorio;
• comandos de instalación, test, build y smoke;
• reglas de alcance y permisos;
• flujo RED → GREEN → REFACTOR cuando haya comportamiento verificable;
• revisión independiente y definición de terminado;
• política de worktrees o propiedad de archivos;
• prohibición de inventar resultados, métricas o verificaciones.

No intentaría meter todo el conocimiento del producto en este archivo. Como el contexto se inyecta en la sesión y consume tokens, conviene mantenerlo enfocado y conciso. Las reglas estables y transversales van en AGENTS.md; los procedimientos complejos y reutilizables, en skills; el detalle de una iniciativa, en su especificación y sus tarjetas.

Un board permanente y una raíz por iniciativa

El Kanban debería representar el producto, no la tarea del mes. Mantendría un board permanente y crearía una tarjeta raíz distinta para cada iniciativa: una migración, una nueva capacidad, una campaña de QA, un bug o una release.

Board permanente: Mi producto
│
├── Iniciativa: validar la propuesta inicial
│   ├── investigación
│   ├── flujos y criterios
│   └── decisión de alcance
│
├── Iniciativa: implementar la primera vertical slice
│   ├── contrato
│   ├── implementación
│   ├── revisión
│   └── aceptación
│
└── Bugs y mantenimiento

Hermes Kanban es un tablero durable compartido entre perfiles. Conserva tareas, responsables, dependencias, intentos, bloqueos y entregas. Con el gateway activo, el dispatcher reclama tareas asignadas que están en ready. Cuando todos sus padres terminan, las dependientes pasan automáticamente de todo a ready. Eso permite que la coordinación sobreviva a una sesión, un reinicio o un cambio de agente.

En modo manual, el orquestador del producto crea el grafo y sus dependencias. En modo automático, el decompositor integrado de Kanban consulta el roster y las descripciones para proponer y asignar las tareas; el perfil configurado como orquestador recibe la raíz y vuelve a intervenir para juzgar el cierre. Conviene distinguir ambos mecanismos para no atribuir al SOUL.md del orquestador decisiones que en realidad tomó el decompositor auxiliar.

Como convención del harness, cada cierre incluye un resumen breve y metadatos estructurados, por ejemplo cambios, decisiones, pruebas y límites. Una tarea también puede pasar a revisión o bloquearse sin completarse. El siguiente agente necesita contexto útil, no un informe de veinte páginas.

Para una consulta breve que debe volver al contexto actual, una delegación temporal puede ser suficiente. Para trabajo con dependencias, intervención humana, reintentos o continuidad entre sesiones, Kanban es una base mucho más fiable. Yo utilizo Bot Mode como sala de deliberación para discutir arquitectura, alternativas de diseño o riesgos. La conversación decide; el tablero ejecuta y registra.

Los errores que más han mejorado el harness

He cometido varios errores construyendo estas estructuras. Ninguno fue espectacular, pero juntos explican por qué el sistema actual es bastante más estricto.

Confundir el board con la iniciativa activa

La primera versión del tablero puede acabar descrita alrededor de una migración o una fase concreta. Cuando termina, el supuesto harness permanente deja de tener sentido. La solución es mantener el board ligado al producto y usar una tarjeta raíz con cierre propio para cada iniciativa.

Crear perfiles y dar por hecho que funcionan

Un perfil puede existir con una descripción pobre, un modelo distinto al esperado, skills que faltan o un directorio de trabajo incorrecto. Ahora compruebo configuración, descripción, herramientas e identidad mediante sesiones nuevas antes de ponerlo a trabajar.

Tratar los perfiles como sandboxes

Los perfiles aíslan estado de Hermes, pero no aíslan el sistema de archivos. Dos agentes pueden tocar el mismo checkout y pisarse. Para trabajo paralelo utilizo worktrees o propiedad explícita de archivos; si comparten un hotspot, serializo las tareas.

Dejar que una revisión abra trabajo infinito

Una revisión puede detectar mejoras reales y aun así salirse de la fase autorizada. La solución no es ignorar el hallazgo, sino clasificarlo: bloqueante de la aceptación actual, corrección acotada o trabajo futuro. Una fase cerrada no se reabre para cualquier mejora; se crea una nueva tarjeta vinculada a la anterior.

Revisar un candidato que sigue cambiando

Si varios perfiles revisan mientras otro agente modifica el mismo código, sus conclusiones dejan de referirse al mismo artefacto. Congelo un candidato, registro su commit o fingerprint, ejecuto las revisiones sobre esa versión y limito las rondas de corrección. Después vuelvo a pasar los gates afectados.

Automatizar demasiado pronto

Sincronizar perfiles, skills, prompts y recuperación entre máquinas puede convertirse en otro producto. Empiezo por un manifiesto legible, una guía de recuperación y verificaciones simples. Cuando la estructura se estabiliza, la empaqueto como distribución versionada o añado automatización con tests. La portabilidad debe poder demostrarse desde una instalación limpia.

Pedir una revisión adversarial demasiado tarde

Si seguridad, datos y QA descubren los casos extremos uno por uno al final, cada hallazgo provoca otra ronda completa. Funciona mejor consolidar primero las clases adversariales del dominio, convertirlas en tests o criterios y ejecutar después los gates y revisiones finales sobre un candidato estable.

Estos límites no hacen que los agentes sean menos autónomos. Les dan un terreno claro donde ejercer autonomía sin convertir cada tarea en una renegociación del producto.

Qué hace robusto al harness

Un harness de desarrollo no es robusto porque todos sus agentes usen el mejor modelo. Es robusto cuando puede responder con evidencia a preguntas bastante sencillas:

• ¿Qué iniciativa está autorizada?
• ¿Qué queda fuera de alcance?
• ¿Qué perfil es responsable y por qué?
• ¿Qué dependencias impiden empezar?
• ¿Qué versión exacta se ha revisado?
• ¿Qué pruebas se ejecutaron de verdad?
• ¿Quién puede aprobar el cierre?
• ¿Cómo se recupera el sistema si una tarea falla o una máquina desaparece?

Para llegar ahí hacen falta perfiles especializados, pero también descripciones precisas, reglas de repositorio, tareas durables, handoffs cortos, aislamiento de escritura, gates reales y revisiones independientes. El modelo potente del orquestador ayuda a mantener la visión, aunque no sustituye ninguna de esas piezas.

«Si producir trabajo deja de costar, el cuello de botella pasa a ser decidir qué trabajo merece existir.»

Con cinco agentes mal coordinados no tienes un equipo. Tienes cinco formas distintas de alejarte del producto. El harness sirve para que Hermes pueda producir más sin obligarme a reconstruir después qué se decidió, quién tocó cada cosa y por qué deberíamos darla por terminada.

Fuentes

• Profiles: Running Multiple Agents | Hermes Agent
• Profile Commands Reference | Hermes Agent
• Kanban - Multi-Agent Profile Collaboration | Hermes Agent
• Kanban tutorial | Hermes Agent
• Which File Does What? | Hermes Agent
• Tips & Best Practices | Hermes Agent
• Bot Mode | Hermes Agent