Qué es un harness en IA y por qué pesa más que el modelo

Si usas un agente de código a diario, ya has visto la escena: le pides que arregle unos tests que fallan y, sin que le digas nada más, ejecuta la suite, lee el error, busca el fichero culpable, lo edita y vuelve a lanzar los tests. Parece que el modelo lo hace todo. No es así. El modelo decide; otra capa de software es la que ejecuta, recuerda, corta cuando hace falta y le devuelve los resultados para la siguiente decisión. Esa capa tiene nombre: harness.

La palabra viene del inglés, del arnés con el que se gobierna a un caballo: riendas, bocado, correas. El equipo que canaliza un animal potente pero impredecible en una dirección concreta. Aplicado a la IA, el harness es el conjunto de piezas que envuelve a un modelo para que pueda hacer trabajo de verdad en lugar de limitarse a escribir texto. En español a veces se traduce como "arnés", pero el término que se ha asentado entre desarrolladores es el original.

Este artículo es la base conceptual. No habla de ninguna herramienta concreta, sino del patrón que comparten todas. Si quieres ver el despiece de un caso real, con sus piezas y sus números, lo tienes en Cómo funciona Claude Code por dentro.

El modelo solo sabe hacer una cosa

Conviene empezar por lo que un modelo de lenguaje no es, porque ahí se entiende todo lo demás.

Un modelo es una función: entra texto, sale texto. Nada más. No tiene estado entre llamadas, así que no recuerda lo que pasó hace dos mensajes salvo que se lo vuelvas a pasar entero. No ejecuta comandos. No abre ficheros. No consulta una base de datos. No sabe qué hora es. Le pides que "lance los tests" y lo único que puede producir es la cadena de caracteres que describe esa intención. Ejecutarla está fuera de su alcance.

Esto choca con la sensación que da usar un agente, donde el modelo aparenta tener manos. No las tiene. Lo que ocurre es que alguien ha construido alrededor un sistema que interpreta esa intención, ejecuta la acción real, captura el resultado y se lo devuelve al modelo como nuevo texto de entrada. Repetido en bucle, eso es un agente.

La fórmula que se ha vuelto estándar para describirlo es directa:

Agente = Modelo + Harness

El modelo aporta el razonamiento. El harness aporta todo lo demás: la capacidad de actuar, de recordar, de mantenerse dentro de unos límites y de seguir adelante cuando la tarea dura más que una sola respuesta. Y de ahí sale el corolario que más cuesta aceptar: si no estás entrenando el modelo, lo que estás construyendo o configurando es el harness.

Qué hay dentro de un harness

Todos los harness, por distintos que parezcan, resuelven los mismos cuatro problemas. Cambian las implementaciones, no las preguntas.

El bucle: el motor

El núcleo de cualquier agente es un bucle. En pseudocódigo:

loop:
    response = model(system_prompt, history)
    history.append(response)

    if response has no tool calls:
        break

    for call in response.tool_calls:
        result = execute(call)
        history.append(result)

Eso es. El harness le pasa al modelo el contexto actual, recibe su respuesta, mira si pide usar alguna herramienta, la ejecuta, mete el resultado en el historial y vuelve a empezar. El bucle termina cuando el modelo responde sin pedir ninguna acción, señal de que considera la tarea acabada.

Lo importante de este diseño es quién lleva el volante: el modelo. El código del bucle no decide qué fichero leer ni qué comando lanzar. Solo ejecuta lo que el modelo pide y le devuelve el resultado. Los modelos de hoy están entrenados para emitir esas peticiones de herramienta en un formato estructurado que el harness sabe parsear, y ahí está la grieta por donde el razonamiento se convierte en acción.

Hay un detalle que sorprende a quien mira un harness por dentro por primera vez: la parte "inteligente" es minúscula. El bucle en sí cabe en unas pocas decenas de líneas. Todo el peso del código está en lo que rodea a ese bucle: validar permisos, recortar contexto cuando se llena, enrutar herramientas, recuperarse de errores, persistir la sesión. La inteligencia la pone el modelo; la fiabilidad la pone esa infraestructura aburrida y determinista que casi nadie ve.

Las herramientas: la superficie de acción

Sin herramientas, un modelo solo habla. Con herramientas, actúa. Una herramienta es cualquier función que el harness pone a disposición del modelo y que este puede invocar: leer un fichero, escribir código, ejecutar un comando, buscar en la web, lanzar una consulta a una base de datos, llamar a una API interna.

Cada herramienta que añades amplía lo que el agente puede hacer, pero también lo que puede romper, así que el catálogo de herramientas no es un detalle de implementación: es una decisión de diseño. Un harness con acceso a Git y al sistema de ficheros es un asistente de código; el mismo modelo con herramientas para consultar tu CRM y enviar correos es otra cosa completamente distinta. El modelo no ha cambiado; ha cambiado el arnés.

Aquí entra una pieza que conviene nombrar porque se ha vuelto un estándar: los protocolos para conectar herramientas externas, como MCP. La gracia es que, una vez conectada, una herramienta externa le resulta al bucle indistinguible de una herramienta interna. El modelo ve una función que puede llamar; de dónde sale es irrelevante para la mecánica. Eso convierte el harness en algo extensible sin tocar su núcleo.

El contexto: el recurso que de verdad escasea

