El arnés antes del caballo: qué es *harness engineering* y por qué define a los agentes de IA útiles

Un modelo de IA puede ser extraordinario. Puede escribir, investigar, programar, resumir, razonar y proponer soluciones. Pero por sí solo no sabe qué parte del negocio importa, qué herramientas puede tocar, cuándo debe detenerse ni cómo demostrar que terminó bien.

Esa es la diferencia entre una demo impresionante y un agente que de verdad mueve una operación.

En inglés, **harness** significa *arnés*: el conjunto de correas, silla, riendas y puntos de unión que permite guiar la fuerza de un caballo y convertirla en trabajo útil. En inteligencia artificial, un **harness** es el sistema que rodea a un agente para darle dirección, contexto, herramientas, límites, memoria y verificación. Y *harness engineering* es el oficio de diseñar ese sistema.

El modelo es la capacidad. El harness es la operación.

**Un agente no mejora solo porque cambia de modelo. Mejora cuando el entorno le permite entender, actuar, comprobar y aprender sin salirse de la ruta.**

No es otro nombre para un prompt

Un prompt es una instrucción: “revisa estos leads y prepara una propuesta”.

Un harness responde las preguntas que el prompt deja abiertas:

• ¿Dónde están los leads y cuál fuente es confiable?
• ¿Qué datos puede leer el agente y cuáles no?
• ¿Qué formato debe tener una propuesta correcta?
• ¿Qué precio puede sugerir y quién autoriza una excepción?
• ¿Cómo registra lo que hizo para que otra persona o agente pueda continuar?
• ¿Qué prueba debe pasar antes de marcar la tarea como terminada?
• ¿Cuándo debe parar y escalar un caso a un humano?

Por eso no basta con poner un modelo potente detrás de un chat. Si el agente no tiene un arnés, improvisa el contexto, inventa rutas, repite errores y puede confundir actividad con avance.

La definición práctica: el sistema que hace confiable al agente

En la práctica, un harness reúne seis piezas.

1. Una misión con una definición verificable de “terminado”

“Mejora el sitio” no es una tarea operable. “Reduce el peso de esta página sin romper el formulario, mantén el puntaje móvil por encima de 85 y deja evidencia antes/después” sí lo es.

El harness traduce una intención humana a criterios de aceptación. Así el agente no persigue una interpretación vaga: persigue una condición observable.

2. Contexto navegable, no una enciclopedia arrojada al modelo

Un agente necesita saber qué negocio está atendiendo, cómo está estructurado el sistema, qué reglas no puede romper y dónde encontrar la información pertinente. Pero darle un documento interminable no resuelve el problema: lo oculta.

OpenAI reporta que, en su trabajo con Codex, un archivo corto de instrucciones sirve mejor como mapa hacia documentación estructurada y versionada que como manual enciclopédico. El objetivo es que la información correcta sea localizable y vigente, sin llenar el contexto de reglas que compiten entre sí.[1]

Dicho de otra manera: el harness no le entrega al agente toda la biblioteca; le da catálogo, mapa y permisos para llegar al estante correcto.

3. Herramientas con permisos y fronteras claras

Un agente útil necesita herramientas: puede consultar un CRM, leer documentos, ejecutar pruebas, abrir un ticket, preparar un borrador o actualizar una base de conocimiento.

Pero cada herramienta debe tener una frontera. Preparar una cotización no es lo mismo que enviarla. Detectar una factura vencida no es lo mismo que cobrarla. Crear una rama no es lo mismo que desplegar a producción.

Un buen harness convierte esa diferencia en permisos concretos:

La autonomía no es una barra que se sube de golpe. Es una escalera de responsabilidades.

4. Memoria externa: el agente debe poder entregar el turno

Los agentes no trabajan siempre dentro de una única conversación perfecta. Una tarea puede durar horas, requerir varios intentos o continuar con otra sesión. Si el estado solo vive en la ventana de contexto, el trabajo se reinicia cada vez que el agente pierde el hilo.

