Harness Engineering: la capa que decide si tus agentes llegan a producción
Tabla de contenidos
Stripe mergea más de 1.300 pull requests por semana sin que un humano escriba el código; solo lo revisa. El equipo de Codex en OpenAI generó cerca de un millón de líneas en cinco meses, arrancando con tres ingenieros y cero código escrito a mano. Entre el modelo de IA y esos resultados hay una capa de la que aún casi nadie habla, pero tiene nombre desde hace pocos meses: el arnés. Y quien lo diseña es el Harness Engineer.
¿Qué es el harness engineering y para qué sirve?
Mitchell Hashimoto, cofundador de HashiCorp, popularizó el término en febrero de 2026 con una fórmula que se ha vuelto canónica: Agent = Model + Harness. El modelo aporta la inteligencia. El arnés es todo lo demás: el contexto, las herramientas, los sandboxes, los feedback loops, los permisos y la observabilidad que rodean al modelo y convierten su inteligencia en trabajo verificable.
La metáfora que mejor lo explica: si el modelo es la CPU y el contexto es la RAM, el harness es el sistema operativo. El agente es la aplicación que corre encima. Al igual que sin un buen sistema operativo, la CPU más potente del mundo no hace nada útil.
Por qué el modelo no es el cuello de botella en harness engineering
Cuando un agente falla en producción, el instinto es cambiar de modelo. Sin embargo, los datos dicen que el instinto se equivoca.
Vercel publicó que eliminó el 80% de las herramientas de su agente de texto-a-SQL. La tasa de éxito pasó del 80% al 100%, con respuestas 3,5 veces más rápidas y un 37% menos de tokens. Mismo modelo, mejor arnés.
LangChain llevó su agente de programación de la posición 30 a la 5 en el benchmark Terminal-Bench 2.0 (casi 14 puntos de mejora) sin tocar el modelo.
El patrón se repite en cada caso documentado: el cuello de botella es el entorno que has construido y la arquitectura que le has asociado.
Domina harness engineering en el Máster AI4Devs
El harness también es una decisión económica
Cada herramienta que añades al harness añade tokens. Cada llamada innecesaria que hace el agente tiene un precio. Un arnés mal diseñado no solo produce peores resultados, también cuesta más.
El caso Vercel lo cuantifica: mismo agente, harness simplificado, 37% menos de tokens por consulta. A escala, esa diferencia determina si el producto es rentable o no.
Pero hay una palanca de coste aún más directa: el diseño del harness para maximizar cache hits. Según la documentación técnica de Anthropic, los tokens en caché cuestan el 10% de los tokens de entrada base. Un harness diseñado con contenido estático primero y dinámico al final puede aplicar ese descuento a la mayor parte del contexto que inyecta en cada llamada.
La pregunta que el equipo de Anthropic usa para iterar su harness lo resume bien: «¿Qué puedo dejar de hacer?» Cada componente del harness que retiras porque el modelo ya no lo necesita es un ahorro de tokens, latencia y mantenimiento.
Anatomía de un harness: las 5 primitivas de cualquier agente en producción
Vivek Trivedy, de LangChain, identifica cinco componentes mínimos de cualquier harness:
- Filesystem: almacenamiento durable donde el agente guarda y recupera estado entre pasos.
- Ejecución de código. darle al agente una terminal es darle una computadora de propósito general.
- Sandbox: ejecución aislada para que el agente actúe sin riesgo de romper producción.
- Memoria y búsqueda: aprendizaje continuo tanto de las instrucciones del proyecto, como la búsqueda web y bases de conocimiento vectoriales.
- Gestión del contexto: compactación y descarga de información para combatir el context rot.
Context Engineering y Harness Engineering: no es lo mismo
La quinta primitiva merece una aclaración que el sector confunde con frecuencia: el harness y el context engineering no son lo mismo.
El Context Engineering define qué información necesita el agente para hacer su trabajo (las especificaciones técnicas del proyecto, el flujo del equipo, las convenciones compartidas). El harness decide cuándo inyectarla, cuándo compactarla y cuándo descartarla.
El propio equipo de Anthropic Engineering documentó un ejemplo concreto de lo que ocurre cuando el harness no gestiona bien el contexto: algunos modelos exhiben lo que llaman context anxiety; empiezan a cerrar tareas prematuramente cuando detectan que se acercan al límite de la ventana de contexto, aunque aún quede trabajo pendiente. La solución fue añadir un mecanismo de reset en el harness.
La conclusión que extraen es aplicable a cualquier equipo que trabaje con agentes: cada componente del harness codifica una asunción sobre lo que el modelo no puede hacer solo y esas asunciones vale la pena revisar con cada actualización del modelo.
Si tus agentes toman decisiones que deberían estar en el contexto, el harness no lo está entregando en el momento correcto.
[Artículo relacionado] Cómo diseñar las tres capas de contexto que el harness va a gestionar: Context Engineering: qué es y cómo aplicarlo en código con IA.
Guías y sensores: cómo el arnés controla al agente
Birgitta Böckeler (Thoughtworks) propuso la taxonomía que hoy usa el sector. El harness controla al agente con dos mecanismos complementarios:
- Las guías (feedforward) actúan antes de que el agente ejecute. El archivo AGENTS.md con las convenciones del proyecto, los linters y las restricciones de arquitectura marcan el camino por adelantado.
- Los sensores (feedback) actúan después. Tests, evaluaciones, validación en navegador u otro LLM revisando el output le dicen si lo hizo bien.
Cada mecanismo puede ser computacional (determinista: un test que pasa o falla) o inferencial (otro modelo emitiendo un juicio). Un buen harness combina los cuatro tipos; uno malo se queda solo en el prompt y reza.
Qué hace un Harness Engineer en su día a día
La práctica central la definió Hashimoto: cada vez que el agente comete un error, no lo corriges a mano, sino que diseñas un control para que ese error no pueda repetirse nunca más. Es un trinquete. El sistema solo avanza.
En la práctica, eso se traduce en entregables concretos: mantener el AGENTS.md del repositorio, escribir hooks que bloqueen patrones prohibidos antes de que se ejecuten, construir la suite de evals que corre en CI, configurar la observabilidad (qué decidió el agente, cuánto costó en tokens, dónde falló) y desplegar sub-agentes especializados para tareas acotadas.
Es decir construye la carrocería que convierte un motor probabilístico en algo que se puede operar con confianza.
Harness Engineer vs AI Engineer vs Agentic Engineer
| Rol | Foco principal | Su pregunta central |
|---|---|---|
| Agentic Engineer | Orquestar agentes en el flujo de desarrollo | ¿Cómo hago que los agentes ejecuten con criterio? |
| AI Engineer | Construir productos donde la IA es el corazón | ¿Qué sistema de IA construyo y con qué modelo? |
| MLOps Engineer | Ciclo de vida del modelo | ¿Cómo despliego y monitorizo el modelo? |
| Harness Engineer | El entorno de ejecución del agente | ¿Qué parte del arnés está fallando? |
El Harness Engineer no sustituye a ninguno de ellos. Trabaja en la capa que está fuera del modelo y debajo del agente, la que hace que todo lo demás sea fiable cuando hay usuarios reales al otro lado.
El harness engineering es tu nueva skill como developer
Harness Engineer como tal aún no aparece en las ofertas de trabajo. Y no sabemos cuándo aparecerá como título formal.
Lo que sí está cambiando es qué se espera de cualquier developer que trabaje con agentes. Diseñar el entorno de ejecución, añadir evals cuando el agente falla, versionar las convenciones en AGENTS.md, conectar observabilidad; estas ya no son tareas de un equipo especializado y forman parte de tu rol.
En definitiva, el harness es la diferencia entre un agente que impresiona en una demo y uno que aguanta en producción. El modelo lo pone el laboratorio. El harness lo pones tú.
Y en 2026, la habilidad que separa a quien enseña vídeos de agentes de quien los tiene corriendo en producción es saber construir el entorno que hace que Claude Code no invente nada.