El modelo es la CPU. El arnés es el sistema operativo

Durante mucho tiempo hemos hablado de agentes como si el agente fuese el modelo.

No lo es.

El modelo es una parte crítica, claro. Igual que la CPU es una parte crítica de un ordenador. Pero nadie serio evalúa un ordenador mirando sólo el procesador. Mira también la RAM, el sistema operativo, los permisos, el disco, la red, los procesos en ejecución, los logs, los drivers y las herramientas que tiene instaladas.

Con agentes pasa exactamente lo mismo.

Un modelo potente sin entorno es una CPU encima de una mesa.

Puede ser impresionante. No es todavía un sistema útil.

Por eso me gusta pensar en harness engineering con una analogía muy simple:

• el modelo es la CPU,
• la ventana de contexto es la RAM,
• el harness es el sistema operativo,
• y el agente es la aplicación que corre encima.

La CPU importa. Mucho.

Pero lo que hace que el trabajo sea fiable no es sólo la CPU. Es el sistema completo que decide qué ve el proceso, qué puede tocar, cómo persiste estado, cómo se recupera de errores y qué señales recibe antes de declarar que ha terminado.

Eso es un harness.

Diagrama: el agente útil aparece cuando modelo, contexto y harness trabajan como un sistema.

Agent = model + harness

La definición más corta es esta:

Agent = Model + Harness

El harness es todo lo que rodea al modelo para convertirlo en un sistema operativo:

• instrucciones permanentes,
• contexto del proyecto,
• memoria,
• herramientas,
• permisos,
• workflows,
• evaluadores,
• tests,
• logs,
• checkpoints,
• recuperación de sesión,
• y reglas sobre cuándo puede actuar o debe parar.

Si vienes de producto o ingeniería, esto no debería sonar raro.

Si vienes de riesgo, seguridad o compliance, menos todavía.

Un harness también puede verse como un marco de control: políticas, límites, puntos de revisión, trazabilidad y evidencias para que un sistema autónomo opere dentro de márgenes aceptables.

Lo nuevo no es la idea de control.

Lo nuevo es que ahora el sistema controlado no es sólo una aplicación tradicional. Es un modelo capaz de leer, decidir, escribir código, ejecutar comandos, abrir PRs, navegar por una web, llamar herramientas y, a veces, convencerse a sí mismo de que algo está terminado cuando no lo está.

Ahí empieza la disciplina.

Diagrama: el modelo genera; el harness convierte esa capacidad en operación controlada.

Por qué esto explotó en 2026

OpenAI puso el término sobre la mesa en febrero de 2026 con su artículo sobre harness engineering con Codex. Lo interesante no era sólo la cifra —un producto interno de alrededor de un millón de líneas sin código escrito a mano— sino el cambio de rol.

Los humanos no estaban compitiendo con el agente a ver quién tecleaba más rápido.

Estaban diseñando el entorno en el que Codex podía trabajar:

• documentación distribuida en el repo,
• flujos de dependencias,
• tests estructurales,
• planes ejecutables,
• feedback automático,
• y una cultura donde el humano revisa el sistema que produce código, no cada línea como si siguiera siendo 2018.

Anthropic llegó al mismo problema desde otro sitio. En su pieza sobre harnesses para agentes largos y después en harness design para aplicaciones largas, el foco no era tanto la escala del repo como la calidad del resultado durante sesiones de horas.

Su conclusión fue muy sana: cuando el agente se evalúa a sí mismo, tiende a ser demasiado indulgente.

O dicho menos fino: a veces construye algo roto y luego se felicita por ello.

Por eso separaron roles: planner, generator, evaluator. Uno planifica, otro construye, otro prueba como usuario real. No porque tres agentes suenen más futuristas que uno, sino porque separar quien hace de quien juzga reduce sesgos.

ThoughtWorks, por su parte, formalizó el vocabulario en el artículo de Birgitta Böckeler sobre harness engineering para usuarios de coding agents: guías antes de actuar, sensores después de actuar; controles deterministas y controles inferenciales.

