¿Qué es el arnés en la inteligencia artificial?

Hace poco vi que se referían a OpenClaw como un arnés. Pensé: "Eso es interesante". OpenClaw no es un arnés. Es un tiempo de ejecución del agente: el motor que impulsa su ciclo. Entonces, ¿qué significa realmente la palabra "arnés"?

La conversación hasta ahora

La base estructural del concepto proviene del artículo de Birgitta Böckeler de abril de 2026. En él, define con elegancia un agente como: model + harness = agent. Ella dividió la stack en un arnés de construcción (el tiempo de ejecución interno incluido en la herramienta) y un arnés de usuario (el contexto personalizado del desarrollador). Esta definición se basó en una ola de debates de febrero de 2026, que incluyó el enfoque pragmático de Mitchell Hashimoto para los contextos de ingeniería AGENTS.md,la descripción general de OpenAI sobre la ingeniería de arneses internos para la implementación automatizada y el memorándum de resumen original de Böckeler.

5 capas, de afuera hacia adentro

Creo que un agente es algo más que el modelo y el arnés. Para mí, esto comienza con la observación de que simplemente no podemos confiar en el tiempo de ejecución del agente. Para tener seguridad sobre la cadena de suministro de software del código de una fábrica de agentes, necesitamos una capa de entorno de pruebas (sandbox) distinta. Esta servirá para capturar información de procedencia y limitar el impacto de un agente fuera de control.

Imagino esta arquitectura de tiempo de ejecución de agentes seguros como una muñeca matrioska, de afuera hacia adentro:

Infraestructura → sandbox → arnés del agente → tiempo de ejecución → modelo

Cada capa tiene un propietario, un modo de fallo y un principio de diseño distintos. Analicémoslos.

Capa 1: Infraestructura

La infraestructura es el lugar donde se ejecutan físicamente los agentes. Pueden ser ejecutores de GitHub Actions, pods de Kubernetes o máquinas virtuales (VM). Esta capa se ocupa de la informática, las redes y la gestión de recursos, y es más importante de lo que se piensa.

Piensa en lo que sucede cuando pasas de un agente a docenas que se ejecutan en paralelo. Roy Belio logró que el sistema de investigación automática de Andrej Karpathy ejecutara 198 experimentos autónomos en OpenShift AI. Esto incluyó la programación de la GPU y la orquestación de tareas sin intervención humana. Ese no es un problema del arnés. No es un problema del sandbox. Es un problema de infraestructura. ¿Tu plataforma puede gestionar solicitudes de recursos contrapuestas y evitar que los agentes simultáneos se queden sin recursos? ¿También puede programar cargas de trabajo de GPU?

La programación de las GPU se está convirtiendo en una disciplina de infraestructura de primer nivel. Red Hat OpenShift 4.21 incluyó la asignación dinámica de recursos. Se trata de una API de Kubernetes que permite que las cargas de trabajo soliciten GPU por atributos (modelo, memoria, capacidad informática) en lugar de por recuentos brutos. También permite compartir las GPU entre contenedores, para que los sidecars de inferencia ligeros no desperdicien un dispositivo completo. Esto es infraestructura pura: sin políticas de sandbox, sin entradas en AGENTS.md ni elección de modelo. Solo la plataforma haciendo su trabajo.

Capa 2: Entorno de prueba (sandbox)

El sandbox restringe lo que el agente puede hacer y limita el impacto potencial si algo sale mal. Se trata del aislamiento. Mi colega Marta Anon Ruiz describió esta capa como la que "determina la intencionalidad del agente". Proyectos como OpenShell de NVIDIA funcionan en esta capa. Desde la perspectiva de la seguridad de la cadena de suministro de software, este es tu límite de confianza principal. Es la diferencia entre un agente que puede rm -rf /y uno que no, o la diferencia entre un agente que puede gh issue delete todos tus problemas de GitHub y uno que no (o uno que puede escribir y ejecutar su propio script para hacer lo mismo).

