Qué es realmente un harness
Un harness no hace al modelo más listo. Lo que hace es meterlo en un bucle: le das una meta, trabaja, algo comprueba el resultado, y vuelta a empezar.
Un gran actor necesita un set, un guion, un director que diga corten y un montador antes de que haya película. El actor aporta el talento; todo lo que lo rodea aporta la fiabilidad. Un harness es el set alrededor del modelo: el guion es el objetivo, el equipo son las herramientas y el entorno, y el director decide cuándo la toma es buena.
Seis etapas, un bucle
Reduce a sus huesos un montaje fiable de agentes y siempre encuentras las mismas seis etapas:
- Objetivo, reglas explícitas y una definición verificable de «hecho» (
AGENTS.md, una lista de funciones). - Inicializa, construye el entorno desde cero, cada vez (
init.sh). - Ejecuta, el agente edita y ejecuta dentro de una terminal persistente.
- Feedback, la salida del runtime y los logs vuelven, así los errores son la siguiente tarea.
- Verifica, una puerta de pipeline completo decide hecho o no-hecho.
- Traspaso, commit, orden y una nota para que la siguiente vuelta arranque con claridad.
Si la verificación falla, vuelve al feedback. Si pasa, va al traspaso y luego a la siguiente unidad de trabajo. Ese ciclo es el harness.
flowchart LR
O["Objetivo, AGENTS.md + feature_list.json"] --> I["Init, init.sh"]
I --> R["Ejecuta, agente en tmux"]
R --> F["Feedback, logs"]
F --> V{"Verifica, verify.sh"}
V -->|rojo| R
V -->|verde| H["Traspaso, handoff.md"]
H --> O
linkStyle 4 stroke:#e0493f,stroke-width:2.5px,color:#e0493f
linkStyle 5 stroke:#2ea043,stroke-width:2.5px,color:#2ea043
Por qué un prompt no basta
Un buen prompt mejora un solo turno. Un harness mejora el turno número cien, porque posee lo que un prompt no puede: estado duradero, un entorno real, evidencia del runtime y una puerta que se niega a aceptar trabajo sin verificar. Los prompts están dentro del bucle; el harness es el bucle.
Agentum es el bucle, empaquetado
En Agentum estas seis etapas son el Harness Engine. Se mapean a archivos reales en un directorio .agentum-harness/: el objetivo es AGENTS.md más feature_list.json, el init es init.sh, la ejecución es un agente real lanzado en tmux, y la puerta es verify.sh. El motor corre init.sh una vez, luego para cada función pending lanza un agente acotado a esa función, espera a que se asiente y corre verify.sh con la clave $HARNESS_FEATURE_ID. El verde marca la función done, escribe handoff.md y avanza. El rojo reinyecta al agente la salida fallida y reintenta hasta max_retries antes de detenerse. No hay promesa de finalización que falsear, porque la puerta es un script de shell, y la corrida termina solo cuando todas las funciones están en verde.
El bucle mayor: roles alrededor del trabajo
Ese bucle de funciones es solo el centro de uno mayor. Agentum lo envuelve en un ciclo de roles SDD autónomo, una máquina de fases que corre por encima del backlog: authoring → architecture → decompose → executing → review → done. Cada fase antes y después del trabajo la juega un agente de rol. Un PM aclara el spec, un Arquitecto valida el diseño, el bucle de funciones que acabas de ver es la fase de Developer, y un Reviewer lo aprueba.
Todo avanza solo. Una puerta pasa cuando el agente de rol produce su artefacto y un veredicto legible por máquina, nunca con un toque humano. Abres un spec y te vas: el PM lo refina, el arquitecto lo revisa, el harness construye y verifica cada función, el reviewer aprueba, y vuelves a un cambio terminado y verificado. Una parada humana es opcional, nunca el valor por defecto, incluso en QA.
Puntos clave
- Un harness es un bucle cerrado, no un prompt más astuto.
- Las seis etapas, objetivo, init, ejecución, feedback, verificación, traspaso, se repiten en todo montaje fiable.
- La verificación es el gozne: fallar vuelve al feedback, pasar va al traspaso.
- Agentum empaqueta el bucle con barandillas reales (promesa de finalización, tope de iteraciones).
Ejercicios
- Mapea tu montaje. Dibuja tu flujo actual como las seis etapas. ¿Qué etapa falta o es solo implícita?
- Encuentra la puerta. Identifica el único chequeo que decide el done en tu proyecto. ¿Es opinión humana o un script?