Mismo modelo, distinto agente: qué es el harness

En febrero de 2026, el equipo de LangChain contó cómo había mejorado su agente de programación en Terminal-Bench 2.0, una prueba de 89 tareas que un agente tiene que resolver escribiendo órdenes en la terminal de un ordenador. El agente pasó de resolver el 52,8 % de las tareas al 66,5 %, y de quedar fuera de los treinta primeros de la clasificación a estar entre los cinco mejores. El motor del agente, un modelo de lenguaje grande (LLM, por sus siglas en inglés), fue el mismo de principio a fin. Era GPT-5.2-Codex, de OpenAI. Lo que cambiaron fueron las instrucciones, las herramientas y el código que rodea al modelo (Trivedy, 2026a).

A ese código que rodea al LLM se le llama harness, o arnés. Vivek Trivedy, de LangChain, lo resumió en una fórmula que se ha repetido mucho desde entonces, agente = modelo + arnés, y en una definición igual de breve. El arnés es todo el código, la configuración y la lógica de ejecución que no forman parte del propio modelo (Trivedy, 2026b). El LLM puede contratarse a un proveedor, como OpenAI, Anthropic o Google, o ser un modelo abierto que se ejecuta en servidores propios o en el mismo dispositivo. El arnés lo diseña siempre quien construye el agente. De ese diseño depende buena parte de que un agente acierte una vez o acierte siempre.

En este artículo contamos qué es el arnés, de dónde viene la idea y por qué, en nuestra experiencia, cada vez pesa más. En el siguiente veremos las claves para construir uno bueno.

Qué es un harness

En inglés, harness es el arnés de un animal de tiro, las correas que unen el caballo al carro, y como verbo significa aprovechar o controlar una fuerza (Wiktionary). La imagen encaja bien con los agentes. El arnés no hace más fuerte al caballo, pero sin él esa fuerza no llega al carro ni va hacia donde interesa. En español, la palabra trae a la cabeza también el arnés de escalada, el que sujeta a una persona en un trabajo con riesgo de caída (Wiktionario). Esa segunda lectura tampoco sobra, porque una parte del arnés de un agente sirve precisamente para frenarlo.

Lo que rodea al LLM es mucho. Está el bucle que lo llama una y otra vez, ejecuta lo que pide y decide cuándo parar. Están las instrucciones y los documentos que tiene delante en cada paso, las herramientas con las que actúa más allá del texto, como buscar en internet, leer un documento o consultar otro sistema, y la memoria que se conserva de una sesión a otra. Y están los límites, que marcan lo que tiene prohibido o necesita confirmación, y las comprobaciones que deciden si el trabajo está bien hecho. Trivedy lo explica empezando por el otro lado, por lo que un LLM no sabe hacer solo. No recuerda nada de una conversación a otra, no ejecuta código y no consulta información actualizada si nadie se la da (Trivedy, 2026b).

Arnés

• Instrucciones y contexto

  Lo que el LLM ve en cada paso.

• Herramientas

  Lo que puede hacer fuera del texto.

• Memoria

  Lo que se conserva de una sesión a otra.

LLM (modelo de lenguaje)

De un proveedor o abierto y en servidores propios. Lee lo que tiene delante y propone el siguiente paso.

↻ El bucle llama al LLM, ejecuta lo que pide y decide cuándo parar.

• Límites y permisos

  Lo que tiene prohibido o necesita confirmación.

• Comprobaciones

  Lo que decide si el trabajo está bien hecho.

• Trazas

  Lo que permite saber qué ha pasado y por qué.

A diseñar todo eso se le llama ingeniería del arnés, o harness engineering. Addy Osmani, que le ha dedicado varios ensayos en O’Reilly, la describe como el trabajo de diseñar, probar y ajustar el andamiaje que permite a un modelo terminar trabajo real (Osmani, 2026).

De dónde viene la palabra

La palabra llega del desarrollo de software. Un test harness es lo que hace falta para poner a prueba una pieza de código, como los programas que la arrancan y le dan datos, los sustitutos de las piezas que todavía no existen y lo que comprueba el resultado. El glosario de ISTQB, el organismo internacional que certifica a profesionales de pruebas de software, lo define como el entorno formado por los controladores y sustitutos necesarios para ejecutar una prueba (ISTQB). La misma palabra lleva años en la evaluación de modelos de lenguaje. Según su documentación, lm-evaluation-harness, de EleutherAI, es el motor con el que se calcula la Open LLM Leaderboard de Hugging Face (EleutherAI).

