Temario · lección 29 de 74
1Por qué fallan los agentes
2Qué es un harness
3Patrones de agentes
4Herramientas
5Ingeniería de contexto
6El repositorio como memoria
7Tareas largas
8Alcance y “hecho” de verdad
9Observabilidad y estado limpio
10Loops y grafos
11Harness reales
12Proyecto final
- Proyecto 1, solo prompt contra harness mínimo
- Proyecto 2, un workspace legible
- Proyecto 3, continuidad entre sesiones
- Proyecto 4, feedback de runtime e indexado
- Proyecto 5, que el agente verifique su trabajo
- Proyecto 6, el harness completo (capstone)
- Proyecto 7, tu primer loop automático
- Proyecto 8, dibuja tu flujo como un grafo
- Checklist final y plantillas
El repo, fuente de verdad
Para un agente, lo que no está escrito en el repositorio no existe. Slack, tickets y la cabeza de tu equipo no cuentan.
La decisión que solo sabía Marta
Tu equipo decidió el viernes, tomando un café, que todas las fechas se guardan en UTC. Marta lo sabe. Lo comentaron en Slack. Pero el lunes un agente escribe una función que guarda la hora local, y nadie se lo había dicho.
No es un fallo del modelo. Es un fallo de visibilidad: la decisión estaba fuera del único sitio donde el agente puede mirar.
Qué ve realmente un agente
Las entradas de un agente son pocas: el prompt de sistema, la descripción de la tarea, los archivos del repositorio y la salida de sus herramientas. Eso es todo. No ve tu Slack, ni Jira, ni Confluence. No puede preguntarle a un compañero.
Es como un ingeniero encerrado dentro del repositorio: de lo que queda fuera de las paredes no sabe nada. Por eso el curso (y OpenAI, cuyo enfoque describe) lo resume así: la información que no existe en el repo no existe para el agente. Es el principio de que el repo es la especificación con más autoridad.
Conceptos útiles
- Sistema de registro: el repositorio es la fuente autorizada de decisiones, restricciones, estado y estándares de verificación. Si hay conflicto, manda el repo.
- Brecha de visibilidad del conocimiento: la parte del conocimiento del proyecto que NO está en el repo. Cuanto mayor, más fallos del agente.
- Coste de descubrimiento: cuánto contexto gasta el agente en encontrar algo. Un dato crítico escondido diez carpetas abajo cuesta mucho.
- Degradación del conocimiento: una documentación que ya no coincide con el código es peor que no tener ninguna, porque manda al agente en la dirección equivocada con total confianza.
Cómo mover conocimiento al repo
Una guía rápida de dónde va cada cosa (basada en el procedimiento de OpenAI incluido en los recursos del curso):
| Conocimiento | Dónde escribirlo |
|---|---|
| Arquitectura | ARCHITECTURE.md |
| Comportamiento del producto | docs/product-specs/ |
| Por qué se decidió algo | docs/design-docs/ |
| Estado del trabajo | docs/exec-plans/ |
| Referencias externas repetidas | docs/references/ |
Y cuatro reglas: escribe para que se encuentre, no para que luzca; prefiere documentos cortos con nombres claros; guarda reglas duraderas, no actas de reuniones; y actualiza el repo en la misma sesión en que se toma la decisión. Elimina las copias antiguas para que haya una sola verdad.
Ejemplo mínimo
La decisión de Marta, escrita donde el agente la verá:
<!-- docs/ARCHITECTURE.md -->
## Fechas
Todas las fechas se almacenan en UTC y se convierten a hora local
solo en la capa de interfaz. Decidido el 2025-03-14 por consistencia
entre servidores en distintos países.
Tres líneas. A partir de ahora cualquier sesión nueva puede cumplirla.
¿Por qué una decisión comentada solo en Slack no sirve a un agente?
Fuentes: Learn Harness Engineering, lección 03 · OpenAI, Harness engineering (vía el curso)