Un modelo tiene una ventana de contexto limitada: hay un tope de texto que puedes pasarle de una vez. Y en un agente esa ventana se llena rápido, porque dentro va el historial de la conversación, el contenido de los ficheros que ha leído, la salida de los comandos que ha ejecutado, las instrucciones del sistema y cualquier documentación que necesite. Cada vuelta del bucle suma.

Gestionar ese presupuesto es uno de los trabajos más difíciles del harness, y donde más se nota la diferencia entre uno bueno y uno malo. Cuando la ventana se acerca al límite hay que decidir qué se tira y qué se conserva, normalmente resumiendo lo viejo y quedándose con lo esencial. Hazlo mal y el agente "olvida" a mitad de tarea una instrucción que le diste al principio, y empieza a contradecirse. Por eso, en cualquier harness serio, las reglas que deben sobrevivir a toda la sesión no se dejan en la conversación: se ponen en un sitio fijo que se recarga siempre. La conversación es volátil; ese sitio fijo, no.

Hay dos técnicas que casi todos los harness modernos usan para estirar el presupuesto sin perder información. Una es cargar conocimiento solo cuando hace falta, en lugar de meterlo todo de entrada: el agente ve un índice de lo que tiene disponible y solo carga el contenido completo de una pieza cuando la va a usar. La otra es delegar trozos de trabajo a subagentes con su propia ventana de contexto aislada, que hacen su parte y devuelven un resumen, de modo que el detalle no contamina la conversación principal. Las dos atacan el mismo problema: el contexto es caro y finito.

Los límites: dónde vive tu autoridad

Un agente que puede ejecutar comandos y editar ficheros puede causar un gran problema. Borrar lo que no debe, mandar algo a producción, tocar un fichero crítico. El harness es también el lugar donde decides qué puede hacer el agente por su cuenta y qué tiene que pasar por ti antes.

Esto toma muchas formas: pedir confirmación antes de acciones con efectos externos, permitir ciertos comandos de antemano para no preguntar cada vez, poder revertir cambios en ficheros, separar un modo de "solo explorar" de un modo de "ejecutar". Todo eso es harness, no modelo. Y es la parte que la industria está mirando con más cuidado, porque a medida que los agentes ganan autonomía, el sistema de control alrededor del modelo importa tanto como la capacidad del modelo. Un buen arnés no solo hace al agente más obediente; al darle reglas claras y formas de verificar su trabajo, lo hace más capaz.

Por qué el arnés pesa más que el modelo

Durante un par de años la conversación giró en torno a qué modelo era mejor. Esa conversación se ha quedado sin gasolina, y por una razón concreta: los modelos punteros se han juntado mucho. En tareas reales de agente, las diferencias entre los mejores modelos de cada proveedor son estrechas. Cuando el motor deja de ser el factor diferencial, la diferencia se va al chasis. Y el chasis es el harness.

Hay una observación que lo resume bien: el mismo modelo, metido en harness distintos, da resultados distintos. Cambia el sistema que lo rodea —las herramientas, cómo gestiona el contexto, los bucles de verificación— y el comportamiento del agente cambia de arriba a abajo, sin tocar un solo peso del modelo. Esto tiene una consecuencia práctica para cualquiera que construya con agentes: el modelo lo alquilas, llamando a una API que no controlas y que cambia cuando el proveedor quiere. El harness es tuyo. Es la parte sobre la que tienes poder real, la que puedes versionar, medir y mejorar.

Y es también donde se decide si un agente llega a producción. Hacer una demo es fácil: conectas un buen modelo, le das un par de herramientas y un prompt decente, y resuelve una tarea simple. Sostener eso en producción —que recuerde el contexto correcto, que use las herramientas con seguridad, que se recupere de fallos, que respete permisos, que verifique su propio trabajo— es otra historia, y es justo el trabajo del harness. La mayoría de los proyectos de agentes que se quedan en el cajón no fracasan por el modelo. Fracasan por el harness.

Una disciplina con nombre propio

Llevamos años envolviendo modelos con scripts y harness sin ponerle etiqueta. El término se popularizó a principios de 2026, cuando varios equipos que construían agentes en serio empezaron a nombrar lo que ya hacían. El argumento de fondo es simple: el agente no es la parte difícil; el arnés lo es. Equipos que han levantado aplicaciones enormes con código generado casi por completo por IA lo cuentan igual: los ingenieros no escribieron el código, diseñaron el sistema que permitió a la IA escribirlo de forma fiable. Ese sistema es el harness, y diseñarlo bien ya es una disciplina propia.

Para un desarrollador, entender esto cambia cómo trabajas con cualquier agente. Cuando falla, dejas de pensar "el modelo es tonto" y empiezas a preguntarte qué parte del arnés ha fallado: ¿perdió contexto?, ¿le faltaba una herramienta?, ¿se quedó sin permiso para algo que necesitaba?, ¿la instrucción que le diste se diluyó a mitad de sesión? Casi siempre el problema está ahí, y casi siempre tiene arreglo sin esperar a un modelo mejor. Dejas de tratar al agente como una caja negra y empiezas a tratarlo como lo que es: un modelo dentro de un sistema que tú puedes diseñar.

Ese es el cambio de mentalidad. El modelo marca el techo de lo que es posible. El harness decide cuánto de ese techo aprovechas.

Si quieres ver todo esto en una herramienta concreta —el bucle real, las herramientas, cómo gestiona el contexto y los permisos, con sus detalles y sus límites— sigue por Cómo funciona Claude Code por dentro.