Aplicada a los agentes, la expresión se extendió en pocas semanas a principios de 2026. Osmani atribuye el término a Trivedy (Osmani, 2026), aunque apareció en varios sitios casi a la vez. El 5 de febrero, Mitchell Hashimoto, cofundador de HashiCorp, contó que había empezado a llamar harness engineering a una costumbre suya. Cada vez que un agente comete un error, dedica tiempo a que no pueda volver a cometerlo, con mejores instrucciones o con herramientas que le permitan comprobar su propio trabajo (Hashimoto, 2026). El 11 de febrero, OpenAI contó cómo uno de sus equipos había construido un producto interno durante cinco meses sin escribir a mano una sola línea de código. Los ingenieros de ese equipo dejaron de programar y pasaron a diseñar el entorno en el que trabajaba el agente (OpenAI, 2026). En las semanas siguientes llegaron los dos artículos de Trivedy en LangChain, y en abril Birgitta Böckeler ordenó las ideas en un artículo del sitio de Martin Fowler que hoy es una de las referencias del tema (Böckeler, 2026).

Hoy la palabra tiene tres usos que conviene no mezclar. Está el arnés que ya traen los productos para crear y ejecutar agentes, como Claude Code o Codex. Está el que cada equipo añade encima para su proyecto, con sus propias instrucciones, permisos y comprobaciones, que es el que analiza Böckeler. Y está el arnés de evaluación, el banco de pruebas que pone nota a modelos y agentes, heredero directo del test harness.

Lo que ya hacíamos antes de los LLM

La expresión es nueva. El problema que nombra lo es bastante menos.

Shakey, el robot que el instituto de investigación SRI desarrolló entre 1966 y 1972, fue el primer robot móvil capaz de razonar sobre sus propias acciones (Computer History Museum). Un planificador calculaba la secuencia de acciones necesaria para cumplir un objetivo, por ejemplo empujar un bloque hasta una puerta. Como el mundo no siempre se comportaba como preveía el plan, sus creadores añadieron PLANEX, un sistema que vigilaba la ejecución y permitía al robot reaccionar cuando una acción no tenía el efecto esperado (Fikes, Hart y Nilsson, 1972). Planificar, actuar, comprobar el resultado y corregir sigue siendo el ciclo de cualquier agente.

Después llegaron otras formas de organizar ese control. Rodney Brooks propuso en 1986 robots hechos de capas de comportamiento que funcionan a la vez, desde evitar obstáculos hasta tareas más elaboradas (Brooks, 1986). En 1995, Anand Rao y Michael Georgeff describieron los agentes BDI, con un ciclo explícito que revisa lo que ha cambiado, decide qué objetivo perseguir, se compromete con un plan y abandona lo que ya ha logrado o se ha vuelto imposible (Rao y Georgeff, 1995).

Quien haya diseñado asistentes de voz antes de los LLM reconocerá casi todas las piezas. En una aplicación para Alexa de 2018 ya había que guardar lo dicho en la conversación, decidir cuándo terminarla, reconducir a quien se salía del guion, dar al asistente una personalidad coherente y conectarlo con otros servicios. Casi todo eso vivía en la gestión del diálogo. La personalidad se trabajaba además al redactar las respuestas, e incluso al elegir y ajustar la voz sintética. Y todo lo escribíamos nosotros. El modelo solo clasificaba cada frase en una intención y sacaba los datos importantes, como una fecha o una ciudad. El asistente hacía exactamente lo que el flujo le permitía, y por eso nadie hablaba de arnés. Lo contamos en hacer un chatbot en 2018 y hacerlo hoy.

En octubre de 2022, un equipo de Princeton y Google propuso ReAct, un método para que un modelo de lenguaje alterne razonamientos y acciones y use lo que obtiene de cada acción para decidir la siguiente (Yao et al., 2022). Buena parte de los agentes actuales descienden de esa idea.

Con un LLM cambia el reparto, porque el modelo aporta autonomía y también imprevisibilidad. Ya no elige entre respuestas previstas. Las redacta, decide qué herramienta usar y cuándo dar algo por terminado, y la misma petición puede recibir respuestas distintas. Las funciones de antes siguen haciendo falta, pero ahora sirven para acotar lo que propone el modelo y para que el servicio se comporte de forma previsible y segura. Además aparecen riesgos que antes no existían. El más conocido es la inyección de instrucciones, órdenes escondidas en una web o un documento que el agente lee y puede acabar obedeciendo. OWASP la pone en primer lugar de su lista de riesgos para aplicaciones con LLM (OWASP, 2025).

Asistente de 2018

Lo escribe quien diseña el flujo.

Agente con LLM

Lo propone el LLM y el arnés lo acota.

Memoria

Asistente de 2018

Variables que se guardan en cada paso del flujo.

Agente con LLM

El arnés decide qué se guarda y qué ve el LLM en cada turno.

Cuándo terminar

Asistente de 2018

Un punto final previsto en el flujo.

Agente con LLM

El LLM propone terminar y el arnés comprueba si de verdad ha acabado.

Desvíos y errores

Asistente de 2018

Respuestas de ayuda cuando no se reconoce la petición.

Agente con LLM

