Harness engineering: qué es el AI harness y por qué es la disciplina que hace fiables a los agentes de IA

Un AI harness es el sistema de software que envuelve a un modelo de lenguaje y lo convierte en un agente capaz de ejecutar tareas: le da un bucle en el que actuar, un conjunto de herramientas con las que interactuar con el mundo, una forma de gestionar el contexto que entra y sale de su ventana, y unos límites dentro de los que operar. El modelo, por sí solo, solo predice texto. El harness es lo que le permite leer un fichero, llamar a una API, ejecutar un comando, ver el resultado y decidir el siguiente paso.

La palabra viene de la ingeniería (un arnés sujeta y guía) y del testing clásico (un test harness es el andamiaje que ejecuta y observa un componente). Aplicado a la IA, el harness es el andamiaje que ejecuta al modelo en un bucle, le pasa herramientas, captura lo que devuelve y realimenta el resultado. Ejemplos reconocibles: el motor que hay detrás de un asistente de programación como Claude Code o Cursor, el scaffolding de un agente que resuelve incidencias de software, o la infraestructura que rodea a un agente de soporte conectado a tu CRM. En todos, el modelo es intercambiable; el harness es lo que define el comportamiento.

Conviene fijar la idea con precisión, porque es la parte que más se confunde: el harness no es el prompt, ni el modelo, ni el framework de moda. Es el conjunto de piezas de ingeniería que gobiernan cómo el modelo percibe la tarea, qué puede hacer y cómo se controla lo que hace. Sus componentes habituales:

• Bucle de ejecución (agent loop): el ciclo que llama al modelo, ejecuta la herramienta que pide, le devuelve el resultado y repite hasta cumplir el objetivo o alcanzar un límite.
• Herramientas (tools): las acciones que el modelo puede invocar —leer, buscar, escribir, consultar una API, ejecutar código— y cómo están diseñadas y documentadas.
• Gestión de contexto: qué información entra en la ventana en cada paso, qué se resume, qué se descarta y cómo se evita que el contexto se sature o se contamine.
• Recuperación de conocimiento: cómo el harness trae datos externos relevantes (RAG, búsqueda, consultas a sistemas) en el momento oportuno.
• Permisos y gates: qué puede leer y qué puede modificar el agente, y en qué puntos necesita aprobación humana antes de actuar.
• Verificación y recuperación de errores: cómo el harness comprueba si un paso salió bien y cómo reacciona cuando falla, en lugar de seguir ciegamente.
• Subagentes y orquestación: cuándo delegar una subtarea a otro agente con su propio contexto acotado para no saturar el principal.
• Observabilidad: la traza de qué hizo el agente, con qué herramientas, con qué datos y con qué resultado, para poder auditar y mejorar.

Hay una observación que se repite en cuanto empiezas a construir agentes serios: cambiar el modelo por otro más potente casi nunca da el salto de fiabilidad que esperabas, pero rediseñar el harness sí. El mismo modelo, con un bucle mejor, herramientas mejor diseñadas y una gestión de contexto más limpia, pasa de fallar la mitad de las veces a resolver la tarea de forma consistente. Los propios laboratorios que publican benchmarks agénticos lo reconocen: buena parte de la puntuación de un sistema depende del scaffolding, no solo del modelo base.

La razón es que los modelos actuales ya son, en general, suficientemente capaces de razonar sobre una tarea. Lo que los hace fallar en producción no suele ser falta de inteligencia, sino condiciones del entorno: contexto saturado o contradictorio, herramientas ambiguas que invitan al error, ausencia de verificación, falta de un camino claro para recuperarse de un fallo. Todo eso son decisiones de harness, no del modelo. Y son decisiones que un equipo controla, mientras que la capacidad del modelo la controla el proveedor.

Esto tiene una consecuencia estratégica importante para cualquier empresa: apostar todo a "esperar el próximo modelo" es una estrategia pasiva y con techo. Invertir en un buen harness es una ventaja acumulable, porque además mejora automáticamente cuando llega un modelo mejor. Elegir bien el modelo sigue importando —lo tratamos en qué modelo elegir para tu empresa—, pero es solo una de las variables, no la que decide el resultado.

Se mezclan constantemente, y esa confusión lleva a invertir esfuerzo en la capa equivocada. No son sinónimos ni etapas de lo mismo: son tres niveles que operan sobre problemas diferentes. Ordenarlos ayuda a saber dónde está realmente el cuello de botella de tu agente.

El prompt engineering trabaja el mensaje: qué le pides al modelo y cómo. El context engineering trabaja la ventana: qué información concreta entra en cada llamada para que el modelo decida con criterio en lugar de suponer. El harness engineering trabaja el sistema completo: el bucle, las herramientas, los permisos, la verificación y la orquestación que rodean a todas esas llamadas a lo largo de una tarea. Cada capa envuelve a la anterior.

Si el prompt engineer optimiza mensajes, el harness engineer optimiza el sistema donde esos mensajes se ejecutan en bucle. Es un perfil más cercano al ingeniero de sistemas y de fiabilidad que al redactor de prompts: piensa en interfaces, en estados, en fallos y en observabilidad. Su trabajo típico incluye:

• Diseñar el bucle del agente: cuándo continúa, cuándo se detiene, cuántos pasos permite y cómo evita quedarse en bucles improductivos.
• Diseñar las herramientas: qué acciones expone, con qué nivel de granularidad, con qué nombres y descripciones, y con qué mensajes de error útiles cuando algo falla.
• Gestionar el presupuesto de contexto: decidir qué se mantiene en la ventana, qué se resume, qué se delega a un subagente y qué se recupera bajo demanda.
• Definir permisos y puntos de aprobación: separar lo que el agente puede leer de lo que puede modificar, y dónde exige revisión humana.
• Construir verificación: cerrar el bucle con comprobaciones —tests, validaciones, checks— para que el agente sepa si su trabajo es correcto antes de darlo por bueno.
• Instrumentar observabilidad: registrar cada paso para poder reproducir un fallo, medir el coste y entender por qué el agente hizo lo que hizo.
• Iterar con evaluaciones: medir el harness sobre un conjunto de tareas reales y mejorar la pieza que más falla, no la que parece más elegante.

No hay una receta única, pero sí un conjunto de principios que distinguen un harness robusto de uno frágil. La mayoría comparten una misma intuición: reducir la incertidumbre a la que se enfrenta el modelo en cada paso y dejar siempre una salida cuando algo va mal.

• Contexto mínimo y limpio: menos información, pero la relevante. Un contexto saturado o contradictorio degrada al mejor modelo. Cada token que añades debería ganarse su sitio.
• Herramientas de alto nivel y sin ambigüedad: es mejor una herramienta que hace bien una cosa concreta que diez primitivas que el modelo tiene que combinar adivinando. Los errores de las herramientas deben devolver mensajes que enseñen a corregir.
• Bucle de verificación cerrado: el agente debe poder comprobar su propio trabajo (ejecutar un test, validar un esquema, releer un resultado) antes de considerarlo terminado. Sin verificación, un error temprano contamina todo lo que sigue.
• Recuperación de errores: un fallo no debe romper la tarea. El harness debe capturarlo, devolverlo de forma útil y dar al agente la oportunidad de reintentar o cambiar de estrategia.
• Subagentes para aislar contexto: delegar subtareas a agentes con su propia ventana acotada evita que el contexto principal se sature y mantiene cada decisión enfocada.
• Permisos explícitos y gates: cuanto más puede hacer un agente, más importante es definir qué no puede hacer sin aprobación. Los límites son parte del diseño, no un añadido.
• Determinismo donde se pueda: si un paso puede resolverlo código normal en lugar del modelo, resuélvelo con código. El modelo se reserva para lo que de verdad requiere criterio.

Un harness no se mejora por intuición, se mejora midiendo. Y aquí está la diferencia entre un equipo que "prueba agentes" y uno que hace harness engineering en serio: el segundo tiene un conjunto de evaluaciones —una eval— que ejecuta el harness sobre tareas representativas y mide si las resuelve, con qué coste y con qué fiabilidad. Sin eso, cada cambio es una apuesta a ciegas.

En el ámbito público existen benchmarks agénticos que sirven de referencia —para tareas de programación, por ejemplo, se usan conjuntos como SWE-bench o terminal-bench—, y son útiles para comparar enfoques. Pero el benchmark que de verdad importa para una empresa es el propio: un conjunto de tareas reales de tu negocio, con sus datos, sus herramientas y sus criterios de "correcto". Ese es el que te dice si tu harness sirve para lo tuyo, no para un problema de laboratorio.

Medir bien implica ir más allá del "¿acertó?". Un harness de calidad se evalúa en varias dimensiones a la vez, porque un agente que acierta pero cuesta diez veces más o tarda diez veces más tampoco es viable.

• Tasa de éxito en tareas reales: ¿resuelve el objetivo completo, no solo un paso?
• Fiabilidad: ¿lo resuelve de forma consistente al repetir, o acierta una de cada tres?
• Coste y latencia: cuántos tokens y cuánto tiempo consume por tarea, y cómo escala.
• Seguridad: ¿respeta permisos y límites, o intenta acciones que no debería?
• Recuperación: cuando falla un paso, ¿se recupera o arrastra el error hasta el final?

La mayoría de empresas no van a escribir su harness desde cero, y es razonable: plataformas y frameworks (desde SDKs de agentes hasta protocolos de integración) ya resuelven buena parte del bucle, las herramientas y la conexión a sistemas. Pero "no escribirlo desde cero" no significa "no diseñarlo". Aunque uses una plataforma, las decisiones de harness —qué herramientas expones, qué contexto entra, qué permisos das, cómo verificas— siguen siendo tuyas, y siguen decidiendo si el agente es fiable.

Aquí encaja el papel de estándares como MCP (Model Context Protocol), que estandariza cómo el harness se conecta a herramientas y datos, o de patrones de recuperación como RAG y bases de conocimiento, que alimentan el contexto con información propia. Son piezas del harness, no sustitutos de pensarlo. La pregunta empresarial correcta no es "¿qué framework uso?", sino "¿tengo el criterio y la medición para diseñar el envoltorio de mi agente y saber si funciona?".

Ese criterio es, en gran parte, una cuestión de personas formadas. El salto de "pasar de ChatGPT a agentes" —que tratamos en esta guía— exige equipos que entiendan estas capas. Antes de escalar, conviene asegurar lo básico:

• Tener claras las tres capas: prompt, contexto y harness, y saber en cuál está tu problema.
• Empezar con casos acotados y una eval propia desde el primer día.
• Diseñar permisos y verificación antes de conectar el agente a sistemas reales.
• Instrumentar observabilidad para poder depurar y auditar lo que hace el agente.
• Formar a los equipos técnicos en diseño de herramientas, gestión de contexto y evaluación, no solo en escribir prompts.