¿Qué es un agent harness? Cómo los agentes de IA obtienen herramientas, memoria y control

La idea no es totalmente nueva. Los desarrolladores llevan años creando envoltorios, andamiajes y entornos de ejecución alrededor de los modelos. La etiqueta se popularizó después de que Mitchell Hashimoto, cofundador de HashiCorp, usara "harness engineering" en una entrada de su blog en febrero de 2026 sobre su flujo de trabajo en IA. Su punto era simple: cuando un agente comete un error, cambia el entorno para que ese error no pueda volver a ocurrir. OpenAI adoptó el término esa misma semana para su trabajo con Codex, y LangChain siguió con el mismo enfoque.

En este artículo te explico qué es un agent harness, por qué los agentes de IA lo necesitan, en qué se diferencia de los frameworks y los runtimes, y qué herramientas usan los desarrolladores para crear sistemas de tipo harness.

¿Qué es un agent harness?

Una definición la aporta LangChain: "Si no eres el modelo, eres el harness". En la práctica, un agent harness es el software que rodea a un modelo de lenguaje: herramientas, memoria, estado, ejecución, guardarraíles y observabilidad.

Agente = Modelo + Harness

El modelo razona. El harness le da a ese razonamiento un lugar donde actuar, recordar, comprobar resultados y seguir reglas.

Modelo dentro de su agent harness de trabajo. Imagen del autor.

La fórmula es útil, pero es un modelo mental, no un estándar del sector. Algunos proveedores siguen usando "harness", "framework" y "scaffold" con significados parecidos.

Por qué los agentes de IA necesitan un harness

Un modelo de lenguaje en bruto tiene límites cuando le pides trabajar en múltiples pasos. Por sí solo no mantiene un estado duradero, no ejecuta herramientas, no gestiona un contexto creciente ni se recupera de llamadas a herramientas fallidas sin ayuda.

Imagina un agente al que se le pide arreglar un test que falla en un proyecto de Python. Sin un harness, el modelo puede escribir algo que parezca un arreglo, pero no puede leer el archivo de test real, ejecutar pytest, ver el error, editar la función que falla o confirmar que el arreglo pasa. Con un harness, todo ese bucle se convierte en unos minutos de trabajo que el propio agente realiza, con cada paso registrado en algún sitio donde una persona pueda revisarlo.

Aun así, sigue valiendo el consejo de Anthropic: empieza con el enfoque más simple posible y solo añade piezas cuando la tarea realmente las necesite.

De qué está hecho un agent harness

Las piezas varían, pero la mayoría comparten varios bloques básicos. Piensa en ellos como una lista de comprobación, no como una especificación cerrada. Un agente pequeño puede necesitar solo unos pocos; un agente en producción, bastantes más.

Prompts del sistema y reglas de comportamiento

El harness suele controlar las instrucciones base del modelo. Incluye el prompt del sistema, pero también puede incluir reglas del proyecto, estándares de código, límites de rol y políticas de seguridad. En Deep Agents de LangChain, por ejemplo, un archivo AGENTS.md puede fijar las reglas de juego antes de empezar una tarea.

Algunos harnesses en 2026 también usan divulgación progresiva de instrucciones. En lugar de cargar la descripción completa de cada herramienta desde el inicio, el harness añade solo un resumen de lo disponible. Las instrucciones completas de una herramienta se cargan solo cuando el modelo la necesita.

Herramientas: cómo interactúan los agentes con el mundo

Las herramientas permiten que el agente haga cosas más allá de generar texto. Ejemplos comunes: búsqueda web, lectura y escritura de archivos, consultas a bases de datos, llamadas a APIs, acciones en el navegador, ejecución de código y comandos de terminal. El harness controla qué herramientas hay disponibles, cuándo puede llamarlas el modelo y cómo se formatean y devuelven los resultados al contexto del agente.

