AGENTES · SISTEMAS · CONFIABILIDAD
El modelo no es
el sistema.
Un agente de código confiable no aparece porque el prompt sea brillante. Aparece cuando el repositorio le da un mapa, el trabajo tiene límites, la ejecución produce evidencia y cada sesión deja un estado que otra puede retomar. Esta es la versión compacta de las catorce lectures de Learn Harness Engineering.
01 / LA UNIDAD DE DISEÑO
No diseñes
un prompt.
Diseñá el sistema que rodea al modelo.
La primera corrección conceptual del curso es separar capacidad de confiabilidad. Un modelo puede entender el código y aun así implementar otra cosa, tocar de más, perder decisiones entre sesiones o declarar victoria con el sistema roto. Esos no son necesariamente fallos de inteligencia: son fallos del entorno de ejecución.
El harness es todo lo que convierte una intención en un ciclo de trabajo: qué sabe el agente, qué puede hacer, dónde actúa, qué recuerda y qué evidencia recibe. Si una falla se puede atribuir a uno de esos subsistemas, cambiar de modelo es una respuesta prematura.
Intención
Un mapa corto del proyecto, restricciones no negociables y enlaces a detalle relevante.
Capacidad
Acceso suficiente para leer, cambiar, ejecutar y diagnosticar, limitado por mínimo privilegio.
Repetibilidad
Runtime, dependencias y comandos fijados para que dos sesiones operen el mismo sistema.
Continuidad
Progreso, decisiones, bloqueos y próximo paso persistidos fuera de la conversación.
Evidencia
Checks rápidos, pruebas de comportamiento y señales de runtime que cierran el loop.
02 / EL REPOSITORIO COMO MEMORIA
Un mapa corto.
Detalle cerca del código.
La información útil tiene que ser encontrable, vigente y proporcional a la tarea.
AGENTS.mdEntradaPropósito, stack, comandos, restricciones y rutas hacia documentación específica.
docs/ + module docsContexto bajo demandaArquitectura, decisiones y reglas al lado del área donde aplican.
PROGRESS.mdEstado operativoQué terminó, qué está activo, qué bloquea y cuál es el próximo paso verificable.
TEST DE SESIÓN NUEVACon solo el repositorio, una sesión nueva debería poder explicar qué es el proyecto, cómo arrancarlo, qué reglas no puede romper, cómo verificarlo y dónde continuar. Cada respuesta ausente se convierte en costo de descubrimiento o en una suposición.
Acumular toda corrección en un único archivo reduce señal, entierra restricciones y crea contradicciones. El entrypoint debe orientar, no contener el universo. Las reglas repetitivas y mecánicas deberían ascender a tipos, lint, tests o CI.
03 / EL CICLO DE UNA SESIÓN
Empezar listo.
Terminar retomable.
La continuidad se diseña en los bordes de la sesión.
- 01INICIALIZAR
Reconstruir realidad
Leer instrucciones y estado, inspeccionar el worktree, instalar lo necesario y ejecutar un baseline. Si el punto de partida ya está rojo, registrarlo antes de tocar negocio.
- 02EJECUTAR
Una unidad a la vez
Elegir una tarea, declarar alcance y exclusiones, implementar, observar y corregir hasta obtener evidencia.
- 03CERRAR
Commit lógico o handoff honesto
Verificar, limpiar temporales y persistir decisiones, resultados y próximo paso. Incompleto no es fracaso; ambiguo sí.
Pensalo como un cambio de turno: la próxima sesión no necesita la transcripción completa; necesita una representación compacta y fiel del estado ejecutable.
04 / ALCANCE Y DEFINICIÓN DE DONE
Menos trabajo abierto.
Más trabajo terminado.
Para agentes, WIP=1 es un default de seguridad.
F-03Un usuario puede exportar el reporte completo desde la pantalla de resultados.
npm run test:e2e -- exportactive → passingSin refactor del sistema de archivos ni rediseño visual.
Una feature list no es una lista de deseos. Es el contrato compartido entre quien selecciona, quien implementa, quien verifica y quien retoma. El agente puede proponer que algo está listo; solo la evidencia puede moverlo a passing.
05 / FEEDBACK QUE CIERRA EL LOOP
“Parece correcto”
no es evidencia.
Cada nivel responde una pregunta distinta y descubre fallas diferentes.
- 01ESTÁTICOBARATO · FRECUENTE
¿Tiene forma válida?
Format, lint, tipos, build y unit tests. Son rápidos y localizan bien, pero no prueban el producto compuesto.
- 02RUNTIMECONCRETO · DIAGNÓSTICO
¿Arranca y se comporta?
Integración, migraciones, health checks, side effects y rutas críticas con dependencias reales.
- 03SISTEMACARO · DECISIVO
¿La persona logra la tarea?
E2E, revisión visual, accesibilidad y escenarios de falla. Prueba interfaces y fronteras, no solo componentes.
“Falló el test” deja al agente adivinando. “El renderer accedió al filesystem; mové la operación al preload bridge y repetí el flujo export” convierte el check en un mecanismo de autocorrección. Cuando una observación humana se repite, promovela a una regla ejecutable.
06 / OBSERVABILIDAD
Ver qué hizo.
Entender por qué siguió.
La confiabilidad es un problema de evidencia, no de vibes.
El sistema observado
Inicio, ready state, logs correlacionados, errores completos, rutas críticas, consumo de recursos y cleanup.
La decisión observable
Objetivo, alcance, exclusiones, plan, criterio de aceptación, resultado del verificador y motivo de cada retry.
TRAZA MÍNIMAtask_id · code_version · active_feature · command · result · attempt · next_action
07 / DE LOOP A GRAFO
Automatizá después
de poder detener.
La autonomía amplifica tanto el diseño como sus defectos.
Meta verificable
Describir el estado final, no una sucesión infinita de acciones.
Juez separado
Tests determinísticos o un evaluador con contexto fresco; el autor no corrige su propio examen.
Presupuesto y salida
Máximo de intentos, tiempo, costo y escalamiento explícito cuando no hay progreso.
Memoria externa
El loop reconstruye contexto desde artefactos; no depende de recordar la conversación.
hay un objetivo principal, un camino dominante, retries locales y un único estado que avanza.
hay roles especializados, trabajo paralelo, rutas condicionales, rollback a etapas distintas, árbitros o aprobación humana.
Un grafo no reemplaza el harness: lo hace visible a escala. Sus nodos tienen responsabilidades; sus aristas, condiciones; su estado, reglas de merge; y sus anchors lo conectan con resultados reales para que una métrica no se convierta en el objetivo equivocado.
EL PLAYBOOK MÍNIMO
Mapa. Contrato.
Evidencia. Handoff.
- Hacé que una sesión nueva pueda operar el repo sin explicación oral.
- Activá una sola unidad con comportamiento, exclusiones y check explícitos.
- Usá tests y runtime para decidir done; nunca la confianza del autor.
- Dejá el sistema verde o documentá con precisión por qué no lo está.
- Recién entonces automatizá el loop; dibujá un grafo solo si las rutas lo exigen.
08 / LAS 14 LECTURES EN UNA LÍNEA
Cobertura completa.
Sin relleno.
El hilo completo del curso, reducido a la decisión que vale la pena conservar de cada unidad.
- 01
Diagnosticar el sistema
Un agente capaz puede fallar por requisitos vagos, contexto ausente, entorno roto, feedback débil o pérdida de estado.
- 02
Diseñar cinco subsistemas
Un prompt file no es un harness: instrucciones, herramientas, entorno, estado y feedback tienen responsabilidades distintas.
- 03
Hacer del repo el registro
Lo que no está en un lugar visible y mantenido no existe para una sesión nueva.
- 04
Dar un mapa, no un manual
El archivo de entrada debe enrutar a documentación cercana al código y cargada bajo demanda.
- 05
Persistir el porqué
El código conserva qué cambió; el handoff debe conservar decisiones, resultados y próximo paso.
- 06
Inicializar antes de implementar
Primero hay que probar que el proyecto arranca, se verifica y puede ser retomado.
- 07
Limitar WIP a uno
Terminar una unidad verificable antes de abrir otra reduce alcance accidental y trabajo a medias.
- 08
Externalizar el contrato
Cada feature necesita comportamiento esperado, verificación, estado y evidencia.
- 09
Quitarle al autor el “done”
La confianza del agente no es criterio de cierre; una condición ejecutable e independiente sí.
- 10
Probar el recorrido completo
Los unit tests aíslan; integración y E2E encuentran contratos, estado y recursos que fallan al componerse.
- 11
Volver visible la ejecución
Logs y health checks explican qué pasó; planes, criterios y rúbricas explican por qué aceptarlo.
- 12
Cerrar limpio
Build y tests verdes, estado actualizado, temporales removidos y camino de arranque funcional.
- 13
Automatizar solo un loop cerrado
Autonomía exige meta, verificador, límite y estado externo; sin eso solo repetimos incertidumbre.
- 14
Usar grafos cuando la topología importe
Especialización, paralelismo, rollback y arbitraje justifican nodos y rutas explícitas.
09 / FUENTES
Leé el curso.
Después, las bases.
Esta pieza sintetiza las lectures; no reemplaza sus ejemplos, ejercicios ni matices.
- 01Curso completo · Learn Harness Engineering↗
- 02Harness engineering en un entorno agent-first · OpenAI↗
- 03Harnesses efectivos para agentes de larga duración · Anthropic↗
- 04Diseño de harness para desarrollo de aplicaciones de larga duración · Anthropic↗
- 05Construir agentes efectivos · Anthropic↗
Síntesis editorial basada en el contenido público disponible al 31 de agosto de 2026. Las recomendaciones prácticas fueron reformuladas y agrupadas; no son una reproducción literal del curso.