Docker Agent, software que convierte YAML en agentes IA
Escribir un fichero de configuración, lanzarlo con un comando y ver cómo la máquina obedece, Docker convirtió ese gesto en la forma estándar de mover software por el mundo con sus contenedores. Ahora quiere repetir la jugada con los agentes de inteligencia artificial, y su apuesta se llama Docker Agent, un proyecto open source con más de 3.300 estrellas en GitHub que define agentes en YAML y los trata como si fueran imágenes, según el repositorio oficial docker-agent.
La propuesta es fácil de resumir. Describes qué debe hacer tu agente, con qué modelo y qué herramientas trabaja. Docker Agent se encarga del bucle de orquestación, la ejecución de herramientas, la delegación entre agentes y la salida en streaming. Tú decides qué debe hacer el agente y el runtime resuelve cómo conectarlo todo por debajo.
El momento acompaña. Los agentes empezaron el año respondiendo preguntas y lo terminan abriendo pull requests, corriendo tests y tocando infraestructura real. Ese salto exige aislamiento serio, porque un agente con acceso a tu terminal necesita los mismos límites que un contenedor bien configurado. Docker, que lleva una década empaquetando procesos, llega a esta fiesta con el traje ya planchado.
¿Qué es Docker Agent y a qué sabe?
La presentación oficial lo resume con una analogía feliz. Docker Agent aspira a ser para los agentes lo que docker run fue para los contenedores, según su documentación. No es un framework donde escribes código, ni un servicio alojado, ni un modelo nuevo. Es una interfaz de línea de comandos que ejecuta agentes declarados en YAML o HCL, con una TUI interactiva, un modo headless para CI y servidores HTTP, OpenAI compatible, MCP y A2A.
El contraste con la competencia ayuda a situarlo. La mayoría de frameworks te piden pegar modelos, herramientas y flujos con Python o TypeScript. Aquí todo se declara en configuración y se ejecuta con un solo comando. Cambias de modelo con una línea, añades herramientas sin tocar código y versionas el comportamiento como versionas tus Dockerfiles.
Un ejemplo de como funciona los Docker Agents
La arquitectura de equipos multagente es su segunda seña de identidad. En vez de un generalista que lo intenta todo, defines especialistas con roles concretos y un coordinador reparte las tareas al más indicado. Cada agente trae herramientas propias, y el enrutado por hooks decide quién responde a cada petición según las reglas que escribiste.
El ecosistema de herramientas bebe de dos fuentes. Por un lado, trae utilidades integradas para el sistema de ficheros y la shell, con memoria propia para recordar el contexto. Por otro se conecta a cualquier servidor MCP, local, remoto o empaquetado como contenedor Docker, y suma recuperación con búsqueda híbrida y reranking para el contexto.
Definiendo tu agente con un fichero YAML
El fichero de configuración es el corazón del invento. En él declaras el modelo con sus instrucciones en lenguaje natural, y qué herramientas y subagentes lo acompañan. La sintaxis está pensada para que un desarrollador la lea de un vistazo, sin sorpresas ni magia oculta entre líneas.
El arranque es igual de directo. El comando de ejecución lanza el agente por defecto con su TUI, y variantes del mismo comando traen un agente del registro, generan uno nuevo de forma interactiva o ejecutan tu fichero local. Quien prefiera automatizar usa el modo exec para turnos sin interacción, con una bandera para imprimir solo la respuesta final.
Los modelos son intercambiables a voluntad. Varios proveedores conviven en la misma configuración, de los grandes laboratorios al Model Runner local de Docker. Esa agnosticidad protege tu trabajo, porque si mañana un proveedor sube precios o baja calidad, cambias una línea y sigues con tu día.
El empaquetado copia la receta de las imágenes. Compartes un agente con push y pull contra cualquier registro OCI, con la misma autenticación que ya usas para contenedores. Pujar crea el repositorio si no existe, y tirar de él lo deja corriendo en cualquier máquina con un comando. Nada de repositorios más README de instalación.
Un agente que solo habla es un loro con buena labia. Un agente que ejecuta comandos necesita una jaula con barrotes de verdad, y ahí los contenedores vuelven a ser protagonistas. Docker Agent se apoya en tres capas de aislamiento según el escenario, el sandbox local, el Model Runner y los sandboxes remotos de CI.
En tu máquina, el flujo natural combina WSL2 como backend de Docker Desktop con contenedores para las toolsets de MCP. Esa pieza merece contexto, porque ejecutar Linux dentro de Windows dejó de ser un experimento hace años. Como contamos en nuestra guía sobre si Windows sigue siendo un buen entorno para programar en 2026, WSL2 trajo un kernel real ultraligero que hoy sostiene el desarrollo con contenedores en Windows sin fricción.
La integración con GitHub dio el salto en el verano de 2026. Los Agentic Workflows de GitHub sumaron los Docker Sandboxes como runtime soportado, de modo que un agente de programación dispone de control amplio de su entorno, incluido lanzar contenedores, mientras el propio entorno vive aislado en una microVM con política de red e inyección de secretos, según relata el blog de Docker sobre agentes en GitHub Actions.
La demo pública lo deja cristalino. El agente corre en un runner Ubuntu alojado por GitHub, entra al sandbox, levanta una suite de integración Java con PostgreSQL mediante Testcontainers, encuentra un bug sembrado a propósito, lo arregla y abre un draft de pull request. La ejecución completa tardó 11 minutos y 16 segundos, y el parche final solo tocó el código bajo el directorio permitido.
El truco arquitectónico está en los daemons anidados. Cada sandbox es un entorno dedicado con su kernel, su sistema de ficheros y su red, y corre su propio daemon Docker privado. El agente tiene root dentro de la máquina virtual sin tocar jamás el daemon del anfitrión. El único puente entre ambos mundos es el directorio compartido del repositorio.
¿Qué ganas con todo esto?
Quien haya montado un agente a mano conoce el dolor, y no, no es una broma. El mismo bucle de modelo, herramientas y subagentes se reescribe en cada proyecto, compartirlo exige un repositorio más un README, y cambiar de proveedor significa retocar el SDK. Docker Agent ataca esos tres frentes con YAML reutilizable, distribución OCI y modelos intercambiables.
La gobernanza es el argumento que más pesa en empresas. Docker AI Governance aplica políticas de organización y equipo sobre red del sandbox, sistema de ficheros y acceso MCP, y registra las decisiones en logs de auditoría. Esos registros identifican el cliente fuente y la máquina, así el mismo modelo cubre portátiles y runners de CI sin inventar nada nuevo.
La seguridad también mejora por defecto. Los toolsets de MCP corren en contenedores con un clic, el modo de depuración permite invocar herramientas fuera del bucle del modelo para inspeccionarlas, y la evaluación con jueces dedicados mide la estabilidad repitiendo ejecuciones. Nada de esto elimina el riesgo de un agente autónomo, pero lo deja confinado y observable.
Para los equipos que ya viven en contenedores, la curva de aprendizaje es casi plana. Los mismos registros, la misma autenticación y la misma visibilidad de supply chain que Scout da a las imágenes se extienden a los agentes. Después de todo, si tu organización ya confía en OCI para mover software, mover agentes por el mismo carril reduce la superficie de novedad.
Capacidad
Docker Agent
Framework clásico en código
Definición
YAML declarativo
Python o TypeScript pegado
Distribución
Registro OCI con push y pull
Repo más README de instalación
Modelos
Multiprovider más Model Runner
Atado al SDK de un proveedor
Herramientas
Integradas más cualquier MCP
Conectores a medida por agente
Equipos
Multagente con delegación
Un generalista por defecto
Ejecución
TUI, CLI, API, MCP y A2A
Lo que implementes tú
¿Cómo probarlo sin romper nada serio?
La instalación cubre los caminos habituales. Docker Desktop desde la versión 4.63 lo trae preinstalado como plugin, y también hay binarios sueltos, fórmula de Homebrew y paquete de Winget. El binario se enlaza como plugin del CLI o se usa en solitario, a gusto del usuario.
El primer paso sensato es fijar el modelo. Configuras al menos una clave de proveedor o apuntas al Model Runner local para correr modelos abiertos en tu máquina. El catálogo de ejemplos del repositorio ofrece configuraciones listas para inspirarte, desde un pirata de juguete hasta depuradores serios.
Empieza con tareas de lectura. Pide al agente que explique un módulo, que dibuje el mapa de dependencias o que proponga tests sin ejecutarlos. Cuando confíes, abre la puerta a la escritura con límites claros, un directorio permitido y revisión humana de cada cambio antes de integrarlo.
Si el experimento crece, llévalo a CI con sandboxes. Describe el workflow agéntico en Markdown con su frontmatter, compílalo a Actions y deja que el agente trabaje confinado con red permitida mínima. La creación de la pull request ocurre en un job separado de salida segura cuyo parche solo admite ficheros bajo el directorio de código.
La jugada de Docker huele a historia que se repite. Primero los contenedores convirtieron el despliegue en un gesto aburrido y fiable, y una década después los agentes buscan su propio gesto aburrido. Definir en YAML, compartir por registro y ejecutar aislado es un candidato sólido a convertirse en ese estándar.
Habrá que ver si la comunidad adopta el formato o si cada laboratorio impone el suyo. El arranque es prometedor, con miles de estrellas y una integración real con GitHub que ya corre agentes confinados en CI. Si el formato cuaja, pedirle algo a un agente será tan normal como tirar de una imagen.
