La anatomía de un agente de IA: qué es el arnés y sus piezas

Agente = modelo + arnés

La idea cabe en una fórmula: agente = modelo + arnés (en inglés, harness). Y viene con una regla fácil de recordar: si no eres el modelo, eres el arnés.

Un arnés es todo el código, la configuración y la lógica de ejecución que no son el modelo. Un modelo en bruto no hace de agente. Empieza a serlo cuando el arnés le da estado, ejecución de herramientas, bucles de realimentación y restricciones que se cumplen sí o sí.

En concreto, un arnés incluye cinco cosas:

• Prompts de sistema. Las instrucciones de partida.
• Herramientas, skills y servidores MCP, con sus descripciones.
• Infraestructura incluida: sistema de archivos, sandbox y navegador.
• Orquestación: lanzar subagentes, repartir el trabajo y elegir modelo.
• Hooks o middleware: pasos deterministas, como compactar, hacer que siga trabajando o pasar el linter.

La frontera más limpia

Hay muchas formas enrevesadas de separar el modelo del arnés. Vivek defiende esta porque le parece la más limpia: nos obliga a pensar en cómo diseñar sistemas alrededor de la inteligencia del modelo. Y desde ahí va deduciendo, hacia atrás, por qué existe cada pieza.

El artículo lo resume en un esquema. En el centro está el modelo, que razona y decide. Desde arriba le entra el contexto: prompts, memoria, skills y la conversación. A la derecha actúa: llama a bash, a herramientas y a servidores MCP, y los resultados vuelven a su contexto. Por abajo persiste: escribe y lee archivos, git y ficheros de progreso. En diagonal observa y verifica, con capturas del navegador, resultados de tests y registros. Y a la izquierda está el control: compactación, orquestación y bucles Ralph.

Por qué hace falta un arnés

Ponte en el lugar del modelo. Casi todos reciben datos, como texto, imágenes, audio o vídeo, y devuelven texto. Eso es todo. De serie, no pueden:

• Conservar un estado duradero entre interacciones.
• Ejecutar código.
• Acceder a conocimiento en tiempo real.
• Preparar entornos e instalar paquetes para terminar un trabajo.

Todas son funciones del arnés. Y seguro que ya has usado uno sin saberlo: para poder chatear con un modelo, lo envolvemos en un bucle while que guarda los mensajes anteriores y añade cada mensaje nuevo tuyo. Esa experiencia de conversar no la da el modelo. La da ese bucle.

Trabajar hacia atrás

De ahí sale la idea central: convertir el comportamiento que queremos del agente en una función real del arnés. A eso lo llaman ingeniería de arneses (harness engineering). Sirve para inyectar conocimiento previo que guíe al agente y, como los modelos son cada vez más capaces, también para extenderlos y corregirlos con precisión de cirujano.

Por eso el artículo sigue siempre el mismo patrón: primero, el comportamiento que queremos; después, lo que añade el arnés para lograrlo. Salen seis parejas. No pretende ser una lista exhaustiva: lo importante es que cada pieza nace de algo que el modelo no puede dar por sí mismo.

Como esto va de anatomía, en el vídeo monto esas seis piezas como un cuerpo, y aquí mantengo la imagen porque ayuda a recordarlas. El modelo es el cerebro. La metáfora es mía, no del artículo.

1. Archivos: el esqueleto

Queremos que el agente trabaje con datos reales, que guarde lo que no le cabe en el contexto y que conserve su trabajo entre sesiones. Pero el modelo solo opera sobre lo que hay dentro de su ventana. Antes había que copiar y pegar a mano, algo incómodo que no sirve para un agente autónomo.

La solución salió sola. El mundo ya trabajaba con archivos, así que los modelos se entrenaron con miles de millones de tokens que enseñan a usarlos. Por eso los arneses traen un sistema de archivos y herramientas para manejarlo. Vivek la considera quizá la pieza más fundamental, por lo que desbloquea:

Si le sumas git, además tiene versiones: sigue su trabajo, deshace errores y prueba experimentos en ramas. Conviene recordar esta pieza, porque varias de las que vienen se apoyan en ella.

2. Bash y código: las manos

Queremos que el agente resuelva problemas solo, sin que nadie tenga que diseñarle antes cada herramienta. El patrón habitual hoy es el bucle ReAct: el modelo razona, actúa llamando a una herramienta, observa el resultado y repite.

Pero el arnés solo ejecuta las herramientas para las que tiene lógica. En vez de programar una para cada acción posible, es mejor darle una de propósito general: bash. Así el modelo resuelve los problemas por su cuenta, escribiendo y ejecutando código.

