El harness del agente: lo que separa una demo de un sistema en producción
El harness es todo lo que se monta alrededor del modelo para que un agente aguante en producción. La pregunta útil no es qué lleva dentro, sino quién lo opera y a quién despiertan cuando se rompe.
Un agente que funciona en producción no es un modelo. Es un modelo más todo lo que se le monta encima: memoria entre sesiones, acceso a herramientas y MCP, recuperación de contexto, enrutado entre modelos, barreras de seguridad, control de costes y las trazas que alguien consulta a las tres de la mañana cuando el agente empieza a responder cosas raras. Esa capa tiene nombre desde hace poco —harness— y es la que decide si lo que tienes es una demo de una tarde o algo que aguanta usuarios reales.
El término se ha popularizado este año, pero el trabajo detrás no es nuevo: quien montaba agentes el año pasado ya estaba pegando herramientas, ajustando prompts a mano y añadiendo reintentos y logs. Lo nuevo es tratarlo como una pieza que se diseña a propósito en lugar de como un cajón de parches. Vivek Trivedy lo resume en The Anatomy of an Agent Harness: "An agent is a model plus a harness". O dicho de otro modo, si no eres el modelo, eres el harness.
Las dos mitades
El harness se parte en dos bloques que conviene no mezclar. El de desarrollo amplía el alcance del modelo: memoria persistente, herramientas y MCP, recuperación, prompts y orquestación. El de operaciones mantiene todo eso en pie cuando llega tráfico de verdad: observabilidad, evaluación, barreras de seguridad, enrutado, vigilancia de deriva y de coste, despliegue y escalado.
La segunda mitad es DevOps con otro sombrero. Si vienes de operar servicios, casi todo te sonará: presupuestos, alertas, canales de guardia, versionado de configuración. La diferencia es que ahora el componente que se degrada no es un pool de conexiones, sino un modelo que responde distinto sin que nadie haya tocado nada.
Conviene no sacar la conclusión equivocada de que el modelo da igual. El modelo hace el trabajo cognitivo difícil y uno mejor empuja todo lo que tiene encima. El punto es otro: un agente no es un modelo, es un producto, y envolver un modelo en un endpoint no te da un producto.
Quién lo opera
Hay dos rutas y ambas contienen las mismas piezas: acceso a modelos, recuperación, herramientas, enrutado, barreras. Lo que cambia es el empaquetado y quién asume la guardia.
Por un lado está el harness como servicio, con ejemplos como AWS AgentCore, Google Vertex AI Agent Engine, Azure AI Foundry Agent Service o LangGraph Platform. Configuras APIs gestionadas y pagas factura de proveedor. Tú sigues siendo dueño de las políticas, los presupuestos, los prompts, las herramientas y las evaluaciones.
Por otro, la pila autogestionada: LangChain o LlamaIndex, más Agent Router —antes Envoy AI Gateway— o LiteLLM, todo sobre Kubernetes. Aquí conservas lo mismo y además el despliegue, las actualizaciones y el on-call. Ganas portabilidad, pagas en tiempo de ingeniería e infraestructura.
El criterio de decisión no es qué capacidades recibes, porque son equivalentes. Es cuánto control quieres conservar frente a cuánta velocidad necesitas, y si prefieres cambiar esfuerzo por portabilidad. Dicho de forma más directa: no cambian las piezas, cambia quién las ensambla y a quién le suena el teléfono cuando se rompen.
La recomendación que se repite en el análisis es empezar con lo mínimo y dejar que el harness crezca con el agente. Sobredimensionarlo antes de tener usuarios es trabajo que nadie te va a agradecer. El valor está en que el trabajo se haga, no en la maquinaria que montaste por si acaso.
