El secreto detrás de los agentes de IA: ¿qué es un AI Agent Harness?

En algún momento de 2025, quedó claro que "conectar un modelo de lenguaje a una API" no era lo mismo que "construir un agente confiable". Un modelo puede razonar, escribir y planear. Pero por sí solo no puede recordar lo que hizo ayer, no sabe qué tiene permitido tocar, y no tiene forma de comprobar si su propio trabajo salió bien.

A todo lo que rodea al modelo para que pueda operar de verdad —herramientas, memoria, permisos, supervisión— se le está empezando a llamar AI Agent Harness (arnés del agente).

La analogía más simple: el cerebro y el arnés

El modelo es el cerebro. El harness es el entorno que permite que ese cerebro pueda trabajar.

Un cerebro humano, por brillante que sea, no puede hacer nada por sí solo sin un cuerpo: sin manos para actuar, sin ojos para observar el resultado, sin memoria para recordar lo que ya intentó, sin reglas sociales que le digan qué puede y qué no puede hacer.

Un modelo de IA está en la misma posición. Es extraordinario razonando sobre texto, pero no tiene manos, no tiene memoria persistente por defecto, y no tiene ningún mecanismo propio para saber si el correo que acaba de "enviar" realmente salió o si el archivo que "modificó" quedó bien.

El harness es lo que le da manos, ojos, memoria y límites.

Qué componentes puede incluir un harness

No existe un único harness estándar todavía, pero la mayoría de las implementaciones serias incluyen algunos de estos bloques:

• Herramientas — funciones concretas que el agente puede invocar: leer un archivo, mandar un correo, consultar una base de datos
• Memoria — qué recuerda el agente entre una tarea y otra, y cómo decide qué vale la pena recordar
• Contexto — qué información relevante se le entrega en cada momento, sin saturarlo con todo lo que existe
• Permisos — qué puede hacer sin pedir confirmación, y qué requiere aprobación humana
• Ejecución — el mecanismo real que corre el código o la acción que el modelo decidió tomar
• Sandbox — un entorno aislado donde el agente puede actuar sin poner en riesgo sistemas reales
• Observabilidad — registro de qué hizo el agente, en qué orden, y por qué, para poder auditarlo después
• Evaluación — formas de medir si el trabajo del agente realmente cumplió el objetivo, no solo si "no truena"
• Guardrails — límites explícitos sobre lo que el agente nunca debe hacer, pase lo que pase
• Ciclos de planificación y ejecución — el bucle que permite al agente proponer un plan, ejecutar un paso, observar el resultado, y ajustar el siguiente paso

Ningún modelo trae esto incluido. Todo esto se construye alrededor del modelo, y es exactamente ese "alrededor" lo que se llama harness.

LLM → Agent → Agent Harness

Conviene separar tres capas que suelen mezclarse en la conversación:

LLM (modelo de lenguaje)
   → puede razonar y generar texto, pero no puede actuar por sí solo

Agent (agente)
   → un LLM al que se le dan herramientas concretas: puede leer, escribir, ejecutar acciones puntuales

Agent Harness (infraestructura del agente)
   → todo el entorno que rodea al agente: memoria persistente, permisos, sandbox,
     observabilidad, evaluación, y el ciclo de planificación-ejecución que lo hace confiable
     en tareas largas y repetidas, no solo en una sola respuesta

Un LLM contesta una pregunta. Un agente puede completar una tarea de varios pasos. Un agente con un harness serio puede operar durante horas o días, en tareas largas, sin que alguien tenga que vigilar cada paso —y con la posibilidad real de auditar después qué hizo y por qué.

Por qué esto se está volviendo importante en 2026

Mientras los agentes se usaban para tareas cortas —contestar una pregunta, generar un texto, resumir un documento— el harness importaba poco. Un error se notaba de inmediato y se corregía en la siguiente respuesta.

Pero en 2026 los agentes ya ejecutan tareas que duran horas, que tocan sistemas reales, y que a veces corren sin supervisión humana constante. En ese escenario, la pregunta ya no es "¿qué tan bueno es el modelo?", sino "¿qué tan bien está construido todo lo que rodea al modelo?".

Dos agentes con el mismo modelo exacto pueden comportarse de forma completamente distinta según el harness que los rodea: uno con buena memoria, buenos permisos y buena observabilidad será confiable; el mismo modelo, sin ese entorno, puede repetir errores, perder contexto a mitad de una tarea larga, o hacer algo que nadie autorizó.