Es un gran paso hacia darle un ordenador y dejar que se las apañe. Ya no depende de un juego fijo de herramientas: se diseña las suyas sobre la marcha. Los arneses siguen trayendo otras, pero ejecutar código es ya la estrategia por defecto.

3. Entornos aislados: la piel

Ya puede guardar y ejecutar código, pero todo eso tiene que pasar en algún sitio. Lanzar en tu máquina lo que genera un agente es arriesgado, y tener solo un entorno local no escala cuando la carga de agentes crece.

La respuesta son los sandbox, entornos aislados y seguros. El arnés se conecta a uno para ejecutar código, mirar archivos e instalar dependencias. Si quieres más seguridad, permite solo una lista de comandos y aísla la red. Y también escalan: se crean a demanda, se reparten entre muchas tareas y se destruyen al acabar.

Los buenos entornos traen buenas herramientas de serie, y configurarlas es cosa del arnés: lenguajes y paquetes ya instalados, líneas de comandos para git y para los tests, y navegadores para usar la web y comprobar lo hecho. Navegadores, registros, capturas y ejecutores de tests le dejan observar su trabajo, y así nacen los bucles de autoverificación: escribe el código, lanza las pruebas, lee los registros y corrige los errores.

De serie, el modelo no configura su propio entorno. Dónde corre, qué herramientas tiene, a qué puede acceder y cómo verifica su trabajo son decisiones de diseño del arnés.

4. Memoria y búsqueda

Queremos que recuerde lo que ha visto y que acceda a lo que no existía cuando lo entrenaron. Pero un modelo solo sabe lo que hay en sus pesos y en su contexto actual. Como no podemos editar esos pesos, la única vía para añadir conocimiento es inyectarlo en el contexto.

Para la memoria, los archivos vuelven a ser la base. Los arneses admiten estándares como AGENTS.md, que se inyecta al arrancar. Cuando el agente lo edita, el arnés carga la versión nueva. Es una forma de aprendizaje continuo: lo que guarda en una sesión llega a las siguientes.

Luego está la fecha de corte. El modelo no conoce, por ejemplo, la última versión de una librería, salvo que se la des tú. La búsqueda web y herramientas MCP como Context7 le traen lo que no existía cuando acabó su entrenamiento, así que conviene integrarlas en el arnés.

5. Pudrición del contexto: el sistema inmunitario

La context rot es esto: los modelos razonan peor y completan peor las tareas a medida que se llena su ventana. Ese espacio es un recurso valioso y escaso, así que el arnés necesita estrategias para administrarlo. Vivek lo resume con una frase contundente: los arneses de hoy son, en gran medida, mecanismos para entregar una buena ingeniería de contexto.

El artículo nombra tres técnicas:

1. Compactación. ¿Qué pasa si la conversación supera la ventana? Una opción es que la API devuelva un error, y eso no es bueno. Así que el arnés descarga y resume con inteligencia lo que hay, y el agente puede seguir trabajando.
2. Sacar fuera las salidas de las herramientas. Las enormes llenan el contexto de ruido sin aportar nada útil. Si una pasa de cierto umbral de tokens, el arnés conserva el principio y el final, y guarda el texto completo en un archivo, por si el modelo lo necesita.
3. Skills. Tener demasiadas herramientas o servidores MCP cargados al arrancar hace que rinda peor antes de empezar. Las skills lo evitan con revelación progresiva: al inicio solo se carga su cabecera. El modelo no lo ha elegido; es el arnés quien lo protege.

Si quieres ir a fondo, hablo de esto en mis posts sobre compresión de contexto, gestión de contexto e ingeniería de contexto.

6. Trabajo a largo plazo: el corazón

Crear software de forma autónoma es el santo grial de los agentes de programación. Pero los modelos de hoy paran antes de tiempo, les cuesta descomponer problemas complejos y pierden coherencia cuando el trabajo se alarga por varias ventanas. Un buen arnés tiene que diseñar alrededor de todo eso.

Aquí las piezas anteriores empiezan a sumarse: trabajar a largo plazo exige estado duradero, planificación, observación y verificación.

