Agent Harnesses: la infraestructura detras de agentes de IA fiables

Muchas demos de agentes de IA se parecen al principio: conectar un buen modelo, agregar algunas herramientas, escribir un prompt decente y dejar que el sistema trabaje una tarea. Eso puede alcanzar para una demo. No alcanza para produccion. Los agentes de produccion necesitan recordar contexto relevante, usar herramientas con seguridad, recuperarse de fallos, respetar permisos, verificar su propio trabajo y seguir operando cuando una tarea dura mas que una respuesta limpia del modelo. El modelo importa, pero el sistema alrededor del modelo decide si el agente resulta util todos los dias. Ese sistema suele llamarse agent harness, runtime de agente, capa de orquestacion, entorno de ejecucion o scaffolding del agente. En este articulo usamos "agent harness" para referirnos al runtime y a la capa de orquestacion alrededor del modelo. Algunos equipos llaman a la misma capa agent framework, orchestration layer, execution runtime o agent scaffolding.

Que es un agent harness

Un agent harness es la infraestructura de software que convierte un modelo de lenguaje sin estado en un agente funcional. El modelo predice, planifica y realiza inferencia similar al razonamiento. El harness le da un entorno controlado donde puede actuar. Un harness de produccion suele incluir:

bucles de orquestacion
registro y ejecucion de herramientas
gestion de contexto
memoria de corto y largo plazo
persistencia de estado
controles de permisos
ejecucion en sandbox
reintentos y manejo de errores
bucles de verificacion
trazas y observabilidad
enrutamiento de modelos
delegacion a subagentes

Sin esta capa, un agente de IA normalmente queda mas cerca de una interfaz tipo chat o de un asistente de un solo paso. Con esta capa, puede convertirse en un motor de flujos de trabajo. Por ejemplo, un usuario puede pedir a un agente que arregle un bug en checkout. Un modelo puede sugerir donde mirar. Un harness permite que el agente inspeccione el repositorio, busque archivos, edite codigo, ejecute tests, lea errores, repare el parche, revise el diff y se detenga solo despues de verificar el resultado. Esa diferencia es el producto.

Por que el harness importa cada vez mas

Los equipos de IA estan aprendiendo que dos productos que usan el mismo modelo pueden dar resultados muy distintos. La razon es la infraestructura. Los modelos frontier estan mejorando rapido. A medida que capacidades como tool use, structured output, long context, code generation e inferencia similar al razonamiento aparecen en mas proveedores, mas ventaja de producto se mueve al entorno alrededor del modelo. El trabajo del harness tambien se acumula. Cada fallo puede convertirse en una mejora permanente del sistema:

Si un agente llama herramientas con argumentos malos, se endurecen esquemas y validacion.
Si pierde decisiones anteriores, se mejora contexto y memoria.
Si hace cambios riesgosos, se agregan puertas de permisos.
Si declara una tarea terminada demasiado pronto, se agrega verificacion.
Si repite llamadas caras, se mejora cache o routing.
Si empeora con contexto largo, se agregan compaction y retrieval.

Los arreglos de prompt ayudan, pero no alcanzan. El comportamiento duradero sale del diseno del runtime.

Prompt engineering, context engineering y harness engineering

Estos terminos estan relacionados, pero no son lo mismo. Prompt engineering es la capa de instrucciones. Le dice al modelo que rol seguir, que restricciones importan y como responder. Context engineering es la capa de informacion. Decide que ve el modelo, cuando lo ve y cuanto de eso pertenece a la ventana actual. Harness engineering es la capa completa de ejecucion. Incluye prompts y contexto, pero tambien herramientas, estado, seguridad, memoria, verificacion, colas, observabilidad y gestion del ciclo de vida. Esta distincion importa porque los prompts piden comportamiento, mientras que los harnesses lo hacen cumplir. Un prompt puede decir: "No borres archivos sin permiso". Un harness puede bloquear comandos destructivos hasta que el usuario los apruebe. Un prompt puede decir: "Revisa tu trabajo". Un harness puede ejecutar la suite de tests, inspeccionar la salida e impedir la finalizacion cuando la verificacion falla.

