Un harness es el entorno que permite a un agente trabajar: las instrucciones que recibe, las herramientas que puede usar, el estado que conserva y las comprobaciones que determinan si terminó. El modelo aporta capacidad de razonamiento; ese entorno convierte la capacidad en un proceso que se puede dirigir y revisar.
En el video del 25 de mayo de 2026 expliqué este concepto con tres pilares: repositorio, orquestación y verificación. La pregunta práctica es sencilla: si mañana retomas un proyecto en otra conversación, ¿el agente sabrá dónde está, qué falta y cómo comprobar su trabajo?
Video completo y recorrido del arnés
Mira la explicación del punto de entrada del agente, la orquestación multiagente y el mapa de los tres pilares. Es una explicación de arquitectura y criterios de trabajo; no una medición de rendimiento de un repositorio implementado durante el video.
Qué problema resuelve un harness
Un agente puede escribir una función correcta y aun así equivocarse de archivo, ignorar una restricción del proyecto o dar una tarea por terminada sin probarla. También puede perder tiempo reconstruyendo decisiones que ya tomaste la semana anterior.
El arnés reduce esa fricción con información concreta. Define dónde buscar, qué acciones están disponibles y qué evidencia debe producir. Para entender la parte anterior a todo esto, revisa cómo funciona el ciclo de un agente de IA.
| Parte del entorno | Pregunta que debe resolver | Ejemplo práctico |
|---|---|---|
| Contexto | ¿Qué estamos intentando conseguir? | Objetivo, restricciones y estructura del proyecto |
| Herramientas | ¿Qué puede hacer el agente? | Leer archivos, ejecutar pruebas o consultar un servicio |
| Memoria y estado | ¿Qué se decidió y qué falta? | Decisiones, tareas pendientes y resultados comprobados |
| Verificación | ¿Cómo sabemos que funciona? | Un caso reproducible, una prueba o una captura de la interfaz |
Estos elementos se relacionan. Una herramienta sin instrucciones de uso puede aplicarse a la cuenta incorrecta. Una memoria desactualizada puede llevar a repetir un error. Una prueba que solo confirma que existe un archivo no demuestra que el usuario pueda completar su tarea.
Pilar 1: un repositorio que explique cómo trabajar
El repositorio sirve como espacio de trabajo y como punto de continuidad. No tiene que ser un proyecto enorme de software: también puede contener un sistema de contenido, una investigación o los procedimientos de un negocio.
Mi propuesta del video es mantener un punto de entrada breve y archivos separados para el detalle. El documento principal orienta; las referencias amplían cuando la tarea las necesita. Copiar todo el historial en cada sesión aumenta el material que hay que interpretar y puede esconder lo importante.
CLAUDE.md y AGENTS.md: una diferencia que conviene corregir
Claude Code carga CLAUDE.md; no lee AGENTS.md automáticamente como un sustituto equivalente. Si quieres compartir instrucciones entre herramientas, la documentación de memoria de Claude Code indica que puedes importarlas desde CLAUDE.md. Por ejemplo, el contenido de ese archivo puede incluir esta línea:
@AGENTS.md
La línea va en el archivo real, fuera de un bloque de código Markdown. Después comprueba que las instrucciones estén cargadas. Tener un documento en una carpeta no significa que cualquier agente lo haya leído.
Qué guardaría en cada archivo
Esta estructura es una propuesta editorial para aplicar lo explicado en el video; los nombres auxiliares no son requisitos del producto:
proyecto/
CLAUDE.md
AGENTS.md
tareas.json
progreso.md
decisiones/
pruebas/
En las instrucciones pondría objetivo, rutas importantes y comandos de comprobación. En las tareas, el resultado esperado y su estado. En el progreso, qué cambió, qué se comprobó y qué queda pendiente. En las decisiones, el motivo de una elección que probablemente habrá que recordar.
Un script de inicio puede revisar dependencias y el estado de las pruebas. Es útil para distinguir un problema previo de uno introducido durante el trabajo. Si algo ya falla, hay que registrarlo; no ocultarlo ni atribuirlo automáticamente al último cambio.
Menos herramientas puede significar menos confusión
Durante el video menciono el caso de d0, el agente de Vercel. La empresa publicó cómo redujo su conjunto de herramientas. El caso sirve para cuestionar si cada herramienta añade una capacidad necesaria o varias formas ambiguas de hacer lo mismo.
La recomendación que extraigo es evaluar el conjunto con tareas reales. No hay una cantidad ideal universal. Una herramienta amplia de terminal puede ser poderosa, pero también exige permisos y un entorno adecuados; su existencia no justifica dar acceso irrestricto a todo el sistema.
Antes de conectar otra integración, escribiría una frase: “La necesito para obtener este dato o ejecutar esta acción”. Si no puedes completar la frase, probablemente conviene ordenar el flujo antes de añadirla.
Pilar 2: repartir trabajo con responsabilidades claras
En el video separo planificación, implementación y revisión. Esa separación ayuda a que una tarea no dependa únicamente de la misma conversación que propuso la solución.
Un coordinador puede definir el alcance. Un agente puede implementar una parte acotada. Otro puede revisar el resultado contra los requisitos. Pero crear varios agentes también añade coordinación y consumo. Para una corrección pequeña, uno puede ser suficiente.
La división funciona mejor cuando cada encargo tiene una entrada, un resultado y un límite claros. Por ejemplo: “revisa si el formulario funciona con teclado y entrega pasos para reproducir fallos” es más comprobable que “revisa todo”. Si dos tareas dependen del mismo archivo o de una decisión todavía pendiente, ejecutarlas simultáneamente puede producir conflictos.
En la guía del equipo multiagente con OpenClaw puedes ver otra aplicación de roles. Cambiar de herramienta requiere adaptar configuración, permisos y comunicación; no basta con copiar una carpeta y asumir un comportamiento idéntico.
Pilar 3: terminar significa mostrar evidencia
La verificación tiene que corresponder al resultado que espera la persona. Si pediste una interfaz usable en móvil, una compilación correcta es necesaria pero insuficiente. Hay que abrirla con el ancho correspondiente y completar el recorrido.
Para código, considera pruebas de comportamiento, tipos y reglas del proyecto cuando correspondan. Para una investigación, conserva fuentes y explica cómo llegaste al dato. Para una pieza visual, revisa el archivo final. Las pruebas de navegador con Playwright muestran por qué una captura puede revelar algo que el texto del agente no detectó.
También conviene registrar qué no se pudo comprobar. Un servicio sin credenciales puede impedir una prueba real; un ejemplo simulado no debe presentarse como una integración verificada.
Cómo empezar con un arnés pequeño
Elige una tarea que repites. Documenta sus entradas y define qué considerarás terminado. Después realiza una ejecución, guarda la evidencia y observa dónde el agente tuvo que adivinar.
Corrige esa ambigüedad en el lugar adecuado. Si faltaba una ruta, documenta la ruta. Si el procedimiento era confuso, mejora el procedimiento. Si una acción necesita una restricción técnica, configura esa restricción; escribir una advertencia en un archivo no equivale a imponerla.
Conserva solo aprendizajes comprobados y elimina instrucciones que ya no aplican. Para ampliar la continuidad del conocimiento, revisa la wiki con Claude Code y Obsidian. Si quieres seguir construyendo estos sistemas, los recursos y la comunidad están en Imperio Agéntico en Skool, y puedes suscribirte al canal de YouTube.
Preguntas frecuentes
¿Qué es un harness en un agente de IA?
Es el entorno que organiza instrucciones, herramientas, estado y verificaciones para que el agente pueda trabajar. El modelo razona dentro de ese entorno; el harness ayuda a convertir sus decisiones en acciones y resultados comprobables.
¿Claude Code lee AGENTS.md automáticamente?
No lo trata automáticamente como sustituto de CLAUDE.md. Puedes importar el archivo compartido con una línea @AGENTS.md dentro de CLAUDE.md y comprobar que se haya cargado. Guardar instrucciones sin conectarlas al punto de entrada no garantiza que el agente las utilice.
¿Necesito varios agentes para tener un buen harness?
No. Una tarea acotada puede funcionar bien con un solo agente. Repartir trabajo aporta valor cuando hay encargos independientes, responsabilidades claras y una forma de integrar y comprobar las entregas. También añade coordinación y consumo.
¿Qué debería guardar como memoria del proyecto?
Objetivos, restricciones, decisiones vigentes, rutas importantes y estado de las tareas. Guarda la evidencia de lo que se comprobó y referencias al detalle. Evita convertir el documento principal en un historial completo de intentos descartados.
¿Más herramientas hacen mejor a un agente?
Solo si aportan capacidades necesarias y están bien definidas. Herramientas redundantes pueden añadir ambigüedad. Evalúa el conjunto con tareas reales y configura el acceso que requiere cada acción, especialmente si una herramienta permite ejecutar comandos amplios.
¿Cómo sé que el agente terminó una tarea?
Define antes qué resultado necesitas y qué evidencia lo demuestra. Para una web puede ser completar el recorrido en móvil; para una integración, una prueba con el servicio; para una investigación, datos y fuentes revisables. El mensaje de finalización del agente no reemplaza esas comprobaciones.