• Archivos y git para seguir el trabajo. En una tarea larga, un agente produce millones de tokens. Los archivos guardan ese progreso, y git permite que otro recién llegado se ponga al día enseguida. Para varios agentes, es además un registro compartido.
• El bucle Ralph para que siga. Cuando el modelo intenta terminar, un hook intercepta esa salida y vuelve a inyectar el prompt original en una ventana de contexto limpia. Así está obligado a seguir hasta cumplir el objetivo. No empieza de cero porque cada vuelta arranca con el contexto fresco, pero lee de los archivos el estado que dejó la anterior.
• Planificar y verificar para no perder el rumbo. El modelo descompone el objetivo en pasos, y el arnés lo apoya con buenos prompts y recordatorios sobre cómo usar un archivo de plan. Al completar cada paso, los hooks pueden lanzar una batería de tests y, si falla, devolverle el error. También se le puede pedir que evalúe su código de forma independiente.

Verificar ancla la solución en esas pruebas y crea una señal con la que mejorar.

El cuerpo entero

Ya está montado. El esqueleto de archivos y git. Las manos de bash y código. La piel del sandbox. La memoria y la búsqueda. El sistema inmunitario contra la pudrición. Y el corazón, que no deja de latir hasta que el trabajo está hecho. Cada parte salió de algo que el cerebro no podía hacer solo.

Modelo y arnés, entrenados juntos

Productos como Claude Code y Codex se postentrenan con el modelo y el arnés en el bucle. Así el modelo mejora en lo que sus diseñadores creen que debería hacer bien de forma nativa: operar con archivos, ejecutar bash, planificar o repartir trabajo entre subagentes.

Eso crea un ciclo: se descubre una pieza útil, se añade al arnés y se usa para entrenar la siguiente generación. Al repetirse, el modelo es cada vez más capaz, pero dentro del arnés con el que lo entrenaron.

Esa evolución conjunta tiene un efecto secundario: si cambias la lógica de una herramienta, rinde peor. El ejemplo es apply_patch, la utilidad que usa Codex para editar archivos. Su guía recomienda usar esa implementación exacta, porque el modelo se entrenó con ese formato. Algo de verdad inteligente cambiaría de método sin problema; entrenar así provoca sobreajuste.

Aun así, el mejor arnés para tu tarea no tiene por qué ser aquel con el que se entrenó el modelo. Terminal Bench 2.0 es un buen ejemplo: según el artículo, cuando se escribió, Opus 4.6 dentro de Claude Code puntuaba muy por debajo del mismo Opus 4.6 en otros arneses. No he podido comprobarlo: la página de Terminal Bench ya muestra otra versión.

LangChain lo comprobó con su propio agente de programación: pasó del puesto 30 al top 5 solo cambiando el arnés, de 52,8 a 66,5 puntos, sin tocar el modelo (GPT-5.2-Codex). Queda mucho margen para mejorar si lo optimizas para tu tarea.

Hacia dónde va

A medida que mejoren los modelos, parte de lo que hoy vive en el arnés acabará dentro de ellos. Planificarán, se verificarán y mantendrán la coherencia mejor de forma nativa, y necesitarán menos contexto inyectado. Eso sugiere que el arnés importará cada vez menos.

Pero Vivek cree que seguirá siendo útil, igual que la ingeniería de prompts lo sigue siendo hoy. Es verdad que los arneses parchean carencias, aunque también construyen sistemas alrededor de la inteligencia. Un entorno bien configurado, buenas herramientas, estado duradero y bucles de verificación hacen más eficiente a cualquier modelo, sea cual sea su nivel.

Por eso sigue siendo un área de investigación muy activa. En LangChain la usan para mejorar su librería deepagents, y citan tres problemas abiertos:

• Orquestar cientos de agentes en paralelo sobre el mismo código.
• Lograr que los agentes analicen sus propias trazas para encontrar y arreglar los fallos del arnés.
• Arneses que se montan al vuelo, con las herramientas y el contexto justos para cada tarea, en lugar de venir preconfigurados.

En resumen

Cada pieza del arnés existe por algo que el modelo no puede hacer solo: guardar, actuar, ejecutar con seguridad, recordar, mantener limpio su contexto y seguir trabajando. Y como el modelo se entrena dentro de un arnés, cambiar ese arnés puede dar más que cambiar de modelo.

¿Qué pieza del arnés te ha dado más resultado a ti?

Fuentes

• «The Anatomy of an Agent Harness», de Vivek Trivedy (@Vtrivedy10), LangChain, 10 de marzo de 2026.
• Los puntos en Terminal Bench 2.0: la publicación que cita el artículo.
• La guía de Codex sobre apply_patch: Codex Prompting Guide.
• Otro artículo sobre el mismo tema, que también expliqué: «The Harness Is The Product».
• El vídeo, en mis tres canales: español, inglés y portugués.