Como funciona un agent harness

La mayoria de los agent harnesses siguen un bucle. Primero, el harness arma la entrada del modelo. Esa entrada puede incluir prompt del sistema, instrucciones del desarrollador, solicitud del usuario, definiciones de herramientas, memoria, estado actual de la tarea y contexto seleccionado desde archivos o bases de datos. Despues, el modelo responde. Puede devolver texto, datos estructurados, tool calls o una solicitud para delegar trabajo a otro agente. Luego el harness clasifica la salida. Si el modelo produjo una respuesta final, el bucle puede detenerse. Si pidio una herramienta, el harness valida la llamada. La validacion es critica. El harness comprueba si los argumentos coinciden con el esquema, si la herramienta esta disponible, si la accion es segura y si el usuario o el sistema concedieron permiso. Despues corre la herramienta. Puede leer archivos, consultar una base de datos, buscar documentos, llamar una API, ejecutar codigo, abrir un navegador o escribir un parche. El resultado vuelve al modelo como una observacion. Si la herramienta falla, el error debe empaquetarse con suficiente claridad para que el modelo pueda recuperarse. El bucle continua hasta que el agente llega a un punto de cierre verificado, alcanza un limite de presupuesto, pide entrada humana o es interrumpido. Suena simple. La calidad de produccion vive en cada detalle alrededor de ese bucle.

Partes centrales de un harness de produccion

1. Bucle de orquestacion

El bucle de orquestacion controla los turnos del agente. Patrones comunes:

ReAct: razonar, actuar, observar, repetir
plan and execute: crear plan y luego recorrerlo
generate, test, repair: producir salida, verificarla y corregir fallos
gather, act, verify: reunir contexto, actuar y comprobar resultado

El bucle puede ser tecnicamente pequeno. La parte dificil es decidir que contexto entra en cada turno, que acciones estan permitidas, que significan los errores y cuando la tarea esta realmente terminada.

2. Capa de herramientas

Las herramientas son la forma en que el agente toca el mundo. Las buenas herramientas se disenan para modelos, no solo para humanos. Un humano puede interpretar salida ruidosa de CLI, defaults ocultos, flags ambiguos y fallos parciales. Un agente necesita limites mas claros. La capa de herramientas deberia manejar:

nombres y descripciones
esquemas de argumentos
controles de permisos
sandboxing
ejecucion
formateo de salida
reintentos
logs de auditoria

El diseno de herramientas suele decidir la calidad del agente. Demasiadas herramientas confunden al modelo. Herramientas con parametros vagos producen llamadas poco fiables. Herramientas con permisos amplios crean riesgo. Los harnesses fuertes exponen el conjunto minimo de herramientas utiles para la tarea actual.

3. Gestion de contexto

El contexto no es almacenamiento. Es una superficie de trabajo escasa. Las ventanas de contexto grandes ayudan, pero no eliminan la necesidad de seleccionar. Cuando logs irrelevantes, salidas viejas, planes antiguos y contenido repetido llenan la ventana, el modelo se vuelve menos fiable. Los harnesses de produccion usan estrategias como:

cargar primero indices pequenos
recuperar archivos o registros exactos bajo demanda
resumir turnos anteriores
ocultar salidas viejas de herramientas
conservar decisiones y problemas abiertos mientras se elimina ruido
delegar exploracion a subagentes que devuelven resumenes compactos

El objetivo no es el maximo contexto. El objetivo es el contexto mas pequeno y de mayor senal que ayude al modelo a hacer bien el siguiente paso.

4. Memoria

La memoria permite que un agente arrastre informacion util entre turnos y sesiones. La memoria de corto plazo cubre la tarea activa. La memoria de largo plazo guarda hechos duraderos, preferencias, reglas del proyecto y decisiones recurrentes. La memoria de trabajo puede incluir archivos de progreso, listas de tareas o blocs de notas estructurados. La memoria no debe tratarse como verdad. Debe tratarse como una pista. Si la memoria dice que un proyecto usa cierto framework, el agente igual deberia inspeccionar el proyecto antes de hacer cambios especificos del framework. Eso evita que memoria vieja se convierta en certeza alucinada. La memoria tambien necesita aislamiento y revision porque hechos malos o maliciosos guardados pueden influir en ejecuciones futuras. Un sistema de produccion debe evitar fugas de memoria entre usuarios, equipos, tenants o fronteras de permisos.

