Harness Engineering: por qué el 88% de los agentes de IA nunca llegan a producción

El 88% de los proyectos de agentes de IA nunca llega a producción. El 95% de los pilotos empresariales de IA entrega cero ROI medible. Y en el 65% de las fallas empresariales de IA, la causa no es el modelo — es el harness.

Casi nadie diseña el harness a propósito. Se acumula solo, entre un prompt aquí, un tool ahí, un parche de contexto cuando algo se rompe. El resultado: un sistema que funciona en la demo y colapsa la primera semana en producción.

El motor no es el sistema operativo

Harness engineering es la disciplina de diseñar los sistemas de control que gobiernan cómo un agente de IA percibe su entorno, elige acciones y valida sus salidas. En otras palabras: todo lo que rodea al LLM — contexto, herramientas, memoria, loop de ejecución, guardarraíles — tratado como ingeniería de primera clase, no como detalle de implementación.

La analogía correcta no es “el LLM es la app”. Es esta:

El LLM es el motor. El harness es el sistema operativo que lo hace útil. Cambiar de modelo sin tocar el harness es como poner un motor más potente en un auto sin frenos.

Los tres defectos que matan un agente en producción

Casi todas las fallas de agentes en producción se reducen a tres patrones:

• Context drift — el contexto acumulado deriva hasta que el agente olvida el objetivo original.
• Schema misalignment — el agente llama herramientas con parámetros incorrectos porque el contrato no está bien definido.
• State degradation — el estado se corrompe entre turnos, y el agente empieza a actuar sobre información obsoleta.

Ninguno de los tres se arregla cambiando de modelo. Los tres se arreglan diseñando el harness.

El equipo de LangChain movió su agente de código del puesto 30 al puesto 5 en Terminal Bench 2.0 sin cambiar el modelo — solo optimizando el harness.

Las capas del harness

Un harness maduro se puede formalizar como:

H = (E, T, C, S, L, V)

E → Environment   — percepción del entorno externo
T → Tools         — registro de acciones disponibles
C → Context       — gestión de la ventana de contexto
S → State         — memoria y persistencia entre turnos
L → Loop          — el ciclo Observe → Think → Act → Validate
V → Validation    — quality gates antes de que algo salga al usuario

En la práctica, esto se organiza en capas: herramientas e integración en la base, memoria y contexto por encima, el LLM en el medio (no en la cima), y orquestación, validación y observabilidad por arriba. El error más común es tratar al LLM como si fuera el sistema completo, cuando en realidad es una sola capa de siete.

Qué hacer con esto

No hace falta construir un harness enterprise desde el día uno. Lo que sí conviene, en cualquier proyecto que use agentes de IA en serio:

• Contexto persistente por proyecto (no reexplicar todo cada sesión).
• Memoria de largo plazo separada del contexto de la conversación activa.
• Un loop de validación explícito antes de que una salida se considere “terminada”.
• Logs mínimos de qué hizo el agente y por qué — sin esto, no hay forma de auditar un error después.

La regla que evita sobre-ingeniería: no formalizar lo que todavía no duele. Agregar una capa del harness solo cuando hay fricción real, no porque “suena a buena práctica”. Un harness sobrediseñado es tan frágil como uno que no existe.