Harness Engineering: el Arnés Importa Más que el Modelo

Llevo meses escribiendo en este blog sobre piezas sueltas: cómo reduje un 80 % mi consumo de tokens, cómo monto agent teams, cómo dejo que los agentes escriban código de producción con SDD. Todas esas piezas tienen un nombre común: harness engineering. El concepto no es nuevo —la idea de que lo que rodea al modelo pesa tanto o más que el propio modelo lleva tiempo rondando, sobre todo entre quien construye y evalúa agentes—, pero estas últimas semanas ha pasado de tecnicismo de pasillo a término que aparece, casi a la vez, en los blogs de OpenAI, Anthropic, LangChain y MongoDB.

Si lo has visto pasar y no tienes claro qué es, ni por qué de repente todo el mundo habla de ello, este artículo es para ti.

La ecuación que lo resume todo

Empecemos por la única fórmula que necesitas recordar:

Agente = Modelo + Harness

El modelo es el LLM: Claude, GPT, Gemini. El harness —“arnés”, en inglés— es todo lo demás: el código, la configuración y la lógica de ejecución que envuelven al modelo y no son el modelo. Como lo resume LangChain con una frase que se ha vuelto lema: “si no eres el modelo, eres el arnés”.

El nombre es una metáfora deliberada. Un arnés es el conjunto de riendas, silla y bocado con el que controlas a un caballo. Tienes un animal con una potencia enorme pero sin dirección; el arnés no lo hace más fuerte, lo hace gobernable. Eso es exactamente lo que hace el harness con un LLM: no lo hace más listo, lo hace fiable.

Y aquí está el giro que ha hecho viral el término: el cuello de botella ya no es la inteligencia del modelo, es la calidad del arnés.

Por qué esto importa ahora (y no hace un año)

Hay un dato que circula en todos los artículos sobre el tema y que conviene interiorizar. Un estudio de Stanford y Tsinghua midió el mismo modelo, sin tocarlo, dentro de distintos arneses. El resultado: diferencias de rendimiento de hasta 6x según cómo estuviera diseñado el envoltorio. Mismo cerebro, seis veces mejor o peor según las riendas.

MongoDB lo lleva un paso más allá con una comparación que escuece. ¿Recuerdas el famoso diagrama de Sculley sobre sistemas de machine learning en producción? Aquel donde el recuadro de “ML code” era una caja minúscula rodeada de un océano de infraestructura: recogida de datos, serving, monitorización, gestión de recursos. Con los agentes pasa lo mismo. La interacción con el LLM es apenas el 1-2 % del trabajo de ingeniería real. El otro 98 % es arnés.

Durante 2024 y buena parte de 2025 el discurso era “espera al próximo modelo”. Cada nuevo modelo puntero tapaba las carencias del anterior. Pero los modelos se han estabilizado en un rango de capacidad altísimo y muy parecido entre sí, y de repente la pregunta interesante ya no es qué modelo usas sino qué has construido a su alrededor. Ahí ha nacido el harness engineering como disciplina con nombre propio.

Hay un efecto secundario precioso de pensar así. Si tu valor está en el arnés y no en el modelo, el modelo se convierte en una pieza intercambiable. Como lo describe BettaTech en su vídeo sobre el tema: tienes un sistema al que simplemente le cambias el cerebro. Sale un modelo mejor, o más barato, y lo enchufas sin reescribir nada. Tu inversión —el arnés— se queda.

La anatomía de un arnés

¿Qué hay exactamente dentro del 98 %? MongoDB lo divide en seis capas, y me parece la mejor manera de ordenarlo que he visto:

1. Estado y persistencia. Guarda el contexto de ejecución, los checkpoints, las salidas intermedias. Permite reanudar desde donde se rompió en lugar de empezar de cero.
2. Seguridad y gobernanza. Quién es el agente cuando actúa y qué se le permite hacer. Cuando llama a una herramienta o a una API, tiene que hacerlo con la identidad y los permisos del usuario correcto —no con acceso total a todo—, ceñirse a lo mínimo que necesita para su tarea, y dejar un registro de cada acción para poder revisarla después. Es la capa donde se atasca la mayoría de proyectos de empresa antes de llegar a producción.
3. Orquestación y uso de herramientas. El bucle del agente: percibir → planificar → actuar → llamar herramienta. Coordinación, rate limiting, ejecución en sandbox.
4. Memoria. Memoria de trabajo (el turno actual) y memoria persistente (caché a corto plazo más almacenes a largo plazo: episódica, conversacional, de entidades).
5. Observabilidad. Registra decisiones, trazas de razonamiento, llamadas a herramientas. No es lo mismo que monitorización: la observabilidad pregunta “¿fue correcta la decisión?”, no “¿respondió?”.
6. Evals. Las pruebas que miden si el agente hace bien su trabajo. No corren en directo con cada petición: se ejecutan aparte, sobre lo que registró la observabilidad, y son las que te dicen si el agente está lo bastante fino para ponerlo en producción.

No hace falta que montes las seis el primer día. Pero conviene saber que existen, porque la mayoría de la gente empieza y termina en la capa 3 y se pregunta por qué su agente “a veces falla en lo más simple”.

Guías y sensores: el marco de Martin Fowler

Para el desarrollador que usa agentes de código a diario —que es donde yo vivo— el marco más útil no es el de las seis capas, sino el de Martin Fowler. Él divide el arnés en dos tipos de control:

Guías (feedforward). Controles que actúan antes de que el agente haga nada. Anticipan su comportamiento y lo dirigen. Son tus CLAUDE.md y AGENTS.md, las convenciones de código, la documentación de arquitectura, las instrucciones de las skills. Le dices al caballo por dónde ir antes de que arranque.

Sensores (feedback). Controles que actúan después de que el agente actúa, y le permiten autocorregirse. Linters, tests, type-checks, un navegador headless con Playwright que verifica que la UI funciona. El agente actúa, el sensor detecta el problema, el agente corrige.

Los sensores son especialmente potentes cuando emiten señales diseñadas para que las consuma un LLM. Un mensaje de linter que no solo dice “error en la línea 42” sino “error en la línea 42, esto se arregla así” cierra el bucle de autocorrección sin que tú intervengas.

Fowler añade un matiz importante sobre el coste. La ejecución de estos controles puede ser computacional —determinista, rápida, barata: un linter, un test unitario— o inferencial —semántica, lenta, cara: otro LLM revisando el código—. La recomendación práctica es distribuirlos en el tiempo: las verificaciones baratas antes de integrar, las caras después, en el pipeline. No pongas un agente revisor a leer cada línea cuando un type-check te lo dice gratis.

La lección contraintuitiva: menos es más

Aquí viene la parte que casi todo el mundo se equivoca al principio, yo incluido.

La intuición dice: si el arnés es lo que importa, hago un arnés enorme. Le doy al agente cincuenta herramientas hiperespecializadas, le meto tres MCP servers, le escribo un CLAUDE.md de 600 líneas, le acoto el razonamiento paso a paso. Arnés supervitaminado, agente imparable.

Pasa exactamente lo contrario. Cuanto más complejo haces el arnés, peor funciona.

El ejemplo que cita todo el mundo es de Vercel. Tienen un agente llamado D0 —el primo de v0— para hacer queries y analizar grandes cantidades de datos. La primera versión seguía la intuición: herramientas especializadas para escribir SQL, para conectarse a cada base de datos, wrappers que guiaban el razonamiento del modelo con precisión quirúrgica. La idea era simplificarle el trabajo al modelo.

Luego probaron lo contrario: quitarle los ruedines. Eliminaron el 80 % de las herramientas y le dejaron solo utilidades Unix de toda la vida —grep para buscar en ficheros, cat para leerlos, ls para listar directorios— y que el modelo se buscara la vida.

El resultado: la tasa de éxito subió del 80 % al 100 %, el consumo de tokens cayó alrededor de un 50 %, y la latencia se desplomó de 724 a 141 segundos. Misma capacidad de modelo. La versión con herramientas simples ganó en todas las peticiones.