5. Persistencia de estado

Las tareas de produccion a menudo sobreviven a una sola respuesta del modelo. El harness deberia rastrear:

ID de sesion
ID de ejecucion
estado actual
tool calls pendientes
archivos tocados
agentes hijos
aprobaciones concedidas
coste y uso de tokens
resultado final
estado de entrega

El estado permite reanudar una tarea despues de una interrupcion. Tambien da auditabilidad: que paso, cuando, por que y a traves de que herramienta.

6. Manejo de errores

Los errores son esperables en flujos de trabajo con agentes. Un harness fuerte separa tipos de errores:

errores transitorios deberian reintentarse con backoff
errores de argumentos deberian devolver feedback claro al modelo
errores de permisos deberian pedir aprobacion o elegir una ruta segura
errores inesperados deberian detenerse con diagnosticos utiles

Esto importa porque las tareas de muchos pasos acumulan fallos. Incluso una alta tasa de exito por paso puede volverse debil en una secuencia larga. La logica de recuperacion no es opcional.

7. Guardrails y permisos

El modelo puede decidir lo que quiere hacer. El harness debe decidir lo que se le permite hacer. Limites de permisos utiles:

acceso de solo lectura frente a escritura
alcance del workspace
aprobacion para comandos destructivos
aprobacion para mutaciones de base de datos
limites para APIs externas
restricciones de acceso a credenciales
revision humana antes de una accion orientada al usuario

Esta capa debe aplicarse con codigo, no solo describirse en un prompt. Para acciones de alto riesgo, la aprobacion debe ocurrir antes de que la herramienta se ejecute, no despues.

8. Bucles de verificacion

La verificacion es donde los agentes se vuelven fiables. Para tareas de software, la verificacion puede incluir tests, type checks, linters, builds, screenshots, browser checks y revision de diff. Para flujos de negocio, la verificacion puede incluir validacion de esquemas, restricciones de base de datos, revision humana, umbrales de confianza, citas de documentos e inspeccion de trazas. Parte de la verificacion es determinista. Otra parte usa otro modelo como juez. Las comprobaciones deterministas deberian preferirse cuando sea posible porque ofrecen una verdad de referencia mas clara.

9. Observabilidad

Los equipos necesitan ver como se comportan los agentes. Un harness de produccion deberia trazar:

prompts y salidas del modelo
tool calls
resultados de herramientas
errores
reintentos
aprobaciones
uso de tokens
latencia
resultados de verificacion
resultados finales

Sin observabilidad, los equipos no pueden mejorar el sistema. Solo pueden adivinar por que fallo.

Subagentes y gestion del ciclo de vida multiagente

Una vez que un agente puede crear otros agentes, el problema cambia. Los subagentes son utiles cuando el trabajo puede dividirse. Un agente puede inspeccionar documentacion mientras otro revisa codigo. Uno puede probar la UI mientras otro parchea la logica de backend. Uno puede investigar fuentes mientras otro escribe el borrador. Pero crear subagentes no es lo mismo que gestionarlos. La gestion del ciclo de vida multiagente empieza cuando el runtime posee muchos agentes en ejecucion a lo largo del tiempo. Un sistema multiagente serio necesita:

IDs duraderos para agentes hijos
linaje padre-hijo
IDs de ejecucion
roles y limites de profundidad
colas
cancelacion
redireccion de trabajo
eventos de finalizacion
politicas de limpieza
recuperacion despues de reinicios

La pregunta clave pasa a ser: donde vive el agente hijo, quien lo posee, como reporta de vuelta y que ocurre si el padre ya siguio con otra cosa. La delegacion simple devuelve un resumen al padre. La gestion del ciclo de vida multiagente trata la finalizacion como un problema de enrutamiento. Un hijo puede terminar mientras el padre esta activo, inactivo, reiniciado o ausente. El runtime tiene que entregar ese resultado al lugar correcto con su procedencia intacta. Por eso los sistemas avanzados de agentes empiezan a parecerse a gestores de procesos. Necesitan identidad, ciclo de vida, colas, recuperacion y limpieza.

