Docker Open-Sources Docker Agent: Define an Agent in YAML, Run It Like a Container

Yesterday, Docker copied the entire "container workflow" into the agent world

On October 8, a project called Docker Agent was submitted to Hacker News. On October 9 it sat on the HN front page, timestamped "1 day ago," with 290 points and 133 comments. The same day, dev.to's tech digest picked it up too — within 24 hours, the two most important information sources in the developer community had pushed it into the spotlight at once.

This is not another agent wrapper. It is an officially open-sourced docker CLI plugin from Docker itself: agents defined in declarative YAML (agent.yaml), with an official tagline of just three words — "no code required."

One sentence to sum up what it does: it turns the whole loop of defining, running, and distributing agents into a workflow identical to containers. docker agent run agent.yaml runs a local agent definition; docker agent run myorg/agent:tag pulls an agent from a remote registry — the syntax is barely distinguishable from the docker run you've used for a decade. For any developer who already has Docker installed, the learning curve is effectively zero.

But this article is really about something else: what matters most about Docker Agent isn't the feature list — it's that, for the first time, the agent world gets a "packaging format" like containers have. Reproducibility, sharing, and deployment in one — exactly the problem containers solved back in 2013, and the one agents have been fumbling with for over two years.

What it is: an official docker CLI plugin

Let's get the positioning straight. Docker Agent is not some external project Docker invested in, nor a community plugin — it lives in Docker's official repository (docker/docker-agent) as a docker CLI plugin, open-sourced under Apache-2.0. Docker Desktop 4.63 and above ships it preinstalled, so docker agent works out of the box; those who don't use Desktop can install it via Homebrew.

The words "official plugin" carry real weight. The typical agent-tool script of the last two years goes like this: a startup ships an agent definition in a proprietary format, accumulates users, raises a round, then gets acquired by a bigger platform or slowly fades. Docker did the opposite: it made the agent definition an open YAML file and turned the "definition layer" into public infrastructure. That posture looks less like shipping a product and more like paving a racetrack.

The core interaction is almost absurdly simple: write an agent.yaml describing who this agent is, which model it uses, and which tools it can call; then docker agent run agent.yaml, and it's running. No glue code, no service framework to set up, no need to understand how the agent loop turns. YAML is the agent.

Under the hood: model-agnostic, MCP-native, full RAG stack

The feature list holds few "black magic" items, but the combination is seasoned — every item lands squarely on the 2026 consensus of agent engineering:

• Model-agnostic. Supports OpenAI, Anthropic, Gemini, AWS Bedrock, Mistral, xAI, plus Docker's own Model Runner — seven providers in total. Switching providers means editing a config in the YAML, not rewriting the agent. With model pricing and capabilities reshuffling every quarter, this design isn't a "feature," it's a survival strategy.
• Native MCP for tools. Local MCP servers, remote MCP servers, and Docker-based MCP servers all plug in directly. One of the soundest bets of 2026: MCP is already the de facto standard for agent tooling, and instead of inventing its own tool protocol, Docker simply stood on the standard's side.
• Built-in think, todo, and memory tools. The agent's reasoning, task breakdown, and memory come out of the box — no need to build them from scratch. That trio happens to be the exact watershed between "an agent that gets work done" and "a chatbot that just talks."
• The full RAG stack, all at once: BM25, embeddings, hybrid retrieval, and reranking. Anyone who has built a knowledge-base agent knows retrieval is where most of the pitfalls live; Docker Agent makes each mainstream approach an option instead of deciding for you.
• Multi-agent orchestration. The README's own words: "specialized agents that delegate tasks automatically" — agents with specialized roles handing tasks off to each other on their own. Note the word "automatically": no hand-written DAG orchestration; an agent itself decides when something belongs to a more specialized agent and passes it along.

Each item on its own is hardly a first; but packed into a single docker agent run, the meaning changes: building a working agent used to be an engineering project — now it's a configuration.

The killer move: agents push and pull like images

If it were only YAML definitions and docker agent run, Docker Agent would be "yet another nice agent runner." What truly separates it from every other agent tool is this one line: agents can be pushed to and pulled from any OCI registry — distributed exactly like images.

Anyone who has used Docker instantly gets what that means. The container-world workflow and the agent-world workflow now map one to one:

Container world	Agent world (Docker Agent)
Dockerfile	agent.yaml
docker run nginx	docker agent run agent.yaml
docker pull myorg/app:tag	docker agent run myorg/agent:tag
docker push to a registry	agent push to any OCI registry
Docker Hub / private registries	any OCI registry (a ready-made global distribution network)

Every row of that table is a dimensionality reduction attack. Think about what sharing an agent looks like today: copy a prompt, paste it into a chat box, and pray the other person's model version and tool setup match yours. In the Docker Agent world, sharing an agent is docker agent run myorg/agent:tag — the version pinned, the dependencies (model, MCP tools, knowledge-base config) written in the YAML, runnable the moment it's pulled. Reproducibility, sharing, deployment — three in one, solved in a single stroke.

One level deeper: agent.yaml is a text file. It goes into git, through PR review, gets versioned with tags. From now on, "changing an agent's behavior" becomes opening a PR whose diff plainly shows which tool permission changed and which model got swapped. Reviewing agent changes will feel as natural as reviewing a Dockerfile. That's the pivotal step from agent "alchemy" to agent engineering: everything mutable becomes a reviewable artifact.

