Qué vas a construir

Son las 09:00 y la responsable de Operaciones abre el informe diario. Está bien redactado, tiene su tabla de cifras y una sección de alertas. El agente que lo generó marcó la tarea como terminada y su propio revisor le dio el visto bueno, un PASS.

Una de las cifras es falsa, y nadie lo ha detectado.

Ese es el punto de partida del módulo. Un agente puede escribir un informe impecable y equivocarse justo en el dato que importa. Lo que decide si puedes publicarlo es lo que hay alrededor del modelo.

Es la primera de cinco piezas, una por cada par de módulos y cada una con su laboratorio y su caso: el harness, los agentes acotados, la búsqueda con permisos, el gate de evals (un gate es una comprobación que deja pasar o bloquea un cambio; la tienes en el glosario) y la extracción de documentos. En la última lección del curso las juntas en el documento de arquitectura de un sistema tuyo.

Qué es un harness

El harness (el armazón) es todo lo que rodea al modelo cuando trabaja como agente: el contexto que lee al empezar, los procedimientos que puede cargar, las herramientas que tiene permitidas, las comprobaciones que se ejecutan antes y después de cada acción y la pieza que publica el resultado final.

El modelo redacta. El harness decide qué puede tocar, qué se comprueba y qué llega a publicarse.

En el nivel 2 diseñaste tools y un servidor MCP, es decir, lo que el modelo puede hacer. Aquí das el paso siguiente: cómo demuestras que un flujo con un agente produce algo correcto, y qué pieza concreta lo garantiza.

El caso: OpsPulse

OpsPulse es un caso ficticio. Cada mañana un agente genera un informe a partir de tres ficheros CSV:

• data/orders.csv, los pedidos;
• data/incidents.csv, las incidencias, con su fecha de apertura (opened_at) y de cierre (closed_at);
• data/signups.csv, las altas de clientes.

El informe se escribe en informes/ y data/ es de solo lectura. Con ese informe se prepara la reunión de las 09:00, así que una cifra falsa puede esconder una incidencia sin respuesta o mandar a dirección un dato que luego nadie sabe reconstruir.

Las capas que vas a probar

El proyecto trae el harness ya montado en la carpeta demos/parte-1/. Tu trabajo es entender qué aporta cada pieza y comprobarlo con un comando. Son siete capas, y cada una vive en un fichero de demos/parte-1/:

1. Contexto persistente (CLAUDE.md): las reglas que el agente lee al empezar cualquier tarea.
2. Skill (.claude/skills/informe-diario/SKILL.md y metricas-operaciones/SKILL.md): un procedimiento que el agente carga solo cuando la tarea lo pide.
3. Permisos (.claude/settings.json, bloque permissions): lo que la sesión del agente puede hacer y lo que tiene prohibido.
4. Hook previo (PreToolUse, .claude/hooks/protect-data.mjs): un programa tuyo que se ejecuta justo antes de cada acción del agente y puede impedirla.
5. Hook posterior (PostToolUse, .claude/hooks/verify-report.mjs): otro programa que se ejecuta justo después y avisa al agente.
6. Publicador (.claude/hooks/publish-report.mjs): el proceso, fuera del agente, que crea el informe definitivo.
7. Revisor independiente (.claude/hooks/report-contract.mjs, que usan el hook posterior y el publicador): una comprobación que recalcula las cifras desde los CSV sin reutilizar el código que las produjo. En el módulo 2 se le suma el subagente .claude/agents/reviewer.md.

Los dos hooks se enganchan en el bloque hooks del mismo settings.json.

Cinco preguntas para cada capa

Una capa entra en el harness solo si puedes contestar estas cinco preguntas:

1. Hipótesis: qué crees que mejora.
2. Fallo: qué error concreto contiene o detecta.
3. Señal: qué puedes observar para saber que funciona.
4. Coste: cuánto contexto, tiempo y mantenimiento añade.
5. Responsable y fecha de revisión: quién la mantiene y cuándo vuelves a comprobar si sigue haciendo falta.

Un ejemplo con el hook que protege data/. La hipótesis es que el agente no podrá modificar una fuente para que le cuadre una tabla. El fallo que contiene es una escritura en data/orders.csv. La señal es la escritura bloqueada y los CSV sin cambios. El coste, un proceso extra en cada escritura del agente. El responsable es quien mantiene el export de data/, porque es quien sabe si aparece una carpeta nueva que proteger; la revisión, cada vez que cambie la versión de Claude Code o la estructura de data/, y como mínimo una vez por trimestre, con una fecha concreta en el calendario: por ejemplo, el 15-2-2027.

Si una capa no supera estas preguntas, es decoración. Y parte del trabajo de este módulo es quitar la decoración.

Prepara el proyecto

Proyecto de este módulo: agentic-harness. Necesitas Node 22.12 o posterior y macOS, Linux o Windows con WSL. Descárgalo desde la ficha del curso (apartado «El código», con tu sesión iniciada; o pídele el enlace a tu Claude conectado al curso): el zip se descomprime en una carpeta agentic-harness/. Entra en ella, instala las dependencias y comprueba que todo funciona:

cd agentic-harness
npm ci
npm run check

Qué deberías ver: npm ci termina sin vulnerabilidades. npm run check compila, pasa los tests y lanza el starter, la solución, los checkpoints y las ocho demos. Tarda menos de medio minuto, no sale a la red y termina sin ningún error. Si algo sale en rojo, mira la tabla «Si te atascas» del laboratorio de este módulo.

Todos los comandos del módulo se lanzan desde esa carpeta. El camino principal no necesita clave de API ni conexión: los datos son sintéticos y las demos son deterministas, dan siempre el mismo resultado.

Además hay un camino real, opcional. Los comandos npm run live:* lanzan tu Claude Code sobre la misma carpeta demos/parte-1/, con su settings.json, sus hooks y sus skills, y gastan uso de tu plan de Claude, sin clave de API (comprobado el 14-11-2026; mira los datos con fecha). Cada live:* es una llamada a claude -p: una sesión de entre 5 y 17 turnos que costó entre 0,05 y 0,22 $ estimados en nuestras pasadas. Lo verás en tres lecciones:

Lección	Comandos	Llamadas a claude -p
3. Instrucciones que piden y controles que impiden	live:ataque y dos variantes	3, o 1 si lanzas solo la primera
6. Del borrador a la publicación	live:informe	1
7. Quita una capa y mide	live:informe con tres variantes	entre 2 y 4

Si no quieres gastar uso, cada lección te enseña la salida que grabamos nosotros, con su fecha y su modelo. Lo que tienen en común todos los caminos reales del curso (cómo se llama a tu Claude, qué se graba, qué hacer si tu plan no llega y lo que costó cada uno) está en una sola página al final de este módulo, El camino real, en una página, junto con un glosario de las palabras en inglés que vas a leer.

Lo que queda fuera

Las pasadas reales son pocas: sirven para ver qué cambia al quitar una capa en este caso, con este modelo y esta versión de Claude Code. No son una media ni una promesa para tu flujo.

Tampoco te protege de otro programa malicioso que se ejecute con tu mismo usuario del sistema. En la lección 6 verás por qué, y dónde tendría que estar esa frontera.