Y LangChain enseñó un dato muy limpio: en Terminal-Bench 2.0, su agente pasó de 52,8% a 66,5% cambiando el harness y manteniendo el modelo fijo. No cambiaron la CPU. Cambiaron el sistema operativo.

Ese es el punto.

El harness no es un prompt largo

Este matiz importa.

Muchos equipos siguen intentando resolver problemas de agentes con más prompt:

• una instrucción más,
• un párrafo más,
• una regla más,
• una advertencia más,
• una lista de “no hagas esto” más larga.

Eso ayuda hasta cierto punto.

Pero un harness serio no es un prompt obeso. Es una estructura.

Un AGENTS.md, un CLAUDE.md o unas rules de Cursor pueden formar parte del harness, pero no son el harness entero. Son más bien la documentación que el proceso lee al arrancar.

El harness completo incluye cosas mucho menos glamourosas y mucho más importantes:

• un npm test que falla cuando debe fallar,
• un linter con mensajes que el agente pueda corregir,
• un hook que bloquea comandos destructivos,
• un CI que no acepta atajos,
• un archivo de progreso que permite retomar una tarea,
• una lista de features con estados verificables,
• un sandbox sin secretos,
• un reviewer separado,
• y logs suficientes para saber qué pasó.

Esto conecta bastante con lo que escribí en Claude Code Hooks: cómo montar una red de seguridad base. La idea de fondo era la misma: el comportamiento correcto no se pide; se automatiza.

Si quieres que el agente formatee, no se lo recuerdes cada vez. Pon un hook.

Si quieres que no toque producción, no confíes en su buena educación. Bloquéalo.

Si quieres que pruebe lo que cambia, no le preguntes si “cree” que está bien. Dale una verificación ejecutable.

Los artefactos que empiezan a repetirse

Cuando miras los enfoques de OpenAI, Anthropic, ThoughtWorks, Vercel o LangChain, cambian los nombres pero se repiten las piezas.

La primera es documentación local y versionada.

Archivos tipo AGENTS.md, CLAUDE.md, .cursorrules o skills específicas. No como literatura corporativa, sino como onboarding operativo para un agente que entra en mitad del sprint y necesita saber cómo se trabaja aquí.

La segunda es estado persistente.

Un agente con una ventana de contexto finita necesita saber qué está hecho, qué falta, qué decisiones siguen vigentes y qué se rompió antes. Anthropic lo resolvió con listas estructuradas de features, verificaciones y estados. En otros sistemas puede ser un issue tracker, un JSON, un log append-only o un documento de progreso.

Lo importante no es el formato.

Lo importante es que el agente no empiece cada sesión como si hubiera sufrido amnesia.

La tercera es verificación ejecutable.

Tests, linters, typecheckers, Playwright, benchmarks, validadores de contrato, scripts de smoke test. Todo lo que convierte “parece bien” en “hemos observado esto”.

La cuarta es separación de responsabilidades.

Planner, builder, evaluator. O humano, agente, CI. O agente principal y subagentes. La forma concreta puede variar, pero la idea es estable: no conviene que la misma instancia haga el plan, ejecute, se evalúe y se perdone.

La quinta es control de herramientas.

Vercel publicó una pieza muy interesante sobre cómo quitó el 80% de las herramientas a su agente y mejoró el resultado. Esto va contra la intuición de “más herramientas = más capacidad”.

En agentes, demasiadas herramientas también significan más confusión, más rutas malas, más coste de selección y más superficie de error.

Un buen harness no consiste en darle todo al agente.

Consiste en darle lo justo, en el momento correcto y con el feedback adecuado.

Diagrama: el harness se materializa en artefactos bastante concretos, no en una idea abstracta.

Tres formas sanas de pensarlo

Yo lo separaría en tres escuelas prácticas.

No porque haya que elegir una como religión, sino porque cada una resuelve un problema distinto.

Diagrama: cada enfoque optimiza una cosa distinta: escala, calidad o vocabulario compartido.