LangChain reporta lo mismo desde otro ángulo: cambios solo en el arnés movieron a su agente de código del fondo de la tabla al top 5 de Terminal Bench 2.0. Y el bufete legal Harvey dobló la precisión de sus agentes solo optimizando el arnés.

¿Por qué funciona así? Porque cada herramienta que añades es una decisión más que el modelo tiene que tomar, una descripción más que ocupa contexto, un camino más donde equivocarse. Un modelo de frontera sabe usar grep. Lo que no sabe es elegir bien entre tus cuarenta herramientas a medida con nombres parecidos. La complejidad del arnés es deuda, no activo.

Esto enlaza directo con todo lo que conté sobre optimización de tokens: cada herramienta tiene una ventana óptima estrecha, y fuera de ella cuesta más de lo que aporta.

El otro enemigo: el contexto que se pudre

Hay un segundo problema que cualquiera que haya usado Claude Code en sesiones largas ha sufrido: cuanto más rato llevas, más tonto se vuelve el agente.

Y no es impresión tuya. A pesar de que las ventanas de contexto son hoy enormes —200K, un millón de tokens—, la degradación de resultados aparece mucho antes de que la ventana se llene. Hay un issue muy comentado en GitHub que sitúa el inicio de la degradación en torno al 20 % de ocupación y recomienda limpiar o abrir ventana nueva a partir del 40 %. El espacio está, pero la calidad no.

Por eso la gestión de contexto es una pieza central del arnés, y por eso la memoria no es opcional. La idea es sencilla de visualizar: la ventana de contexto es un recuadro pequeño dentro del modelo, y tu trabajo es sacar cosas fuera —a un sistema de ficheros, a una base de datos— para que ese recuadro nunca esté lleno. El agente consulta la memoria externa cuando la necesita en lugar de arrastrarla siempre.

Esto es el patrón filesystem-as-memory, y es exactamente lo que uso en mi vault con el directorio .agent/: un memory.md que es un índice, tareas completadas archivadas por fecha, conocimiento reutilizable en ficheros aparte. El agente no carga todo: sigue los enlaces que necesita. Y no hace falta montarlo a mano: está creciendo un ecosistema de herramientas de memoria para agentes —Engram, claudemem y otras— que empaquetan este patrón y lo gestionan por ti. Anthropic ha publicado guías específicas sobre cómo construir arneses para sesiones largas de codificación, y casi todas giran alrededor de lo mismo: un fichero JSON estructurado con las tareas pendientes, del que los agentes van tirando, y subagentes que arrancan con el contexto vacío en lugar de heredar el del padre.

Ese último punto es clave. Cuando lanzas un subagente, lo que no quieres es que herede los 80K tokens de contexto que ya tiene el orquestador. Quieres que arranque limpio, con solo la información de la tarea concreta que le toca. Contexto menos lleno, agente más eficiente. Es la base de los agent teams que monté.

Verificación: que lo demuestre, no que lo diga

Llegamos al problema más peligroso de todos, y el que el arnés tiene que resolver sí o sí.

No puedes fiarte de lo que te dice la IA. El código generado por un LLM puede parecer 100 % convincente y tener un fallo sutil enterrado donde no cumple su objetivo. Recuerda para qué está entrenado el modelo: para parecer verosímil, para darte respuestas que parecen ciertas. Que lo parezcan no significa que lo sean.

Así que la pregunta de diseño es: ¿cómo haces que el agente no se limite a decir “hecho”, sino que lo demuestre?

La respuesta es darle herramientas de verificación y exigir que las use. Tests automatizados —escritos por ti o por él, pero que pasen de verdad—. Un navegador headless que abre la app y prueba el flujo. Las DevTools de Chrome. Nunca, jamás, dejes que la única fuente de verdad sobre si algo funciona sea el propio agente que lo construyó. Tiene que demostrarlo, y el software tiene la suerte de ser verificable: aprovéchalo.

Como el agente genera cada vez más código y revisarlo todo a mano no escala, está cuajando una capa extra: usar IA como revisor de IA. Añadir al arnés instrucciones explícitas sobre cómo validar y revisar el trabajo, y agentes dedicados solo a eso. Es la capa de sensores de Fowler llevada a su extremo: un agente revisor dentro del propio pipeline, como el que monté en mi pipeline de 9 agentes.

