Docker's Agent CLI plugin packages AI agents as OCI artifacts for push, pull and run

Docker ships an agent runtime as a CLI plugin

Docker's engineering team has open-sourced Docker Agent, a plugin for the docker CLI that builds, runs and distributes AI agents. According to a detailed walkthrough published on dev.to, the plugin comes pre-installed with Docker Desktop 4.63 and later, so docker agent works out of the box; Homebrew and standalone binaries from GitHub Releases are the alternatives. The project lives at docker/docker-agent under an Apache-2.0 licence, is written in Go, and is unusually busy for a young project — the dev.to author counts more than eleven thousand commits, roughly 4.6k stars, and a v1.152.0 release in late October 2026. The author also notes a March 2026 rename, so older tutorials referencing a different binary name are describing the same tool.

Agents become OCI artifacts

Distribution is the headline feature. An agent is declared in YAML, and docker agent share push ./agent.yaml ghcr.io/username/my-agent:v1.0 packages that definition as an OCI artifact — the packaging format registries already use for container images, except it carries an agent configuration rather than a filesystem. Anyone on the team can then run the agent with docker agent run myorg/agent:tag, pulling straight from Docker Hub, GitHub Container Registry or any OCI-compatible registry.

The image lifecycle carries over too. Per the dev.to post, a --key flag signs on push and verifies on pull using a DSSE envelope over an in-toto statement, the same ecosystem cosign interoperates with, and agents can be pinned by digest (myorg/agent@sha256:...) where rollback protection matters.

A YAML-first authoring model

The minimal example in the project's README is about ten lines: one agent with a model, a description the runtime uses when routing work, an instruction that serves as the system prompt, and an optional toolset list. Toolsets include an MCP type that can point at any Model Context Protocol server, with docker:duckduckgo acting as a catalog shorthand for web search. Useful CLI details include -a to select one agent from a multi-agent file, --exec to skip the terminal UI for scripting, and docker agent new to generate a config interactively. Model providers are pluggable: the README lists OpenAI, Anthropic, Gemini, AWS Bedrock, Mistral, xAI and Docker Model Runner for local models, plus custom OpenAI-compatible endpoints. At least one API key or a local Model Runner endpoint is required before anything runs.

Delegation, handoffs and agent teams

Single agents degrade as tasks grow — one model juggling planning, searching and writing in a single context window — and Docker Agent's answer is multi-agent configuration. The docs, as summarised on dev.to, describe two patterns. Delegation, configured through sub_agents, has a parent dispatch a task to a specialist, block, and collect the result; the child runs in its own sub-session with a clean task description, driven by a transfer_task tool the docs say is always auto-approved. Handoff keeps the same session and passes the full conversation history to the next agent, which suits pipelines and can loop back on itself. Both patterns can be mixed in one config.

The repo's dev-team example pairs a product-manager coordinator with designer and engineer sub-agents plus a shared SQLite-backed memory that persists decisions across turns. A force_handoff option routes the conversation at the runtime level whenever an agent finishes, bypassing the model's own tool-calling, and a background_agents toolset supports parallel fan-out with run, list and join calls so several specialists can work while a coordinator waits.

Why it matters

Anyone running agents inside a team knows the problem the dev.to author calls the "snowflake agent": the system prompt lives in a note app, the tool wiring lives in a repository nobody can find, and sharing amounts to pasting YAML into a chat window and hoping the receiver reassembles it correctly. Docker's move makes agent distribution boring in the best way: the registries, signing, digest pinning and access controls that operations teams already run for container images now apply to agents, with no new infrastructure to stand up. The trust question is not solved — an agent with shell access to a host is still code execution, a concern the post raises — but packaging agents as verifiable, versioned artifacts is a prerequisite for treating them as deployable software rather than folklore.