Anthropic propone un patrón claro para trabajo de larga duración: preparar el entorno al inicio y dejar una lista de funcionalidades, notas de progreso, commits y pruebas para que la siguiente sesión pueda retomar sin adivinar qué pasó.[2]

Esto aplica mucho más allá del código. Para un agente comercial, la memoria externa puede ser el CRM y un registro de decisión. Para un agente de operaciones, una bitácora de incidentes. Para uno de contenido, un brief, fuentes verificadas y el estado editorial de cada pieza.

La pregunta no es “¿el agente recuerda?”. La pregunta útil es: **“si mañana otra persona toma este caso, puede entender qué se hizo, por qué y qué falta?”**

5. Verificación: no confundir una respuesta con un resultado

El mayor error al adoptar agentes es medir la calidad por lo convincente que suena la respuesta. Un harness mide el resultado en el mundo real.

En desarrollo eso puede ser una prueba automatizada, un linter, una revisión de cambios o un despliegue en staging. En ventas puede ser que los datos del lead coincidan con el CRM, que la propuesta use la lista de precios vigente y que no se haya enviado sin aprobación. En servicio al cliente puede ser una política cumplida y un caso correctamente escalado.

OpenAI describe este cambio como la construcción de herramientas, abstracciones y bucles de retroalimentación que permiten a los agentes hacer trabajo confiable. También enfatiza que las restricciones arquitectónicas y de calidad deben verificarse mecánicamente, no quedar como sugerencias en una instrucción.[1]

La regla es simple: **si no hay una forma de comprobarlo, el agente no ha terminado; solo ha hablado de terminar.**

6. Guardrails y escalamiento: saber cuándo no avanzar

Un arnés no sirve para obligar al caballo a atravesar cualquier cosa. Sirve para controlarlo cuando el terreno cambia.

Un buen harness define señales de alto:

• Falta información crítica.
• Dos fuentes confiables se contradicen.
• La acción afecta dinero, reputación, datos personales o producción.
• La política no cubre el caso.
• La verificación falla repetidamente.

En esas situaciones, el comportamiento correcto no es “ser más autónomo”. Es detenerse, explicar el bloqueo y pedir una decisión concreta. La confianza en un agente no nace de que nunca pregunte; nace de que no tome decisiones irreversibles cuando no debería.

Tres casos: así se ve un harness fuera de una presentación

Caso 1: un agente comercial que prepara propuestas, pero no improvisa precios

Sin harness, el agente recibe un lead, escribe una propuesta persuasiva y hasta puede sugerir un descuento inventado. El texto puede sonar excelente y aun así ser un problema comercial.

Con harness:

1. Lee solamente los campos autorizados del CRM. 2. Consulta una lista de servicios y precios versionada. 3. Identifica el segmento y el objetivo del cliente. 4. Redacta una propuesta con una plantilla aprobada. 5. Señala vacíos o inconsistencias en vez de rellenarlos. 6. Deja el documento en estado **borrador**. 7. Solicita aprobación si hay descuento, condición especial o dato ausente. 8. Registra qué fuentes usó y qué decisión queda pendiente.

El resultado no es “un agente que vende solo”. Es un sistema que reduce trabajo repetitivo sin soltar el control comercial.

Caso 2: un agente de desarrollo que no declara victoria antes de probar

Sin harness, un agente modifica varios archivos, dice “listo” y deja una regresión escondida.

Con harness:

1. Lee la arquitectura, las convenciones y el plan activo. 2. Trabaja en una rama aislada. 3. Hace cambios pequeños y trazables. 4. Ejecuta las pruebas relevantes. 5. Revisa el diff contra los criterios de aceptación. 6. Deja una nota de progreso y evidencia de validación. 7. No marca la tarea como terminada si una prueba falla.