1. El enfoque entorno primero

Este es el patrón más parecido al de OpenAI con Codex.

El repo es el harness.

La estructura del código, los archivos de instrucciones, los tests, el CI, las reglas de dependencia y los pipelines forman un entorno donde el agente puede moverse con mucha autonomía.

Esto funciona especialmente bien cuando:

• el código base es grande,
• los patrones están claros,
• puedes invertir en infraestructura,
• y quieres muchas tareas en paralelo.

El riesgo es creer que los tests capturan todo.

No lo hacen.

Un sistema puede compilar, pasar CI y seguir siendo una mala decisión de producto o una mala abstracción técnica.

Por eso este enfoque necesita algo que en equipos buenos ya existía antes de la IA: criterio de arquitectura y ownership real.

2. El enfoque multiagente

Este es el patrón de Anthropic.

Separar quien planifica, quien construye y quien evalúa. Meter contratos de sprint. Usar navegador para probar como usuario. Hacer que el evaluador sea difícil de impresionar.

Es más caro y más lento.

Pero si el coste de sacar algo roto es alto, puede compensar.

Aquí la clave no es “usar varios agentes” porque suena avanzado. La clave es separar sesgos.

En tareas largas lo expliqué en En tareas largas, el rendimiento del agente depende menos del modelo y más del arnés: cuando una ejecución dura horas, deja de ser una conversación larga y empieza a ser un sistema operacional.

Y los sistemas operacionales necesitan handoffs, checkpoints y evaluación externa.

3. El enfoque taxonómico

Este es el enfoque ThoughtWorks.

No te vende una arquitectura cerrada. Te da un mapa.

Por un lado tienes feedforward: lo que das al agente antes de actuar para aumentar la probabilidad de que lo haga bien.

Por otro lado tienes feedback: lo que observa después de actuar para corregir.

Y luego puedes separar controles computacionales de controles inferenciales.

Computacional es un typecheck, un linter, un test, un script determinista.

Inferencial es otro modelo revisando semántica, intención, UX, arquitectura o cumplimiento del objetivo.

Mi regla sería esta: empieza siempre por lo computacional barato y rápido. Luego añade revisión inferencial donde lo determinista no llegue.

No tiene sentido pagar a un segundo LLM para descubrir que TypeScript no compila.

Sí puede tener sentido usarlo para detectar que una solución compila, pero rompe el diseño o no resuelve lo que se pidió.

Diagrama: no todos los controles hacen lo mismo. Un buen harness mezcla guías antes de actuar y sensores después de actuar.

Opus 4.8 cambia el peso del harness, no lo elimina

Aquí viene la parte interesante de 2026.

Cada generación nueva de modelos está quitando trabajo al harness.

Claude Opus 4.5 necesitaba más andamiaje para ciertas tareas largas. Opus 4.6 permitió simplificar piezas. Opus 4.7 empezó a verificar mejor sus propias salidas. Y Claude Opus 4.8, publicado el 28 de mayo de 2026, empuja otra vez en esa dirección.

Anthropic lo describe como más fiable en tareas agentic, con mejor juicio, mejor uso de herramientas y menos tendencia a dejar pasar fallos en su propio código. También introduce cosas relevantes para harnesses reales: control de esfuerzo, dynamic workflows en Claude Code y la posibilidad de actualizar instrucciones de sistema durante una tarea sin romper ciertos patrones de caché.

Esto importa mucho.

Si el modelo ya planifica mejor, quizá no necesitas tanta descomposición manual.

Si usa herramientas con menos errores, quizá puedes simplificar middleware.

Si verifica mejor su propio trabajo, quizá el evaluador externo puede centrarse en menos cosas.

Pero cuidado con sacar la conclusión equivocada.

Que el modelo mejore no significa que el harness desaparezca.

Significa que cambia de forma.

El harness deja de compensar torpezas básicas y empieza a concentrarse en cosas más estructurales:

• permisos,
• estado,
• trazabilidad,
• integración con el repo,
• evaluación de negocio,
• seguridad,
• coste,
• y control operacional.