Model Context Protocol (MCP) se ha convertido en 2026 en la interfaz estándar para esto. Muchos harnesses, incluido Anthropic Agent SDK, LangChain Deep Agents y OpenAI Agents SDK, usan MCP para conectar servidores de herramientas externos sin tener que escribir integraciones a medida para cada uno.

Memoria y estado

Los agentes necesitan saber qué ha pasado antes en una tarea. Un harness puede mantener estado a corto plazo en la conversación activa y estado a largo plazo en archivos, registros, resúmenes o preferencias guardadas. Algunos también compactan historiales largos en resúmenes más cortos para no cargar cada detalle en el contexto.

Entorno de ejecución: dónde corre y actúa el agente

Muchos agentes útiles necesitan un lugar real donde trabajar: un sistema de archivos, un contenedor, un terminal aislado, una instancia de navegador o un runtime en la nube. Sin un entorno de ejecución gestionado por el harness, las llamadas a herramientas no tienen dónde aterrizar.

Hoy muchos harnesses usan contenedores sandbox aislados: entornos efímeros vinculados a una sola sesión, que se limpian al terminar la tarea, para que las escrituras de archivos, paquetes instalados y llamadas de red de una tarea no contaminen otra.

Orquestación y planificación

Algunas tareas no encajan en una única línea recta de pasos. El harness puede ofrecer una herramienta de planificación que descompone un objetivo en subtareas y sigue su estado. También puede generar subagentes que se encargan de una parte del trabajo y devuelven solo un resumen al agente principal.

LangChain Deep Agents, por ejemplo, registra los pasos del plan en un archivo del sistema de archivos, actualizando cada paso de pendiente a completado a medida que avanza la tarea.

Guardarraíles y permisos

El harness es donde pones las reglas: aprobaciones humanas, bloqueo de ciertas llamadas, permisos basados en roles y validación de salidas. OpenAI Agents SDK, LangChain Deep Agents y Microsoft Agent Framework admiten este tipo de control. El patrón más seguro es comprobar por separado entradas, salidas y permisos de herramientas.

Observabilidad y trazabilidad

Cuando una tarea de cincuenta pasos falla en el treinta y siete, una traza muestra qué pasó. La trazabilidad registra llamadas al modelo, a herramientas, traspasos, errores, latencia y coste en toda la ejecución. OpenAI Agents SDK activa el tracing por defecto. LangSmith añade paneles de depuración y evaluación por encima. OpenTelemetry se ha convertido en el estándar para exportar trazas en un formato neutral, para que no quedes atado a una sola herramienta de observabilidad.

Agent harness vs. framework vs. runtime: ¿en qué se diferencian?

Esta pregunta aparece a menudo y la respuesta es más enrevesada de lo que sugieren muchos artículos. La taxonomía es útil, pero no es fija.

Tres capas, mayor abstracción de abajo arriba. Imagen del autor.

Empiezo por el framework, porque muchos desarrolladores ya han usado alguno.

¿Qué es un framework de agentes?

Un framework de agentes ofrece a los desarrolladores bloques para crear agentes. Cubre llamadas al modelo, definición de herramientas, patrones de memoria y la estructura del bucle del agente. Ejemplos: el LangChain inicial, CrewAI y Google ADK. Un framework te dice cómo estructurar un agente, pero no siempre cómo ejecutarlo de forma fiable en producción.

¿Qué es un runtime de agentes?

Un runtime de agentes es la capa que ayuda a que un agente se ejecute de forma fiable en el tiempo. Gestiona ejecución duradera, persistencia de estado, reintentos, pasos con intervención humana y streaming. LangGraph, Temporal e Inngest son ejemplos. Harrison Chase propuso esta analogía: si Node.js es el runtime y Express es el framework, un harness sería como Next.js.

¿Qué diferencia a un harness?

Un harness está a un nivel más alto que un framework. Mientras un framework te da componentes, un harness suele llegar con más decisiones ya tomadas: herramientas, planificación, acceso al sistema de archivos y gestión del contexto.