La idea coincide con la investigación de Anthropic: una lista explícita de funcionalidades, verificación antes de marcar algo como aprobado y artefactos de traspaso reducen los fallos típicos de los agentes que trabajan por muchas sesiones.[2]

Caso 3: un agente de operaciones que detecta una anomalía y no la oculta

Supongamos que un agente monitorea renovaciones de dominio o facturas. Su trabajo no debería ser “resolver a cualquier costo”; debería ser mantener el proceso visible y seguro.

Un harness puede indicarle que:

• compare la fecha con la fuente oficial;
• clasifique el riesgo por urgencia;
• abra un caso con la evidencia;
• envíe una alerta con una recomendación;
• nunca renueve, transfiera, cobre o cancele sin la autorización requerida.

Eso es valioso porque evita dos extremos: el agente que no hace nada y el agente que actúa demasiado.

El trabajo de un harness engineer

Llamar a esto *harness engineering* importa porque cambia dónde está el valor humano.

El trabajo ya no es únicamente escribir instrucciones más ingeniosas. Es diseñar la infraestructura de trabajo del agente:

• convertir objetivos de negocio en criterios de aceptación;
• ordenar el conocimiento para que sea encontrable;
• seleccionar herramientas y definir permisos;
• crear pruebas, validaciones y rutas de aprobación;
• instrumentar registros para saber qué hizo el agente;
• capturar cada error útil como una mejora del sistema.

La evidencia de los equipos que construyen agentes serios apunta al mismo lugar: cuando el agente falla, la solución recurrente no es repetir “hazlo mejor” en el prompt. Es descubrir qué capacidad, dato, regla, herramienta o comprobación faltaba y añadirla al entorno.[1]

Ese cambio es profundo. En lugar de administrar un modelo como si fuera un empleado que necesita más entusiasmo, se construye una operación donde una capacidad probabilística puede producir resultados verificables.

Cómo empezar sin construir una plataforma enorme

No hace falta lanzar diez agentes ni comprar una capa compleja de orquestación. Empieza por un flujo repetitivo, con impacto medible y riesgo controlado.

Semana 1: escoge una tarea, no un departamento

Ejemplos: preparar una primera respuesta a leads, clasificar solicitudes entrantes, detectar vencimientos, resumir una reunión con acciones o revisar borradores contra una guía editorial.

Semana 2: diseña el arnés mínimo

Escribe en una sola página:

• entrada permitida;
• salida esperada;
• fuentes autorizadas;
• acciones permitidas y prohibidas;
• criterio de terminado;
• caso en que debe escalar;
• evidencia que debe dejar.

Semana 3: observa los fallos reales

No corrijas cada salida manualmente en silencio. Clasifica el motivo: ¿faltó contexto?, ¿la fuente no era confiable?, ¿el permiso era demasiado amplio?, ¿no existía una prueba?, ¿la definición de listo era ambigua?

Semana 4: convierte la corrección en sistema

La mejora correcta suele ser una nueva fuente de verdad, una validación, una plantilla, una regla de permiso o una prueba. Así el aprendizaje deja de depender de que alguien recuerde el error la próxima vez.

El futuro no es “más agentes”; es mejores arneses

La carrera por modelos más capaces va a continuar. Pero para una empresa, la pregunta decisiva no será únicamente qué modelo contrató. Será si puede convertir esa capacidad en una operación que mantiene contexto, respeta límites y deja evidencia.

Un caballo veloz puede cruzar el desierto. Sin arnés, no necesariamente lleva nada útil. Con el arnés correcto, fuerza, dirección y carga llegan juntas.

Eso es *harness engineering*: diseñar el sistema que permite que un agente deje de ser una buena conversación y se convierta en trabajo confiable.

*Artículo escrito por **Estudio Naranja** — IA agéntica para empresas latinoamericanas.* *Bogotá, Colombia — agosto de 2026*

Sources

[1] https://openai.com/index/harness-engineering — Harness engineering: leveraging Codex in an agent-first world [2] https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents — Effective harnesses for long-running agents