# Mecatl, los agentes de IA llegan a Kubernetes > Los creadores de Kubernetes publican Mecatl, un harness de agentes de código abierto que separa el bucle del agente del cliente, el modelo y el entorno. > Por José Maldonado · Agentes de IA · 2026-10-16 La mayoría de los asistentes de código viven donde vive el desarrollador. El bucle que llama a las herramientas, el estado de la conversación y la ejecución de comandos corren en el mismo portátil, y eso plantea un problema que no aparece hasta que la organización intenta desplegar la herramienta para miles de ingenieros en lugar de para seis. Ese es el diagnóstico que sostienen Craig McLuckie y Joe Beda, dos de los creadores de Kubernetes, desde su empresa Stacklok. Su respuesta es [Mecatl](https://github.com/stacklok/mecatl), un harness de agentes de código abierto que arrancó en junio de 2026 y que está diseñado para ejecutarse en Kubernetes en lugar de en un escritorio. McLuckie presentó el argumento completo en el [blog de la CNCF el 28 de septiembre](https://www.cncf.io/blog/2026/09/28/the-case-for-a-cloud-native-agent-harness/) y los dos lo desarrollaron después en una [entrevista con Latent Space](https://www.latent.space/p/stacklok) publicada el 7 de octubre. La tesis se apoya en una comparación histórica que sus autores conocen bien. Los problemas de mantener sesiones fiables, aislar la ejecución de herramientas y preservar contexto se parecen bastante a la orquestación de contenedores de principios de la década pasada, el terreno del que salió Kubernetes en 2014. Si los agentes tienen el mismo tipo de problemas que tuvieron las aplicaciones distribuidas, la apuesta es que se gestionen con las mismas herramientas. ## ¿Por qué un harness de escritorio no escala? El punto de partida del argumento es arquitectónico, no de rendimiento. En un harness de escritorio, el bucle del agente, la ejecución local y el estado de sesión arrancan dentro del mismo proceso, según describe Beda. Aunque la herramienta ofrezca complementos y cierta modularidad, la arquitectura sigue siendo un proceso único o un conjunto de procesos fuertemente acoplados y pensados para correr en una máquina personal. Esa decisión tiene consecuencias cuando llega el despliegue corporativo. El código y el contexto de un agente suelen derivarse del entorno local, y ahí es donde está la propiedad intelectual del trabajo. Beda lo resumió con una frase directa: gobernar algo que vive en un escritorio es mucho más difícil que gobernar algo que vive en la infraestructura de la empresa. Cabe preguntar si basta con empaquetar el harness en una máquina virtual o moverlo a un contenedor. Los dos fundadores sostienen que ese traslado directo, al que llaman \*lift and shift\*, arrastra problemas de ciclo de vida. El caso concreto que mencionan es la pausa segura: detener un agente mientras espera la respuesta de una persona sin perder el hilo de lo que estaba haciendo. Una arquitectura que nunca previó ese estado intermedio no lo resuelve añadiendo una capa de virtualización. ## Mecatl una propuesta única La propuesta de Mecatl es trocear el harness en piezas que se puedan gestionar por separado. El bucle del agente queda independiente del cliente, del proveedor de modelo, del almacén de estado y del entorno de ejecución. En palabras de Beda, se trata de tomar la parte del sistema que se sabe ejecutar bien en la nube y separarla de las operaciones más sensibles, como la llamada a herramientas o el acceso a una shell. El cambio más tangible está en dónde vive la sesión. En los harnesses de escritorio, el estado de una conversación con un agente suele acabar como una colección de ficheros JSONL en disco. Mecatl mueve ese estado a sistemas gestionados, y eso abre la puerta a consultarlo, auditarlo, moverlo entre máquinas y aplicar políticas sobre él sin depender de que nadie copie una carpeta. Pieza En un harness de escritorio En el diseño de Mecatl Bucle del agente En el mismo proceso que el cliente Aplicación independiente en el clúster Estado de sesión Ficheros en el disco local Almacén gestionado y consultable Ejecución de herramientas En la máquina del usuario Aislada del bucle del agente Proveedor de modelo Fijado en la configuración local Intercambiable sin tocar el bucle Pausa a la espera de una persona No prevista en la arquitectura Estado intermedio de primera clase McLuckie añade a ese diseño una pregunta de fondo sobre identidad. Su crítica es que la identidad de un agente se está razonando con las herramientas de identidad pensadas para personas, y que esa herencia condiciona el resto del diseño. Es una observación que apunta a un problema que las organizaciones regulatorias van a encontrar antes que las demás, porque necesitan saber quién actuó y en nombre de quién. ## ToolHive y la puerta de entrada a los agentes Mecatl no es la primera pieza que [Stacklok](https://stacklok.com/) pone en abierto. Antes llegó [ToolHive](https://github.com/stacklok/toolhive), una plataforma para ejecutar y gobernar servidores MCP, el protocolo que usan los agentes para conectarse a herramientas externas. Empezó como una forma de gestionar esos servidores en contenedores Docker sobre el escritorio y ha evolucionado hacia una pasarela sobre Kubernetes, con un registro y un operador que ayuda a desplegarlos y a resolver la autenticación de entrada y salida. La secuencia tiene lógica. Primero se resuelve cómo el agente llega a las herramientas, después cómo se ejecuta el propio agente. La tercera pieza es una pasarela de modelos, el AI Gateway, que es lo único que la empresa no ha abierto todavía y que Beda sitúa en la hoja de ruta con intención de publicarla. Las funciones que cubre esa pasarela delimitan bien qué le importa a su clientela. Control de acceso, presupuestos y enrutado entre proveedores de modelo, además de informes periódicos de consumo por equipo. Lo que no hace, por decisión, es elegir el modelo en función de la tarea. McLuckie explicó que prefieren que esa elección semántica ocurra dentro del harness, donde hay más contexto disponible para decidir. Es una diferencia apreciable frente a otros productos del mercado que venden precisamente el enrutado inteligente como característica principal. ## El modelo de negocio detrás del código abierto La pregunta obvia ante dos proyectos abiertos es de dónde sale el dinero. La respuesta de McLuckie es que ToolHive y Mecatl están pensados para ser útiles por separado, y que la empresa vende lo que llama el espinazo empresarial: un plano de control que aporta identidad coherente, autorización, políticas y auditoría sobre las piezas abiertas. Ese reparto no es nuevo en el mundo de la infraestructura, y explica por qué el discurso de los fundadores insiste tanto en el paralelismo con Kubernetes. La comparación que hacen es explícita: igual que Kubernetes permitió a las empresas ejecutar en la nube sin atarse a las particularidades de un proveedor concreto, su objetivo declarado es reducir la dependencia de las organizaciones respecto a los laboratorios de frontera y a los hiperescaladores. Las herramientas señaladas son Codex, Claude Code y GitHub Copilot, entre otras de los grandes proveedores. La motivación tiene un componente comercial claro. Si el valor de un agente se queda en el portátil del empleado, la empresa no puede gobernarlo ni acumularlo. Si se mueve a su infraestructura, sí. Beda lo ilustró con una analogía que cualquier responsable de sistemas entiende: las conversaciones de un empleado con un agente, mientras trabaja para la empresa, pertenecen a la empresa, y se van a querer gestionar y gobernar como se gestiona el correo electrónico corporativo. ## La apuesta de que los agentes se gestionen como el correo La idea que subyace a Mecatl no es tanto técnica como organizativa. Durante la última década, las empresas aprendieron a tratar su infraestructura como un recurso centralizado y gobernable, y ese aprendizaje es lo que convirtió a Kubernetes en un estándar. Aplicar el mismo razonamiento a los agentes supone aceptar que el trabajo de un agente es un activo de la empresa y no una conversación privada en una máquina. Ese cambio tiene un coste que los fundadores reconocen de pasada y que conviene mirar de frente. Un harness centralizado es más gobernable y también más observable por la organización que lo despliega. Para el desarrollador que usa el agente, la comodidad de tenerlo todo en su portátil no desaparece por decreto, y muchas herramientas seguirán viviendo ahí porque resuelven bien el problema inmediato. Lo que Stacklok está poniendo a prueba es si existe un mercado dispuesto a pagar por la versión gobernable antes de que un incidente la haga obligatoria. Con dos proyectos abiertos y un plano de control como producto, la respuesta llegará de los sectores que ya tratan sus datos con ese nivel de formalidad.