Modelo vs. harness: el término que por fin le pone nombre a la gobernanza de agentes de IA

Dos productos pueden correr exactamente el mismo modelo y comportarse de forma completamente distinta. El mismo modelo puede ser un chatbot básico de ida y vuelta en una interfaz, y en otra puede trabajar horas seguidas sobre una tarea de software con acceso a archivos y terminal. Esa diferencia no vive en el modelo, vive en lo que lo rodea. La industria ya le puso nombre a eso: agentic harness.

Llevamos dos artículos de esta serie hablando de niveles de autonomía, tool calling con esquema cerrado, idempotencia y trazas de auditoría, sin usar esta palabra ni una sola vez. Resulta que ya estábamos describiendo un harness. Solo nos faltaba el término.

¿Qué es un agentic harness, exactamente?

Es el software que envuelve a un modelo de IA y le da la capacidad de interactuar con herramientas externas, recordar interacciones pasadas y ejecutar tareas de varios pasos. Un modelo de lenguaje, por sí solo, solo genera texto: no puede abrir un archivo, ejecutar código ni navegar la web de forma nativa. El harness es la infraestructura que convierte esa generación de texto en acción real dentro de un sistema, según lo define Google Cloud en su documentación técnica sobre el tema.

Dicho de otra forma: si el modelo es el cerebro, el harness es todo lo que le permite tener manos.

¿Por qué dos productos con el mismo modelo se comportan tan distinto?

Porque los saltos de capacidad que hemos visto últimamente vienen sobre todo del harness, no solo del modelo. IBM lo plantea con un dato incómodo en su análisis sobre el tema: la brecha de rendimiento entre los laboratorios líderes se ha reducido a apenas unos puntos en la mayoría de los benchmarks. Así que cuando un producto de IA supera claramente a otro, normalmente no es "el cerebro" lo que explica la diferencia. Es lo que lo envuelve.

Un mismo modelo puede ser brillante dentro de un harness y quedarse atascado dentro de otro.

¿De qué está hecho un harness?

De tres piezas que trabajan juntas: herramientas, memoria y el ciclo agéntico.

• Herramientas. Es lo que le da al modelo acceso al mundo: leer y escribir archivos, ejecutar código en un sandbox, buscar información, e incluso operar una pantalla mediante computer use. Para conectarse a sistemas externos que no viven en la misma máquina, el estándar que se está consolidando es MCP (Model Context Protocol): una herramienta construida para MCP se conecta a cualquier harness compatible sin tener que reconstruirse cada vez.
• Memoria. Un modelo tiene una ventana de contexto fija, su memoria de trabajo, que se borra al terminar la conversación. El harness es lo que persiste lo que importa: archivos de instrucciones que se cargan al inicio de cada sesión (para que el modelo sepa las convenciones del proyecto), compactación del contexto cuando empieza a llenarse, y búsqueda selectiva en lugar de volcar todo el proyecto de una vez.
• El ciclo agéntico. Es donde el modelo y el harness trabajan juntos: el modelo decide el siguiente paso, el harness ejecuta esa acción, el modelo observa el resultado, y el ciclo se repite, a veces por segundos, a veces por horas. Los harnesses más maduros corren verificación continua durante todo el ciclo: pruebas automáticas, capturas de pantalla del resultado, y en algunos casos un segundo modelo actuando como revisor. Un sistema que se autoverifica tiende a mantenerse en carril mucho más tiempo que uno que no lo hace.

Un artículo académico reciente que formaliza esta distinción lo resume con una ecuación simple:

Agente = Modelo + Harness

El harness, no el modelo, es lo que determina qué puede percibir el agente, cómo actúa, y cómo se verifica y coordina su trabajo.

¿Es "agentic harness" un término real, o solo la palabra de moda de esta semana?

Es real, y no hace falta confiar en ningún analista para comprobarlo: basta con mirar cómo lo usan, en su propia documentación técnica, los tres laboratorios que dominan la conversación sobre agentes:

• La documentación oficial del SDK de Claude Code, de Anthropic, describe el SDK como construido "sobre el harness de agente que impulsa Claude Code", que es, literalmente, el nombre que le dan a su propia infraestructura de producción.
• LangChain lo convirtió en la ecuación central de su documentación de agentes: Agent = Model + Harness. Según explican, el trabajo del harness es darle al modelo el contexto correcto en el momento correcto para la tarea que tiene por delante.
• El equipo de Codex, de OpenAI, usa "agente" y "harness" de forma prácticamente intercambiable para referirse a toda la infraestructura que no es el modelo.

