Docker Agent: Build AI Agents That Talk to Each Other (YAML, No Glue Code)

0:00The video opens with GPT-6 Luna and Claude Haiku 5.5 playing Battleship — each running as its own AI agent in its own process, talking over a protocol called A2A, with zero framework code. Just YAML files and a new tool from Docker called Docker Agent.

What it is

0:45Docker Agent is an open-source tool from Docker for building and running AI agents. Docker's own framing: it's "to AI agents what docker run is for containers." You describe an agent in a YAML file — the model it uses, its instructions, the tools it's allowed — and run it with one command. Docker Agent handles the agent loop for you: it calls the model, runs the tools, feeds results back, and repeats until the job is done.

How an agent is defined

1:15A complete agent is just YAML. 1:17The model line can point at OpenAI, Anthropic, Gemini, OpenRouter, or a local model through a Docker Model Runner. 1:29Tools come from a "tool sets" section: built-ins like file access and shell commands, plus any MCP server you want to hook up. An agent can also have sub-agents, so a coordinator can hand work off to specialists. Docker's docs show the comparison directly: on the left, the Python you'd normally write to loop a model over tool calls; on the right, the same agent in Docker Agent YAML — dramatically less boilerplate.

Three big ideas

1:59The three things the host calls out:

• Agents become configuration. Version them, review them in pull requests, swap the model by changing one line.
• Distribution. Push an agent to Docker Hub (or any OCI registry) and anyone runs it with docker agent run <image> — the same way you share a container.
• Agents run as services. One command turns an agent into an HTTP API, an MCP server, or an A2A server that other agents can call.

2:40If you're on Docker Desktop 4.63 or newer it's installed by default; otherwise install via Homebrew and symlink it into the Docker CLI plugins folder. 2:57The smallest possible agent is a model, a description, and an instruction — then docker agent run agent.yaml drops you into a terminal UI.

The on-call demo

3:09The realistic example: checkout is down and you're on call. Two agents in one file — a log analyst (the only agent that can read logs, with a read-only file tool locked to the logs folder) and an on-call assistant (no file access at all — the only thing it knows is the analyst's URL). In a real company the platform team owns the log analyst and runs it next to the logs; any other team's agent can ask it questions without ever getting access to the logs themselves. 3:45He runs docker agent serve a2a with the log analyst on port 8080, then asks the on-call assistant why checkout has been throwing 500s since ~2 p.m. — the question reaches the analyst, it reads app logs and deploy history, and sends findings back, which the on-call agent turns into an incident summary.

The battleship demo

4:14Same pattern, more fun: three agents. Two players (blue = GPT-6 Luna, red = Claude Haiku 5.5), each served over A2A on its own port, plus a referee running on Kimi K3 — so neither player's own model judges its game. Haiku gets off strong, finds the carrier early, and works down the line until it sinks it; Luna comes back hard, and by the endgame both are down to their last ship. Haiku finds the final submarine in row H and wins in 34 shots at 50% accuracy — and Luna had sunk all but one of Haiku's ships by then, so it was genuinely close. The host is careful to call it a game, not a benchmark: both models "clearly played better than random," and Haiku happened to win.

5:24Bottom line: write agents in YAML, run them with one command, share them through a registry, and connect them over A2A with nothing more than a URL — no framework glue code.

Claims checked

Sources & further reading