Agentes gestionados frente a harnesses personalizados

Las plataformas de agentes gestionados son cada vez mas comunes. Empaquetan el harness y la infraestructura de produccion para que los equipos avancen mas rapido. Esto puede ser valioso cuando un equipo quiere:

lanzar mas rapido
runtime alojado
escalado incorporado
ejecucion gestionada de herramientas
observabilidad estandar
menos responsabilidad de infraestructura

Pero los agentes gestionados tambien son una decision de arquitectura. Los equipos pueden seguir necesitando un harness personalizado cuando:

la calidad del flujo de trabajo es valor central del producto
las herramientas del dominio son muy especificas
permisos y auditoria son estrictos
importa el coste por tarea
agentes de larga duracion necesitan reglas de ciclo de vida propias
el lock-in de proveedor preocupa
el comportamiento del agente base rinde mal en evals internas

Para muchos equipos, la ruta practica no es "construirlo todo" o "usar solo runtime gestionado". Es por etapas. Empieza con herramientas existentes. Construye evals. Encuentra patrones de fallo. Personaliza el harness donde los fallos repetidos o la economia lo justifiquen.

Cuando tu equipo deberia prestarle atencion

Deberias pensar en serio en el diseno del harness cuando un flujo de IA deja de ser un prototipo. Senales claras:

los usuarios dependen de la salida
los errores generan coste operativo
el flujo toca datos privados o regulados
el agente necesita herramientas con efectos laterales
la tarea lleva muchos pasos
la salida necesita verificacion
la revision humana necesita auditoria
el coste en tokens empieza a notarse
el comportamiento del agente cambia de forma impredecible entre ejecuciones

En ese punto, el modelo es solo una parte del sistema. La fiabilidad viene del harness.

Como lo abordamos en Lunover

En Lunover tratamos a los agentes de IA como sistemas de software de produccion, no como experimentos de prompts. Eso significa que empezamos por el valor del flujo de trabajo. Mapeamos el proceso real, las fuentes de datos, los riesgos, los usuarios y los criterios de exito antes de construir. Luego elegimos el nivel correcto de complejidad del harness para el trabajo. Para un asistente interno simple, eso puede significar retrieval, tool use y monitorizacion basica. Para un flujo orientado al cliente, puede requerir permisos mas estrictos, evals, fallbacks, revision de trazas y aprobacion humana. Para automatizacion de larga duracion, puede necesitar estado durable, job queues, recuperacion y propiedad clara de cada accion que toma el agente. La meta no es que el agente se vea impresionante en una demo. La meta es que el sistema sea util despues del lanzamiento. Si tu equipo esta explorando agentes, copilots, RAG o automatizacion de flujos, conviene empezar pronto con la pregunta del harness: Que necesita ver el modelo? Que puede hacer? Que no deberia hacer nunca? Como sabemos que la salida es correcta? Que pasa cuando algo falla? Quien revisa las acciones de alto riesgo? Que datos sobreviven despues de la ejecucion? Estas preguntas determinan si una funcionalidad de IA se convierte en un flujo fiable o en una interfaz fragil.

La idea principal

La siguiente ola de productos de IA no se ganara solo por eleccion de modelo. Los modelos aportan inteligencia. Los harnesses aportan comportamiento operativo. El harness decide si un agente puede usar herramientas con seguridad, gestionar contexto, recuperarse de errores, verificar trabajo, respetar permisos y seguir mejorando con el tiempo. Para equipos que construyen sistemas de IA reales, ahi vive ya una gran parte del trabajo de ingenieria. Si tu equipo esta construyendo agentes de IA, copilots, sistemas RAG o automatizacion de flujos, Lunover puede ayudar a traves de Desarrollo de IA, Aplicaciones web y Sistemas empresariales, con foco en la capa de produccion alrededor de tu modelo: herramientas, memoria, permisos, verificacion, observabilidad y despliegue.