Casos de uso de agent harness: código, investigación, datos y empresa

Los mismos bloques aparecen en trabajos muy distintos, pero cambia la mezcla. Un agente de código y un agente de flujos empresariales necesitan un harness, pero presionan distintas partes. Estas categorías no son estándares formales, sino formas prácticas de ver cómo la idea se adapta al trabajo real.

Harnesses para agentes de código

Los agentes de programación son un buen ejemplo porque el harness se hace visible. Para hacer trabajo útil, un agente necesita acceso a archivos, contexto de git, ejecución en terminal, ejecución de tests, instalación de dependencias y reglas del proyecto. Claude Code y Codex siguen este patrón: ambos se apoyan mucho en código de harness, no en una API de modelo desnuda.

La diferencia entre un buen harness de código y uno mediocre suele aparecer en los detalles: cómo se recupera de un test fallido, si puede deshacer una mala edición, o cómo expone el historial de git al modelo. Ahí es donde se va la mayor parte del esfuerzo de ingeniería.

Harnesses para agentes de investigación

Los agentes de investigación necesitan otro conjunto de herramientas: búsqueda web, trazado de fuentes, toma de notas, gestión de citas y resúmenes. El harness gestiona cómo se guardan los resultados de búsqueda, cómo se atribuyen las fuentes y cómo se trocean y descargan documentos largos para no consumir toda la ventana de contexto de una vez.

Harnesses para agentes de análisis de datos

Los agentes de datos necesitan acceso a conjuntos de datos, bases de datos SQL, entornos de ejecución de Python y contexto de esquemas para saber qué tablas y columnas hay antes de escribir consultas. El harness también impone límites de permisos, cruciales cuando el agente puede tocar datos de producción.

Harnesses para flujos empresariales

Los despliegues empresariales añaden otra capa: autenticación, logs de auditoría, flujos de aprobación, control de acceso basado en roles y conexiones con sistemas internos. AWS AgentCore es un ejemplo gestionado en esta categoría, con identidad, redes VPC y observabilidad incluidas. Microsoft Agent Framework cubre un terreno similar para equipos en Azure o entornos .NET.

Herramientas para crear agent harness en 2026

A mediados de 2026 un puñado de productos aparecen con más frecuencia. Se sitúan en distintos puntos del espectro framework-runtime-harness, y los límites siguen moviéndose.

LangChain Deep Agents

LangChain Deep Agents es el harness de código abierto de LangChain, construido sobre LangGraph como runtime. Incluye herramienta de planificación, sistema de archivos virtual, generación de subagentes, compactación automática de contexto y middleware para aprobación con humano en el bucle y detección de PII. Es agnóstico al modelo, admite endpoints compatibles con OpenAI y se conecta a proveedores de sandbox como Modal, Runloop y Daytona para la ejecución de código.

Anthropic Agent SDK

El Anthropic Agent SDK (nombre del paquete: claude-agent-sdk) se extrajo de Claude Code y se lanzó como opción independiente. Incluye un bucle de agente integrado, herramientas para ejecutar bash, leer y escribir archivos, buscar en la web, integración MCP y compactación de contexto. Funciona solo con modelos Claude, a través de la API de Anthropic, Amazon Bedrock, Vertex AI y Azure.

OpenAI Agents SDK

Como comenté antes, OpenAI Agents SDK pasó de framework a terreno de harness a medida que crecía su set de funciones. La versión de abril de 2026 añadió ejecución en sandbox nativa, compactación de memoria y herramientas de sistema de archivos. Disponible en Python y TypeScript, el SDK admite uso de herramientas, handoffs entre agentes y guardarraíles.

Google Agent Development Kit

Google ADK admite orquestación multiagente con clases integradas para estructuras secuenciales, paralelas y en bucle. Incluye herramientas de evaluación, funciona con Vertex AI para despliegue gestionado y soporta MCP para conectar herramientas. Disponible en Python, Java, TypeScript y Go, está afinado para modelos Gemini pero se describe como agnóstico al modelo.