No es una idea completamente nueva: desarrolladores llevan años construyendo wrappers y entornos de ejecución alrededor de modelos. Lo que sí es nuevo es que tres competidores directos hayan convergido en el mismo vocabulario técnico para describir la misma capa de su arquitectura, sin necesidad de coordinarse entre sí. Esa es una señal bastante más sólida de que el concepto es real que cualquier ranking de tendencias.

¿Cómo conecta esto con la gobernanza de agentes que ya cubrimos en esta serie?

Aquí es donde esta pieza deja de ser una definición y se vuelve útil de verdad: todo lo que hemos venido construyendo en las dos primeras partes de esta serie vive, físicamente, dentro del harness.

• Los niveles de autonomía L0–L5 que definimos en la primera parte no son una propiedad del modelo: son reglas que el harness aplica antes de dejar pasar una acción.
• El esquema cerrado de tool calling de la segunda parte es, literalmente, la capa de herramientas del harness.
• La idempotencia, la separación de estado de negocio/ejecución/memoria y la traza estructurada de auditoría son, todas, responsabilidades del harness, no del modelo subyacente.

Esto tiene una consecuencia práctica importante: cambiar de modelo no debería significar rediseñar tu gobernanza desde cero. Si tu autoridad de ejecución, tus guardrails y tu auditoría están bien construidos en el harness, puedes cambiar el modelo que razona por debajo (de una versión a otra, incluso de un proveedor a otro) sin tocar una sola regla de negocio. Esa separación es, quizás, el argumento más fuerte a favor de tratar el harness como una disciplina de ingeniería propia, no como un detalle de implementación alrededor del modelo.

¿La línea entre modelo y harness es fija?

No, y es un matiz que vale la pena tener claro antes de asumir que esta distinción es permanente. Hay capacidades que antes vivían enteramente en el harness (planificación a largo plazo, autoverificación) que se están empezando a entrenar directamente dentro de los modelos más nuevos. Y al mismo tiempo, comportamientos que antes se atribuían al modelo, como la consistencia a lo largo de una tarea larga, cada vez dependen más de las convenciones del harness y de los archivos de proyecto que lo alimentan.

Es decir: la frontera se mueve. Pero mientras se mueve, la disciplina de diseñar bien esa frontera (qué vive en el modelo, qué vive en el harness, y quién tiene autoridad para qué) sigue siendo el trabajo real.

Preguntas frecuentes

¿Qué es un agentic harness?

Es el software que envuelve a un modelo de IA y le da acceso a herramientas, memoria persistente y un ciclo de ejecución de varios pasos, convirtiendo un modelo que solo genera texto en un sistema capaz de actuar sobre archivos, código y servicios externos.

¿Cuál es la diferencia entre un modelo de IA y un agente de IA?

El modelo es la red neuronal que razona y genera texto. El agente es el modelo más el harness que lo envuelve: las herramientas que puede usar, cómo recuerda información entre pasos, y el ciclo que decide, ejecuta y verifica cada acción.

¿Por qué importa más el harness que el modelo en muchos casos?

Porque las brechas de rendimiento entre los modelos líderes se han reducido considerablemente, mientras que la diferencia entre un buen harness y uno mal diseñado sigue siendo enorme. El mismo modelo puede rendir de forma completamente distinta según el entorno de ejecución que lo rodea.

¿Qué es MCP (Model Context Protocol) y qué tiene que ver con el harness?

Es un estándar abierto que define cómo un harness se conecta a fuentes de datos y herramientas externas de forma normalizada. En la práctica, permite construir una herramienta una sola vez y conectarla a cualquier harness compatible, sin tener que reconstruirla para cada framework o producto distinto.

¿Si cambio de modelo tengo que rediseñar la gobernanza de mi agente?

No debería, si la gobernanza (niveles de autonomía, validación de herramientas, idempotencia, auditoría) está bien construida en el harness y no depende del modelo específico. Esa separación es una de las razones por las que vale la pena tratar el diseño del harness como su propia disciplina de ingeniería.

Esta es la tercera parte de la serie sobre arquitectura de sistemas agénticos. Las dos anteriores, autonomía frente a autoridad de ejecución y tool calling, idempotencia y observabilidad, cubren, sin saberlo todavía, dos de las piezas centrales de un harness bien diseñado. Juntas, con nuestra guía sobre desarrollo agéntico en equipos de software, forman una línea completa sobre cómo construir sistemas de IA que funcionan más allá de la demo.

Fuentes técnicas

• AI Model vs Agentic Harness: What Actually Drives AI, IBM Technology (YouTube): youtube.com
• What is an agent harness?, Google Cloud: cloud.google.com
• The Last Harness You'll Ever Build, Seong et al., Sylph.AI (arXiv:2604.21003, 2026): arxiv.org
• Claude Code SDK, Anthropic: docs.claude.com
• Agents, LangChain Docs: docs.langchain.com