Si la infraestructura pregunta "¿dónde se ejecuta el agente?", el sandbox pregunta "¿qué tiene permitido tocar el agente?". Son preguntas diferentes con respuestas distintas.

Red Hat publicó una guía detallada sobre cómo crear medidas de seguridad resistentes para agentes de inteligencia artificial en Kubernetes. Incluye restricciones de contexto de seguridad (SCC) restricted-v2, políticas de red de denegación de salida por defecto y control de acceso basado en roles (RBAC) por agente. Cada uno es un control sustractivo. Comienzas con todo lo que el agente puede hacer y eliminas capacidades hasta que solo queden las necesarias.

La capa de sandbox va más allá de las políticas de red. Los contenedores en entornos de prueba Red Hat OpenShift, basados en Kata Containers y peer-pods, son una tecnología clave en esta capa. Toman medidas adicionales para aislar el proceso de un agente de su host. Consulta también el artículo sobre habilidades de los agentes y amenazas de seguridad. En él se exploran soluciones como la firma criptográfica de habilidades para verificar la procedencia antes de la ejecución. Una habilidad no firmada que se inserta en la cadena de herramientas de un agente es un ataque a la cadena de suministro de software. La capa de sandbox puede ayudar a tener esto en cuenta.

Proyectos como OpenShell de NVIDIA son relevantes en esta capa, al igual que las primitivas de seguridad integradas en los tiempos de ejecución de contenedores generales. Ninguno de ellos es un "arnés" en el sentido de Hashimoto. No estás enseñando al agente a trabajar mejor, sino que estás evitando que realice tareas peligrosas o inesperadas.

Capa 3: Arnés del agente

Esta es la capa sobre la que escribió Hashimoto, y es lo que Birgitta Böckeler llama el arnés de usuario. Esta es la capa de habilitación, que incluye archivos AGENTS.md, habilidades, herramientas personalizadas, linters diseñados a mano, peticiones del sistema y un buen conjunto de pruebas. Son elementos que diseñas de forma iterativa para aumentar las posibilidades de que el agente haga las cosas bien.

El artículo de Marco Rizzi sobre la ingeniería de arneses con flujos de trabajo estructurados resume el principio: "estructura de entrada, estructura de salida". El artículo describe el escaneo de la estructura del proyecto con LSP y MCP para generar peticiones contextuales. No solo le dice al agente qué hacer, sino que le da la información estructural necesaria para hacerlo bien. Esto es control con visión hacia el futuro en la terminología de Birgitta.

El uso de herramientas es una parte fundamental del arnés que hace posibles las guías computacionales que menciona Birgitta Böckeler. La llegada del uso de herramientas y el estándar MCP han hecho posibles los agentes útiles, lo que da al tiempo de ejecución del agente una mejor oportunidad de alcanzar sus objetivos. Cómo crear agentes de inteligencia artificial eficaces con MCP profundiza en este tema. Muestra cómo puedes habilitar a los agentes al dar a su arnés una forma de acceder a los recursos de tu empresa dinámicamente.

¿Cómo sabes que tu arnés funciona? Lo evalúas. Michael Dawson escribe sobre el desarrollo basado en la evaluación y presenta un marco de evaluación de 8 etapas con los patrones DeepEval y LLM como juez. Las evaluaciones son el ciclo de retroalimentación que te indica si los cambios en el arnés mejoraron o empeoraron al agente. Sin ellas, la ingeniería de arneses es solo una conjetura. Herramientas como evaluation hub ayudan a gestionar esto a escala.

Los artefactos del arnés presentan un problema de gestión. A medida que tu archivo AGENTS.md crece y tus herramientas personalizadas se multiplican, ¿cómo controlas sus versiones? ¿Cómo los compartes entre proyectos? El artículo sobre Lola, un gestor de paquetes de contexto de inteligencia artificial, trata el contexto de la inteligencia artificial como paquetes con versiones. Ese enfoque tiene sentido. Si los artefactos de tu arnés son de ingeniería, gestiónalos como tales.