Microsoft Agent Framework

Microsoft Agent Framework es la ruta actual de migración de Microsoft para proyectos de AutoGen. Soporta Python y .NET, funciona con servicios de Azure AI e incluye soporte MCP para conectar herramientas.

CrewAI

CrewAI adopta un enfoque basado en roles para sistemas multiagente. Defines agentes con roles específicos, asignas tareas, creas equipos y configuras memoria y guardarraíles de forma declarativa. Encaja bien cuando el problema se parece a un equipo de especialistas.

Temporal e Inngest

Por sí solas no son agent harnesses. Son plataformas de ejecución duradera que gestionan qué ocurre cuando una tarea de agente necesita correr horas o días sin perder el estado. Si falla, el motor reejecuta desde el último checkpoint correcto en lugar de empezar de cero.

Retos y compromisos al usar un agent harness

Añadir un harness amplía lo que el sistema puede hacer, pero cada herramienta, permiso y agente extra es otra vía de fallo. A medida que las tareas se alargan, los guardarraíles, el tracing y el estado duradero dejan de ser opcionales y pasan a ser lo que mantiene recuperables las ejecuciones largas.

También existe un riesgo de acoplamiento que sorprende a muchos equipos. LangChain informó de un salto de 10 a 20 puntos en un subconjunto de tau2-bench tras añadir perfiles de harness específicos por modelo. Artificial Analysis señaló algo similar en su Coding Agent Index: los resultados dependen del modelo y del harness a la vez, con cambios notables en coste, tokens y tiempo por tarea según la combinación. El modelo no cambió. Sí lo hicieron los prompts, las herramientas y el middleware que lo rodean. Ese perfil en sí es trabajo de harness.

¿De verdad necesitas un agent harness?

Aquí tienes una forma directa de evaluar si lo necesitas.

Probablemente lo necesites si tu sistema cumple una o más de estas condiciones:

• Necesita usar herramientas externas
• Necesita recordar el progreso entre sesiones
• Necesita ejecutar código en un entorno real
• Coordina más de un agente
• Debe recuperarse de fallos parciales sin perder trabajo
• Requiere aprobación humana

Probablemente no lo necesites si la tarea es un flujo predecible con pasos totalmente determinados.

Una buena prueba: si la tarea se resuelve con una sola llamada al modelo o con un pequeño script determinista con unas pocas condiciones, un harness seguramente es excesivo. En cuanto la tarea exige que el agente tome decisiones, use herramientas y reaccione a resultados a lo largo del tiempo, el harness empieza a aportar valor real.

Un patrón que veo a menudo es equipos que recurren a un harness demasiado pronto, construyendo trazabilidad y sandboxing para lo que en realidad es una tarea de generación de texto de un solo tiro. El error contrario duele más: exponer el modelo directamente y descubrir, en el segundo test fallido, la tercera llamada a herramienta o el quinto reinicio, que no hay infraestructura a la que recurrir.

Reflexiones finales

Como decía antes, los proveedores no usan siempre las mismas palabras para las mismas cosas, y la frontera entre framework, runtime y agent harness sigue moviéndose.

Para una generación de un solo paso, el envoltorio es excesivo. Para agentes que deben actuar, recordar y recuperarse en sesiones largas, el agent harness se convierte en una parte clave del sistema. Elegir el adecuado es cada vez una decisión separada de elegir el modelo. Tengo curiosidad por ver cuánto de esta capa absorberá la próxima generación de modelos, porque algunos movimientos de OpenAI y Anthropic sugieren que la frontera seguirá cambiando. La idea esencial sigue en pie: un agente es un modelo más un agent harness.

Si quieres aprender más sobre cómo construir sistemas de agentes, nuestro curso Building Scalable Agentic Systems cubre los patrones detrás del uso de herramientas, la orquestación y los flujos de trabajo de agentes de larga duración.