Harness Engineering: La Capa de Madurez Después de Prompt y Context Engineering

Los equipos pasan semanas refinando prompts y armando paquetes de contexto, y luego culpan al modelo cuando el agente se detiene a mitad de una tarea. El modelo rara vez es el problema. La brecha de confiabilidad vive en el harness: el software que rodea al modelo y decide qué ve, qué puede hacer y qué ocurre cuando falla. Acabamos de publicar un conjunto de nuevos términos de glosario y recursos que nombran esta capa y la práctica de construirla.

Qué es un Harness en la Práctica

Un agent harness es el software no-modelo que convierte un modelo de lenguaje en un agente funcional. Es el loop, las herramientas, la gestión de contexto, la memoria, la lógica de recuperación y las salvaguardas. El modelo aporta el razonamiento. El harness aporta todo lo que hace que ese razonamiento opere sobre una base de código real.

En el centro está el agent loop: el ciclo de control modelo-herramienta-observación que se ejecuta hasta que la tarea termina o se detiene. El modelo propone una acción, el harness ejecuta una herramienta, el resultado regresa como una observación y el ciclo se repite. Plan-and-execute (Wang et al., 2023, implementado en LangChain como Plan-and-Execute) y ReAct (Yao et al., 2023) son formas específicas de este loop, no alternativas al mismo.

Tres decisiones de diseño dentro del harness determinan si ese loop produce trabajo confiable:

• Diseño de herramientas: cómo se nombran las herramientas, qué tan granulares son, qué dicen sus mensajes de error y cuándo se carga su documentación. Una herramienta que devuelve un error vago no le enseña nada al agente. Una herramienta que devuelve un error preciso y accionable le permite corregirse a sí mismo.
• Compactación de contexto: reducir el contexto acumulado del agente a mitad de una ejecución mediante resúmenes o reinicios completos, para que una tarea larga permanezca dentro de la ventana sin perder el estado necesario para terminarla.
• Divulgación progresiva: organizar la información por relevancia y cargar solo lo que el agente necesita en cada etapa, en lugar de adelantar todo de golpe y ahogar al modelo en ruido.

Ninguna de estas es una configuración del modelo. Son decisiones de ingeniería, y es de ellas de donde proviene la mayor parte de la confiabilidad.

De Claude Code a Harnesses de Código Abierto

El concepto de harness no es abstracto. Es la categoría a la que pertenecen las herramientas de programación agéntica más comunes.

Los dos ejemplos más claros son Claude Code y Codex CLI. Claude Code es el agente de línea de comandos de Anthropic: un loop nativo de terminal con edición de archivos, ejecución de comandos y contexto a nivel de toda la base de código. Codex CLI es el agente de línea de comandos de OpenAI que ocupa el mismo rol para sus modelos. Ambos son harnesses en el sentido preciso que se usa aquí. Envuelven un modelo en un loop, un conjunto de herramientas y una estrategia de contexto, y las diferencias entre ellos son diferencias de diseño de harness, no de capacidad bruta del modelo.

Otros harnesses ampliamente utilizados llevan la misma idea a distintas superficies: Cursor y Windsurf integran el loop en un editor, GitHub Copilot ejecuta un modo agente dentro del flujo de trabajo existente del desarrollador, y Aider y Opencode son agentes de línea de comandos de código abierto. El modelo subyacente suele ser el mismo en varias de estas herramientas. Lo que las distingue es el harness: cómo gestionan el contexto, diseñan sus herramientas y se recuperan de los fallos.

Esta es la conclusión práctica. Cuando dos equipos que usan el mismo modelo obtienen resultados diferentes, el harness suele ser la variable.

Harness Engineering como Disciplina Emergente

El harness engineering es la disciplina de diseñar e iterar el harness para que el agente funcione de manera confiable. Es la capa de madurez que sigue al prompt engineering y al context engineering. El prompt engineering mejora una instrucción individual. El context engineering mejora lo que el agente conoce. El harness engineering mejora el sistema que ejecuta al agente a lo largo de muchos pasos, y se mide por si el agente termina el trabajo correcto sin supervisión.

¿En qué consiste el harness engineering en la práctica? Es menos una lista de verificación que un conjunto de principios de diseño, y un harness popular es el lugar más claro para verlos en acción. Consideremos los principios dentro de Claude Code:

• Un agent loop ajustado sobre herramientas reales. El modelo actúa, observa el resultado y se corrige, en lugar de producir una respuesta grande de forma aislada.
• Gestión deliberada del contexto. La memoria persistente del proyecto, la recuperación y la compactación mantienen la información correcta en la ventana en lugar de incluir todo (context engineering).
• Herramientas diseñadas para el agente. Los nombres claros y los mensajes de error accionables permiten que el modelo se recupere por sí solo (tool design).
• Salvaguardas y supervisión humana. Los permisos y las aprobaciones controlan las acciones sensibles en lugar de confiar ciegamente en el agente.
• Verificación antes de la finalización. El agente comprueba su trabajo contra una fuente de verdad, como pruebas y compilaciones, antes de declarar que una tarea está terminada.
• Interfaces estables sobre un núcleo cambiante. La superficie que usa el desarrollador se mantiene estable mientras se ajustan los componentes internos (building effective agents).

Estos principios, y no el modelo subyacente, son lo que hace que un harness sea confiable. Anthropic documenta cómo se sostienen a escala en harnesses for long-running agents.

Esta es también la razón por la que la mayoría de las empresas no deberían construir su propio harness. Los laboratorios de frontera y un puñado de startups especializadas iteran sobre estos sistemas a tiempo completo, con benchmarks privados y mucho más signal del que cualquier organización de ingeniería individual puede reunir. Para la mayoría de los equipos, la mejor decisión es adoptar un harness maduro e invertir el esfuerzo ahorrado una capa más arriba. Construir el harness es donde los laboratorios y las startups están mejor posicionados. Construir sobre él es donde todos los demás crean ventaja.

El agent loop se encuentra dentro del harness: el modelo actúa, las herramientas devuelven observaciones, y el harness gestiona el contexto, las salvaguardas y la recuperación alrededor del ciclo.

Del Harness a la Productividad

Un harness sigue siendo un lienzo abierto. Funciona como una herramienta de CI: proporciona el sustrato de ejecución, pero el valor proviene de lo que se construye encima. Los patrones de diseño, las habilidades curadas o personalizadas, los procesos de revisión y los controles son lo que convierten un harness genérico en la forma en que un equipo específico construye software.

Este es el rol del meta-harness: la abstracción que integra un harness en las formas de trabajo de una empresa o un desarrollador. En la práctica, esto puede implicar coordinar más de un harness, aunque no necesariamente. La función esencial es la integración: codificar los patrones, las habilidades y las salvaguardas en el harness para que viajen con el trabajo en lugar de vivir en la cabeza de una sola persona.

La pila: la capa del modelo es un insumo compartido, el harness la hace operativa, y el meta-harness la integra en las formas de trabajo de un equipo. El apalancamiento aumenta a medida que se sube.

Formalmente, un meta-harness es un sustrato o plano de control que aloja múltiples agent harnesses intercambiables y conectables en un runtime compartido. El nuevo recurso Omnigent es un ejemplo concreto: un meta-harness de código abierto de Databricks que se sitúa por encima de los agentes de programación existentes, incluidos Claude Code y Codex CLI, y los hace componibles, controlables y compartibles a través de una sola interfaz bajo Apache 2.0. El caso de múltiples harnesses es el más visible, pero la misma capa de integración sigue siendo relevante incluso cuando un equipo estandariza en un solo harness.

Un harness que se auto-mejora va más lejos. Observa sus propias ejecuciones, edita su propio andamiaje y conserva un cambio solo cuando ese cambio supera un benchmark de referencia. Esto es harness engineering aplicado de forma recursiva, con una salvaguarda estricta: una validación determinista contra un benchmark decide qué sobrevive, no el juicio del propio agente sobre su trabajo.

Conclusiones

• El harness es la variable, no el modelo. Cuando los agentes tienen un rendimiento inferior con el mismo modelo, audita primero el agent loop, el diseño de herramientas y la estrategia de contexto.
• No construyas tu propio harness. Adopta uno maduro. Los laboratorios y las startups especializadas están mejor posicionados para construir harnesses; tu tiempo está mejor invertido en otra parte.
• Invierte una capa más arriba. La diferenciación vive en tus formas de trabajo: patrones, habilidades curadas o personalizadas, procesos de revisión y controles, integrados a través de la capa meta-harness.
• Trata el modelo como un insumo. Los mismos modelos están disponibles para todos, por lo que la ventaja sube en la pila.

Los nuevos términos del glosario le dan a esta capa un vocabulario compartido. La práctica de construirla bien es el harness engineering, y es lo que decide si los agentes se convierten en un pasivo o en un multiplicador de fuerza.