Agent is Docker's open-source builder and runtime for AI Agents. Define roles, models, and tools in a declarative file, then run a single assistant or a coordinated team from the command line.
Agent is an open-source builder and runtime from Docker that turns a plain configuration file into a working AI assistant. You describe the Agent's role, pick a model, and attach the tools it may use, then run it from a terminal or inside another application. The workflow stays the same whether you need one specialist or a team: write the definition, review its permissions, and start a session. Because the definition is a text artifact, it can be reviewed in a pull request, versioned beside your code, and shared with teammates instead of being recreated by hand. That makes Agent useful for repeatable, auditable work such as triaging issues, summarizing repositories, or automating a documented process.
Running Agent on Windows follows the same route as most container tooling: a Linux environment supplied by Windows Subsystem for Linux gives the runtime somewhere consistent to execute, so shell-based tools and file paths behave predictably. From there, the practical loop is to define a task, watch the transcript, and refine the instructions until the output is dependable. Sessions can be saved and resumed, snapshots let you step back to an earlier point in a run, and interactive use is not mandatory because the same definition can execute headlessly in a pipeline. Teams often keep several definitions, one for code review, one for release notes, one for support triage, and share them through a registry.
The main benefit of Agent is that it replaces ad-hoc prompting with a definition you can review and reuse. Because models, instructions, and tool permissions live in one configuration file, a teammate can read exactly what the assistant is allowed to touch before it runs. That transparency matters when an Agent can read files, run commands, or call an external API on your behalf. Second, the multi-agent model mirrors how real work is divided: a coordinator can pass a narrow task to a specialist and combine the results, which keeps long instructions out of a single overloaded prompt. Third, provider choice is not locked in, since you can point an Agent at a hosted model or run one locally through Docker Model Runner when data should not leave the machine. Finally, distribution through a registry means a useful Agent travels as an image rather than a folder of notes, so onboarding a colleague is a pull and a run rather than a setup checklist.
Every Agent starts as a configuration file that names its model, its instructions, and the tools it may call. Because the definition is plain text, you can keep it in version control, review changes in a pull request, and copy it between machines without installing anything extra. Editing is a matter of changing a few lines and rerunning, so tuning behaviour is fast and repeatable.
A single definition can describe a team rather than one generalist. You nominate a root Agent that receives the request and gives it specialist sub-agents, each with its own instructions and tool access. The coordinator can hand off a task, wait for the result, and continue, which keeps long procedures readable and stops one overloaded prompt from doing everything at once.
Model Context Protocol servers extend what a definition can reach: issue trackers, browsers, databases, design tools, and internal APIs. You can attach a server by reference from the Docker MCP Catalog or point at your own command, then narrow the exposed tool list so the model sees only the handful of actions it needs. That restraint improves reliability and reduces accidental calls.
Agent is not tied to one vendor. A configuration can route different sub-agents to different providers, mix a large reasoning model with a cheaper one for routine steps, or run entirely on local weights through Docker Model Runner when prompts and files must stay on the machine. Switching providers is a configuration change rather than a rewrite.
Beyond MCP, the runtime ships tools that cover ordinary automation work: reading and writing files, running shell commands, working with Git repositories, fetching web pages, keeping notes in memory, and maintaining a task list. Because they are part of the runtime, you do not have to build a server for basic file or command access before your first useful run.
Conversations are stored as sessions, so a long investigation can be paused and picked up later without repeating earlier prompts. Snapshots capture the state of a run, letting you step back after a poor result instead of starting over. Together they make experimentation cheap and keep an auditable record of what was asked and what the runtime did.
Agent can be given guardrails before it is trusted with real work. Tool access is allow-listed per definition, sensitive calls can require manual approval, ignore files keep credentials and build output out of reach, and budget settings cap consumption so an unattended run cannot quietly spend without limit. These controls are configuration, not extra code.
A finished definition can be published as an image and pulled by anyone who needs it, so sharing an assistant is closer to pulling a container than emailing instructions and hoping the setup matches. Versioned tags let a team pin the release it trusts, while the receiving side still controls model choice, credentials, and permissions.
It is a builder and runtime for AI assistants that are defined in configuration files rather than written as programs. Typical uses are repetitive developer and operations work: reviewing a repository, drafting release notes, triaging issues, summarising documents, or querying an internal service through MCP. You keep the definition once and rerun it whenever the same task comes up again.
Definitions are written in a readable configuration format rather than source code, so editing an instruction or swapping a model does not require software development experience. Some comfort with a terminal helps, because runs are started from a command line, but the runtime handles container setup, tool wiring, and the conversation loop on your behalf.
Yes. A configuration can reference a hosted provider, a gateway, or local weights served through Docker Model Runner. Local inference keeps prompts and file contents on the machine, which suits regulated or confidential material, while hosted models remain useful when a task needs the strongest reasoning available for the hardest steps.
The main route is MCP. You reference a server from the Docker MCP Catalog, or supply your own command and credentials, and the runtime exposes those actions to the model as tools. API and OpenAPI tool definitions cover services that have not been packaged as MCP servers yet.
Only through tools you enable. Permission settings decide which tools are available and whether a call needs confirmation, sandbox mode restricts execution, and ignore rules hide paths such as credential files. Nothing outside the configured tool list is reachable, so the safest approach is to start narrow and widen access deliberately.
Yes. The same definition runs headlessly, which suits scheduled jobs and continuous integration, and the runtime can also be exposed through an API or chat server for other applications to call. A budget cap and clear approval rules are worth setting first so an automated run stays predictable.
Publish the definition as an image and let colleagues pull it. The recipient still supplies their own model credentials and permissions, so the shared piece is the behaviour and tool wiring rather than anyone's secrets. Tags keep a known-good release available while the definition continues to evolve.
Comments