Cómo se ve un arnés de verdad

Bajemos a tierra. Un proyecto con un arnés decente, hoy, con Claude Code, se parece a esto:

mi-proyecto/
├── .claude/
│   └── agents/
│       ├── implementador.md   # escribe código
│       ├── lider.md           # orquesta
│       └── revisor.md         # verifica
├── CLAUDE.md                  # punto de entrada: reglas comunes
├── docs/
│   ├── arquitectura.md
│   └── convenciones.md
├── .agent/
│   ├── memory.md              # índice de memoria persistente
│   └── tasks/                 # tareas estructuradas
└── src/

Tres ideas que rescatar de ese esqueleto:

El arnés vive en el repositorio. No es configuración que tengas tú en tu máquina: es parte del proyecto, versionada en git. Esto tiene una consecuencia bonita: el arnés es autoeditable. Si detectas que un agente no hace bien su trabajo, cambias su prompt o sus reglas en el repo y la próxima vez funciona mejor. El arnés evoluciona con el proyecto.

El protocolo es obligatorio. Cada agente, para formar parte del arnés, sigue las mismas reglas: lo primero que hace es leer CLAUDE.md y los documentos de arquitectura y convenciones. Sin protocolo común, no hay equipo, hay agentes sueltos.

Orquestador y obreros. Un agente líder que coordina y spawnea, y subagentes pequeños que hacen el trabajo con contexto mínimo. Es el modelo del sistema de investigación multiagente de Anthropic: el usuario manda la query, el orquestador delega iterativamente en subagentes que buscan y guardan en memoria, y al final el orquestador devuelve el resultado.

Mi consejo, y el de prácticamente todos los que escriben sobre esto: empieza de menos a más. No te montes los tres agentes y las seis capas el primer día. Un buen CLAUDE.md, un par de comandos de verificación que el agente esté obligado a ejecutar, y un fichero de memoria. Entiende cada pieza antes de añadir la siguiente. El arnés mínimo que entiendes bate al arnés completo que no controlas —es la misma lección de Vercel, otra vez.

Lo que esto significa para ti

Si tuviera que destilar todo el harness engineering en cuatro frases para llevar:

• El modelo es la pieza pequeña. Tu ventaja competitiva está en el arnés, no en qué LLM usas. Y como el arnés es tuyo, sobrevive a cada cambio de modelo.
• Más arnés no es mejor arnés. Menos herramientas, más generales, casi siempre ganan. La complejidad es deuda.
• El contexto se pudre antes de llenarse. Saca estado a memoria externa y arranca a los subagentes en limpio.
• Que lo demuestre. Sin verificación automatizada, no tienes un agente, tienes algo que suena convincente y poco más.

Y una observación final, medio personal. Cuando leí por primera vez “harness engineering” pensé que era otro término inflado para vender humo. Pero cuando lo miras de cerca, describe algo concreto y real: las skills, las reglas de navegación de código, la memoria en .agent/, los agent teams, las verificaciones obligatorias. Todo eso es arnés. La diferencia entre tratar a la IA como un chatbot al que le pides cosas y tratarla como un motor sobre el que construyes un sistema es, literalmente, esta disciplina.

El caballo siempre ha tenido la potencia. Lo que faltaban eran las riendas.

---

Si quieres profundizar: el artículo de Martin Fowler sobre harness engineering es la mejor fuente sobre el marco de guías y sensores; el de OpenAI cuenta el caso de un equipo de tres personas que pasó cinco meses sin escribir una línea a mano; y el de MongoDB tiene el desglose más claro de las seis capas. Si prefieres vídeo y en español, el de BettaTech explica el concepto con ejemplos muy claros.

P.D.: Si estás montando tu propio arnés para agentes, o no te convence algo de lo que cuento aquí, me encuentras en Twitter como @lm_martinbar. Y si quieres el contexto previo, este artículo es la continuación natural de cómo monto agent teams y SDD con OpenSpec.