Qué pasa cuando un agente trabaja sin infraestructura adecuada

Sin memoria persistente, un agente puede olvidar una decisión que tomó hace diez minutos y contradecirla.

Sin permisos bien definidos, un agente puede ejecutar una acción irreversible —borrar algo, enviar algo, gastar algo— sin que nadie la haya aprobado.

Sin sandbox, un error del agente puede afectar directamente un sistema de producción en vez de quedar contenido en un entorno seguro.

Sin observabilidad, cuando algo sale mal, nadie puede reconstruir qué pasó ni por qué el agente tomó esa decisión.

Sin evaluación, una tarea puede "verse terminada" sin que en realidad cumpla el objetivo real que se pidió.

Ninguno de estos problemas se arregla usando un modelo "más inteligente". Se arreglan construyendo mejor el entorno alrededor del modelo. Ese es, precisamente, el trabajo del harness.

Harness Engineering: ¿una nueva disciplina?

Conforme más equipos construyen agentes para tareas reales, está apareciendo un tipo de trabajo que no es exactamente "entrenar modelos" ni tampoco "hacer prompts": es diseñar el entorno operativo completo en el que un agente vive y trabaja.

A este trabajo se le empieza a llamar Harness Engineering (ingeniería de arneses): decidir qué herramientas tiene el agente, cómo se estructura su memoria, qué permisos tiene por defecto, cómo se sandboxean sus acciones, y cómo se evalúa si su trabajo fue correcto.

Es un trabajo distinto al de escribir un buen prompt, y distinto también al de entrenar o afinar un modelo. Se parece más a diseñar la infraestructura de un sistema distribuido que a "hablarle bien" a una IA. Y conforme los agentes toman más responsabilidad en tareas reales, este trabajo de infraestructura puede volverse tan especializado como cualquier otra disciplina de ingeniería.

El modelo ya no es el único protagonista

Durante un par de años, la conversación pública sobre IA giró casi por completo alrededor de qué tan grande o qué tan inteligente era el modelo de turno. Esa conversación está cambiando.

Conforme los agentes ejecutan tareas más largas y más autónomas, la infraestructura que los rodea —memoria, permisos, sandboxing, evaluación, gobernanza— se vuelve tan importante como el modelo mismo. Un cerebro brillante sin un buen entorno para actuar sigue sin poder hacer nada útil de forma confiable.

Paso a paso para construir un harness básico, con Claude

Cada pieza de un harness tiene un equivalente concreto cuando trabajas con Claude Code:

• Herramientas → los MCP servers que actives (Odoo, Gmail, GitHub...) más las herramientas nativas (Bash, lectura y edición de archivos, búsqueda web)
• Memoria → un archivo CLAUDE.md en el proyecto, con el contexto que no quieres repetir cada sesión
• Permisos → los modos de permiso de Claude Code (ask, acceptEdits, bypassPermissions) y las reglas de allow/deny en la configuración
• Sandbox → un git worktree o un entorno de pruebas aislado, donde Claude puede equivocarse sin tocar el proyecto real
• Observabilidad → el transcript de la sesión y los hooks (PreToolUse/PostToolUse) que registran cada acción
• Evaluación → correr pruebas automatizadas o un checklist de verificación antes de dar el trabajo por terminado
• Guardrails → reglas de deny explícitas para lo irreversible (rm -rf, git push --force)

El paso a paso práctico:

1. Activa solo los MCP servers que la tarea necesita — si Claude va a cotizar, no le des acceso al sistema de nómina.
2. Escribe un CLAUDE.md corto con el contexto del proyecto, para que Claude no dependa de que se lo repitas cada vez.
3. Configura permisos específicos: por ejemplo, permite git status sin preguntar, pero exige confirmación para git push.
4. Aísla el trabajo riesgoso en un git worktree — Claude trabaja en una copia del repo, y tú revisas antes de fusionar a la rama principal.
5. Revisa el transcript de la sesión para ver exactamente qué comandos corrió y en qué orden.
6. Verifica con pruebas automatizadas antes de aceptar el resultado — "compiló" no es lo mismo que "funciona".
7. Agrega reglas de deny para las acciones que nunca quieres que Claude tome sin ti, sin excepción.