El LLM improvisa y el arnés limita la respuesta a lo permitido.

Personalidad

Asistente de 2018

Respuestas redactadas a mano y una voz elegida y ajustada.

Agente con LLM

Instrucciones de estilo y comprobaciones sobre lo que genera el LLM.

Otros servicios

Asistente de 2018

Llamadas programadas en pasos concretos del flujo.

Agente con LLM

El LLM elige la herramienta y el arnés controla permisos y confirmaciones.

En el fondo, los problemas son los mismos que tenía Shakey. Hay que saber si una acción ha salido bien, darse cuenta de cuándo se ha terminado, poner límites y recuperarse de los errores. Ha cambiado cuánto puede hacer el motor por su cuenta y, con ello, cuánto control hace falta alrededor. En nuestros proyectos, esa parte ocupa cada vez más tiempo, y suele ser la que separa una demostración que impresiona de un servicio que se puede poner delante de los clientes.

Las piezas de un arnés

Hay varias formas de clasificarlas. Una revisión académica publicada en mayo de 2026 las ordena en cuatro capas, que son la ejecución, el contexto, la conexión con herramientas y entorno, y las restricciones (Xie et al., 2026). Nosotros juntamos el contexto y las herramientas, porque al diseñar un agente se deciden a la vez, y nos quedan tres familias.

• El núcleo de ejecución. El bucle, la elección del modelo y de cuánto tiene que razonar en cada paso, y la capacidad de retomar el trabajo si algo falla a mitad.
• El contexto y las capacidades. Las instrucciones, la información que el LLM tiene delante en cada momento, las herramientas, los conocimientos especializados que se cargan solo cuando hacen falta (lo que Anthropic llama skills), la memoria y los subagentes, otros agentes a los que se encarga una parte del trabajo.
• El control. Los permisos, las comprobaciones, las trazas que registran qué ha hecho el agente y por qué, la defensa frente a instrucciones maliciosas, las confirmaciones de una persona y la evaluación.

Las dos primeras familias le dan al agente lo que necesita para trabajar. La tercera es la que permite confiar en él y, en nuestra experiencia, la que más ha crecido desde que el motor es un LLM.

El arnés de un agente de voz

En un agente de voz, el arnés incluye además piezas que no existen en un chat. Tiene que detectar cuándo ha terminado de hablar la persona, dejar que interrumpa, cubrir con una frase los segundos en que el agente consulta algo y medir la latencia de cada paso. Lo contamos en cuándo me toca hablar y en tres formas de montar un agente de voz. Como en 2018, la personalidad se reparte entre las instrucciones, las comprobaciones de cada respuesta y la voz con que se dice, como explicamos en quién habla cuando habla tu agente. Y como lo que se dice en voz alta no se puede borrar, los límites tienen que actuar antes de que la respuesta llegue al altavoz. Con el mismo LLM, dos agentes de voz pueden ofrecer experiencias muy distintas según lo bien resuelto que esté todo eso.

Cómo te ayudamos

En Monoceros diseñamos y construimos agentes, y buena parte de ese trabajo es el arnés. Decidimos qué ve el modelo, qué puede hacer, qué tiene prohibido y cómo se comprueba que ha hecho bien su trabajo. Antes de lanzarlo, lo evaluamos con conversaciones reales para saber qué aporta cada capa y qué sobra.

Referencias

• Trivedy, V. (2026a). Improving Deep Agents with harness engineering. LangChain.
• Trivedy, V. (2026b). The Anatomy of an Agent Harness. LangChain.
• Wiktionary. harness.
• Wiktionario. arnés.
• Osmani, A. (2026). Agent Harness Engineering. O’Reilly Radar.
• ISTQB. Standard glossary of terms used in Software Testing, versión 2.3.
• EleutherAI. lm-evaluation-harness. GitHub.
• Hashimoto, M. (2026). My AI Adoption Journey.
• OpenAI (2026). Harness engineering: leveraging Codex in an agent-first world.
• Böckeler, B. (2026). Harness engineering for coding agent users. martinfowler.com.
• Computer History Museum. Shakey.
• Fikes, R. E., Hart, P. E. y Nilsson, N. J. (1972). Learning and executing generalized robot plans. Artificial Intelligence, 3, 251-288.
• Brooks, R. A. (1986). A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation, 2(1), 14-23.
• Rao, A. S. y Georgeff, M. P. (1995). BDI Agents: From Theory to Practice. ICMAS-95.
• Yao, S., Zhao, J., Yu, D. et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023.
• OWASP GenAI Security Project (2025). Top 10 for LLM Applications.
• Xie, Z., Ren, X., Zheng, T., Bai, J., Fan, W., Xu, B., Li, H., Jing, H. y Song, Y. (2026). A Survey on AI Agent Harness. ResearchGate. DOI: 10.13140/RG.2.2.31393.57447.