Why this is a landmark moment for "agent engineering"

A dose of rationality first: the agent track in 2026 is brutally crowded, with new agent frameworks and orchestration tools landing almost weekly. Why does Docker's move deserve its own article? Three judgments:

First, what agents lack was never smarter models — it's engineering. For two years, agent definitions have been scattered across proprietary formats: switching tools means rewriting, sharing means copy-pasting prompts, deployment means "it works on my machine." What Docker solved for containers in 2013 was exactly that class of problem — from "runs on my machine" to "runs on any machine." Docker Agent ports that same answer, verbatim, into the agent world. History doesn't repeat, but it rhymes.

Second, Docker's real weapon isn't technology — it's distribution. Preinstalled in Docker Desktop 4.63+, docker agent is out-of-the-box for a vast developer base; OCI registries are a ready-made global distribution network, no new "Agent Hub" required. While everyone else competes on what the agent itself can do, Docker has occupied the "definition layer + distribution layer." Once that position holds, every agent tool after it will have to be compatible with agent.yaml — not the other way around.

Third, Apache-2.0 plus official status is a bet that agent.yaml becomes the de facto standard. Docker didn't turn the agent definition into a proprietary moat; it open-sourced it under a permissive license, fully compatible with standard OCI registries. It's replaying Docker's most successful move ever: trade openness for ecosystem, trade ecosystem for standard-setting. Last time it was the Dockerfile and the image format; this time it's agent.yaml and agent distribution.

The counterintuitive detail: this is not bandwagon-jumping

Seeing "Docker officially open-sources an agent tool in October," the first reaction might be: the container giant finally couldn't resist milking the agent hype. But the repository data tells a different story:

Metric	Figure
Repository created	2025-09-01
Commits	10,735
Releases	263
Stars	4,284
Forks	498
License	Apache-2.0

This repository was created on September 1, 2025 — more than a full year before the HN explosion. 10,735 commits and 263 releases: this is no flash-in-the-pan "open source for the sake of it," but an engineering effort that ground away quietly for over a year. The 290 points and 133 comments on HN look less like "overnight virality" and more like "a year of slow work finally being seen."

The timeline is telling: in September 2025, agent hype was nowhere near today's frenzy, and the MCP protocol was still early. Starting work at that point means Docker wasn't chasing a trend it saw — it had already decided, a year ahead, that "agents need container-style engineering." Viewed from October 2026, that call looks frighteningly accurate.

Sober second thought: how far can YAML go?

After the praise, some cold water. There are questions Docker Agent must answer — and currently has no answers for:

• How far can declarative YAML go? Simple agents read elegantly in YAML, but once agent behavior gets complex enough — conditional branches, dynamic tool selection, long state-machine chains — does the declarative form become a new ceiling? The flip side of "no code required" could be "no complex behavior supported." To be fair, the Dockerfile faced the same question back in the day ("how complex a build can a declarative file express?"), and the eventual answer was engineering mechanisms like multi-stage builds and layer caching. Whether Docker Agent walks a similar path is worth watching.
• The debugging experience of automatic multi-agent delegation. "Specialized agents that delegate tasks automatically" sounds lovely, but when one agent hands a task to a second, which hands it to a third — who do you blame when it breaks? Observability across the call chain is the acknowledged hard nut of multi-agent systems, and YAML alone can't crack it.
• The battle for the niche has only just begun. Tightly integrated proprietary agent tools like Claude Code and Codex, versus an open "definition layer" like Docker Agent — two different roads. The former bets on "the best model plus the deepest integration," the latter on "the most open format plus the widest distribution." The roads aren't mutually exclusive, but developer attention is finite.

Looked at another way, though, these questions prove Docker Agent picked the right battlefield — only infrastructure worth taking seriously is worth nitpicking. Nobody nitpicks the debugging experience of a toy.

What it means for a one-person team

Finally, the question VibeFix readers care about most: what does this have to do with me?

If you're single-handedly maintaining a vibe coding project, Docker Agent's significance is concrete. Permissions and tool surface get declaratively pinned down: which tools the agent can use, which model it calls, how memory is stored — all in one YAML file, reviewable at a glance, no more digging through scattered configs and glue code.

Agent changes can go through the PR process for the first time. agent.yaml lives in the git repo; giving the agent a new tool, swapping a model, tuning a prompt is just an ordinary commit and PR. Code review covers the agent's changes as a matter of course — a phase change for a one-person team: "tuning the agent" used to be alchemy; now it's an engineering change, with a diff, a history, and a rollback.

One-person teams get to play multi-agent collaboration too. Multi-agent used to be "team-scale" engineering complexity: orchestration, delegation, state sync — every piece needed code. Now it's a few specialized agents defined in one YAML file, delegating automatically. A team of one can, for the first time, own "a team of agents."

From the Dockerfile to agent.yaml, Docker took thirteen years. But what it's trying to do this time is exactly what it did thirteen years ago: turn something chaotic and irreproducible into a standard part everyone can use and everyone can distribute. Last time it changed software distribution; this time it wants to change agent distribution. The 290 upvotes on the HN front page are developers voting with their clicks: this road — we're following it.