La CPU mejora. El sistema operativo sigue haciendo falta.

Diagrama: las implementaciones cambian, pero los principios se repiten.

El harness también se pudre

Hay una idea que me parece especialmente importante: harness decay.

Cada pieza de un harness codifica una suposición sobre lo que el modelo no sabe hacer bien.

Cuando el modelo cambia, esa suposición puede caducar.

Lo que ayer era una barandilla necesaria mañana puede ser latencia, tokens y ruido.

Esto ya lo estamos viendo:

• Vercel quitó herramientas y mejoró,
• Anthropic simplificó partes de su arquitectura al mejorar Opus,
• LangChain habla de perfiles de harness por modelo,
• y cualquier persona que mantenga agentes reales sabe que una instrucción útil en marzo puede ser una interferencia en junio.

La lección práctica es incómoda pero clara:

Diseña el harness para poder borrarlo.

Cada componente debería tener una razón de existir y, si se puede, una forma de medir si sigue aportando.

Si un hook no evita fallos reales, sobra.

Si una instrucción ya no cambia comportamiento, sobra.

Si un evaluador cuesta mucho y no detecta nada que no detecten los tests, sobra.

Si una herramienta confunde más de lo que ayuda, sobra.

Esto no va de construir catedrales de control alrededor del modelo.

Va de construir el mínimo entorno que produce trabajo fiable hoy, sabiendo que mañana habrá que recortarlo.

Diagrama: cada generación de modelo puede convertir partes del harness en coste muerto. Hay que diseñar para borrar.

Cómo empezaría en un equipo normal

No hace falta copiar el sistema de OpenAI ni montar tres agentes el primer día.

Para un equipo normal, yo empezaría mucho más simple.

Primero: un archivo de contexto corto en el repo.

No 800 líneas de filosofía. Algo que diga:

• qué es este proyecto,
• cómo se ejecuta,
• cómo se prueba,
• qué convenciones importan,
• qué zonas son delicadas,
• qué no debe tocar el agente sin permiso.

Segundo: verificación barata.

Un comando claro para build, test, lint y typecheck. Si el agente no puede ejecutar eso, o si el resultado no es fiable, todavía no tienes harness. Tienes conversación.

Tercero: permisos y zonas rojas.

Producción, secretos, migraciones destructivas, pagos, auth, datos personales. Todo eso debe tener controles explícitos.

Cuarto: estado persistente para tareas largas.

Si una tarea puede durar más de una sesión, necesita un archivo de progreso, issues bien definidos o una checklist verificable. No confíes en que el contexto aguante por magia.

Quinto: un evaluador separado cuando la calidad lo justifique.

Puede ser otro modelo, una persona, Playwright, un script de smoke test o una combinación. Lo importante es que el agente no sea el único que decide que ha terminado.

Sexto: revisiones periódicas del harness.

No para añadir siempre más cosas. También para borrar.

Esta parte es la que más se nos va a olvidar.

La parte verdaderamente escasa

En 2025 parecía que lo escaso era conseguir que un modelo escribiera código.

En 2026 eso ya no es lo interesante.

Lo escaso es diseñar el entorno correcto para que ese código sea útil, mantenible, seguro y verificable.

Por eso harness engineering no es una moda de naming.

Es una forma bastante concreta de admitir que los agentes no son magia autónoma. Son sistemas. Y como sistemas necesitan arquitectura, límites, observabilidad y criterio.

La pregunta buena ya no es sólo “qué modelo usamos”.

Es:

• qué contexto le damos,
• qué herramientas le quitamos,
• qué señales recibe,
• qué memoria persiste,
• qué verificaciones no puede saltarse,
• qué acciones requieren permiso,
• y cómo sabemos que ha hecho trabajo real.

Ahí está el trabajo serio.

El modelo es la CPU.

El harness es el sistema operativo.

Y el agente útil aparece cuando dejas de mirar sólo benchmarks y empiezas a diseñar el sistema completo.