Docker shipped an agent runtime, not a magic container.
Docker Agent is an open-source multi-agent runtime. It reads YAML or HCL, runs agents through a terminal interface, command line, or server, and can call built-in tools or MCP servers. Version 1.149.0 was published on October 7. Its release adds public GitHub repository skill loading, evaluator routing changes, pricing fixes, and terminal stability work.[1][2]
The artifact exists. We downloaded the official Linux AMD64 release and ran its version and help commands. It reported docker-agent version v1.149.0, commit bf4169c, and listed run, share, sandbox, session, evaluation, and server commands. We did not give it a model key or run an agent task.
The useful unit is a portable agent definition with explicit run controls beside it.
A registry reference answers where, not whether.
Docker Agent can push an agent definition to an OCI-compatible registry and run it from a registry reference. A tag is checked on each run. A digest can use the cached exact artifact. The documentation recommends digest pinning for reproducible external sub-agents.[3]
That is a distribution contract. It tells the runtime which package to load. It does not prove who reviewed the package, which model will answer, which external tools are safe, or whether the run may touch the host.
The caller should own the safety floor.
The permission system has four safety modes. Strict asks for each tool call. Balanced allows calls labeled safe and asks about the rest. Restricted allows safe calls and denies the rest without asking. Autonomous allows everything unless another rule blocks it. Docker says restricted mode is defense against unwanted calls, not a security boundary.[4]
An agent author may place a default safety mode in the package. The caller's command-line flag, alias, or user settings take priority. This matters because a third-party package can declare autonomous mode. Set a user-owned floor before running an unfamiliar reference.
Sandboxing is a separate mechanism.
The --sandbox flag asks Docker's separate sbx program to create or reuse a virtual machine. Shell, filesystem, and process work then runs inside that machine. Docker Agent does not implement the sandbox itself, and it does not turn every ordinary run into a container.[5]
The working directory is mounted into the virtual machine. The default network policy denies destinations until the runner opens model, package, or declared hosts. The machine and staged kit remain after a session so later runs can reuse them. Those details belong in the run receipt because they change the authority and residue of the job.
A budget is a stop, with boundaries.
Docker Agent can cap cost, cumulative tokens, and working time. Shared named budgets cover every agent that references the same name, so adding sub-agents does not multiply the allowance. The default is no budget.[6]
The runtime checks limits between turns. A model call or tool already in flight can overshoot before the next check. Cost limits also need model pricing data. An unpriced local or private model contributes no cost unless the config supplies pricing. Treat the budget as a stop policy, not a bank guarantee.
Write the coupling receipt before launch.
AGENT_REF=myorg/reviewer@sha256:[DIGEST] AGENT_VERSION=[INSPECTED] SAFETY_MODE=restricted SANDBOX=enabled SANDBOX_TEMPLATE=[DIGEST] WORKSPACE_MOUNT=[PATH] NETWORK_ALLOWLIST=[HOSTS] MAX_COST_USD=[VALUE] MAX_TOKENS=[VALUE] MAX_WORK_TIME=[VALUE] REVIEW_OWNER=[NAME] RESULT=[NOT RUN]
Keep the package identity and runtime controls in one review card. Record the result after the job ends. A checked template means the launch plan is complete. It does not mean the agent ran or the output passed review.