Capa 4: Tiempo de ejecución del agente

El tiempo de ejecución del agente es el motor que impulsa su ciclo. Claude Code, OpenCode, Goose o algo personalizado. Se encarga de la distribución de herramientas, las ventanas de contexto y la gestión de conversaciones.

Esto es lo que Anthropic llamó un "arnés" en ese correo electrónico. Creo que es incorrecto o, al menos, impreciso. El tiempo de ejecución no es algo que puedas diseñar y mejorar, a menos que crees el tuyo propio. Ejecuta el ciclo: envía la petición, recibe la respuesta, distribuye las llamadas a las herramientas y devuelve los resultados. No puedo minimizar la importancia de esta capa. Los tiempos de ejecución mejoran constantemente y todos nos beneficiamos de ello.

Sin embargo, algunas organizaciones diseñarán los suyos propios. Si tienes requisitos de soberanía o necesitas funciones que ningún tiempo de ejecución estándar ofrece, debes diseñar el tuyo propio. Esto también aplica si tu caso de uso requiere un control muy alto del comportamiento del tiempo de ejecución. En estos casos, necesitas API sobre las cuales construir. Aquí es donde los proyectos como Llama Stack cobran importancia, al exponer API abiertas para respuestas, manejo de archivos, búsqueda y, en el futuro, memoria. Un tiempo de ejecución soberano basado en API abiertas es una propuesta diferente a uno bloqueado en un servicio propietario. Las plataformas de Red Hat admiten ambos caminos. Algunos equipos adoptan un tiempo de ejecución existente y diseñan el arnés de usuario a su alrededor. Otros crean su propio tiempo de ejecución con API abiertas porque su contexto lo exige.

Capa 5: Modelo y endpoint de inferencia

En cuanto a la distribución, la guía de Red Hat para integrar Claude Code con Red Hat AI Inference Server en OpenShift utiliza vLLM en Red Hat AI para la inferencia local. Tu modelo, tu clúster y tus datos. Ejecutar la inferencia en tu propio hardware tiene un gran impacto en el modelo de confianza de toda tu stack de agentes.

En cuanto a la procedencia, es importante el trabajo de Red Hat en la seguridad de la cadena de suministro de software moderna, específicamente Red Hat Trusted Artifact Signer y la firma criptográfica de modelos. Si no puedes verificar y gestionar la procedencia del modelo que ejecutas, toda tu stack superior se basa en cimientos no verificados. La firma del modelo es para la capa del modelo lo que la firma de habilidades es para la capa del arnés: una garantía criptográfica de que ejecutas lo que crees que ejecutas.

Sustracción frente a adición

El sandbox y el arnés tienen filosofías de diseño opuestas. El sandbox es sustractivo: eliminas capacidades para reducir riesgos. El arnés es aditivo: añades capas de conocimiento y herramientas para aumentar la competencia. Si los confundimos, enturbiaremos los principios de diseño que deben guiar a cada uno.

También tienen modos de fallo diferentes. Un fallo en el sandbox significa que el agente hizo algo que no debería haber podido hacer. Un fallo en el arnés significa que el agente hizo mal algo que debería haber hecho bien. Se trata de problemas distintos que requieren soluciones diferentes.

El sandbox puede desempeñar un papel secundario como registrador (un observador neutral de las actividades del agente). Esto permite certificar sus acciones de forma más confiable que si el tiempo de ejecución del agente se certificara a sí mismo.

El sandbox limita y observa. El arnés habilita y puedes mejorarlo. El tiempo de ejecución se ejecuta y no deberías diseñar uno propio a menos que sea necesario. Los agentes son tan seguros y confiables como la stack que los sustenta. Red Hat está creando esa stack open source en todas las capas, desde la programación de la GPU hasta la firma criptográfica de modelos. Si estás implementando agentes en producción y buscas una base verificable en lugar de solo esperar lo mejor, hacia allá vamos.