El problema que nadie te cuenta de los agentes
Un agente de codificación no tiene memoria entre sesiones. Cada vez que se agota la ventana de contexto y empieza una nueva, el modelo llega como un empleado en turno de noche que no sabe qué hizo el del turno de día: mira el código, intenta adivinar qué estaba a medias y, con suerte, no rompe nada.
Anthropic lo describió muy bien en Effective harnesses for long-running agents: sin una estructura que haga de puente entre sesiones, hasta un modelo puntero acaba intentando hacerlo todo de una vez, se queda sin contexto a mitad de una feature y deja el repositorio en un estado del que el siguiente agente no se fía. O peor: ve que hay avances, decide que el trabajo está hecho y se va.
Yo llevaba tiempo dándole vueltas a lo mismo en mi propio harness. Leer ese artículo fue menos un descubrimiento y más un “vale, vamos por buen camino, pero esto se puede afinar”. Aquí va lo que me llevé y cómo lo apliqué.
Las dos ideas que me quedé de Anthropic
La solución de Anthropic se apoya en dos piezas. Un agente inicializador, que
en la primera sesión prepara el terreno: monta el entorno, escribe un init.sh
para arrancar el proyecto, crea un feature_list.json con todo lo que la app
debería hacer (marcado como “pendiente”) y deja un claude-progress.txt con el
registro de lo ocurrido. Y un agente de codificación, que en cada sesión
posterior lee ese rastro, avanza una sola feature, la verifica de extremo a
extremo y cierra dejando un commit limpio y el progreso anotado.
La idea de fondo es sencilla y poderosa: el estado del trabajo no vive en la memoria del modelo, vive en artifacts perdurables que cualquier sesión futura puede leer en segundos. El git y un par de ficheros de texto hacen de memoria compartida.
Mi harness: un pipeline de ocho agentes
Mi enfoque parte del mismo principio, pero en vez de un único agente de codificación lo parto en una cadena de agentes especializados. Es un CLI en TypeScript que se instala en cualquier repositorio y deja una tubería de ocho pasos para Claude Code:
1. init haiku → detecta stack, dependencias y test runner
2. explore sonnet → intención, alcance y fuera-de-alcance; crea rama feat/<slug>
3. spec opus → requisitos, decisiones y criterios de aceptación
4. design sonnet → arquitectura; qué resolver inline y qué delegar
5. task sonnet → tareas atómicas con score 1-5 y modelo sugerido
6. apply ×3 haiku/sonnet/opus → TDD por tarea, un commit cada una
7. verify sonnet → suite completa + 2 casos límite extra
8. documental sonnet → documentación para devs y para QACada paso escribe su artifact en .harness/<feature-slug>/<step>.md. Eso es,
literalmente, mi versión del claude-progress.txt: el rastro que permite a
cualquier paso —o a mí— entender el estado sin releer toda la conversación.
El mapeo, idea por idea
Cuando puse mi diseño al lado del de Anthropic, los paralelismos saltaron solos.
| Idea de Anthropic | Cómo la resuelvo en mi harness |
|---|---|
| Agente inicializador que prepara el entorno | El paso init detecta stack, deps y runner de tests |
feature_list.json con el alcance completo | spec y task descomponen en criterios de aceptación y tareas atómicas |
claude-progress.txt + git como puente | Un artifact .md por paso, más un commit por tarea |
| Progreso incremental, una feature por sesión | apply trabaja tarea a tarea con TDD: test que falla, código mínimo, test que pasa |
| Verificación de extremo a extremo | El paso verify corre la suite completa y añade dos casos límite |
| Declarar victoria antes de tiempo | Los gates manual en spec, task y verify me obligan a revisar antes de seguir |
La coincidencia no es casual: los dos partimos de mirar cómo trabaja un equipo de ingeniería de verdad. Spec antes de código, tests antes de implementación, commits pequeños y trazables, y un sitio donde apuntar lo que se ha hecho.
Donde decidí ir más allá
El artículo de Anthropic deja una pregunta abierta para el futuro: ¿rinde más un único agente generalista, o varios agentes especializados (un planificador, un generador, un evaluador)? Mi harness es, básicamente, una apuesta por la segunda opción. Cada paso tiene su propio subagente con su prompt y, sobre todo, su propio modelo.
Ahí está la otra diferencia: el coste. El paso task asigna a cada tarea un score
de complejidad de 1 a 5 y, con él, un modelo. Las triviales van a Haiku, las
medias a Sonnet, y solo lo difícil llega a Opus. No tiene sentido pagar el modelo
más caro para escribir un getter.
model_selection:
mode: heuristic # 1-2 → haiku, 3-4 → sonnet, 5 → de vuelta al spec
thresholds:
haiku_max: 2
sonnet_max: 4
fallback: sonnetEs la misma filosofía de Anthropic —dale al agente la estructura para no perderse— llevada un paso más allá: que además gaste lo justo en cada decisión.
Qué funcionó y qué sigo puliendo
Lo que mejor ha salido es el rastro de artifacts. Abrir .harness/<slug>/ y ver
el spec, el diseño, las tareas y el resultado de verify de una feature es, para mí
y para cualquiera que herede el trabajo, infinitamente mejor que reconstruirlo de
la cabeza del modelo. Los gates manuales en spec, task y verify me han
ahorrado más de un disgusto: reviso decisiones y casos límite antes de que el
pipeline siga gastando tokens en la dirección equivocada.
Lo que sigo afinando es el reparto de modelos —el score heurístico acierta casi siempre, pero a veces infravalora una tarea— y la verificación de interfaces, que es justo el punto débil que Anthropic también reconoce: hay bugs que no se ven en el código ni en un test unitario.
Si te interesa el tema, el artículo de Anthropic es de lectura obligada. Y la conclusión que me llevo es la misma con la que ellos cierran: el modelo es la parte fácil; el harness que lo rodea es donde se decide si el agente trabaja una hora o se pierde en la primera.