docker-agent-config

Original skill document

Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.

Docker Agent Configuration

Overview

Docker Agent (the CLI is docker agent, the open-source project is cagent) runs AI agents declared in a YAML file instead of application code. This skill owns the agent.yaml artifact: the agents section (each entry's model, instruction, and its own toolsets/sub_agents), the top-level models/providers sections referenced from agents, and a top-level commands group agents can opt into with use_commands. It does not cover invoking the CLI or serving/sharing the config — see Related skills.

When to use this skill

Activate this skill when:

The user is creating, editing, or reviewing an agent.yaml/agent.yml/agent.hcl file.
The user wants to add a tool/toolset, an MCP server, or a sub-agent to an agent config.
The user wants to choose or configure a model/provider (OpenAI, Anthropic, Google, Bedrock, Docker Model Runner, custom endpoint) for an agent.
The user wants a multi-agent "team" with a coordinator delegating to specialists.

Do not use this skill when

Do not use this skill when:

The task is about running the CLI (docker agent run flags, --safety, --sandbox, aliases, worktrees) — use docker-agent-run.
The task is about exposing an agent as a server (serve mcp/api/a2a/acp/chat), distributing it (share push/pull), or evaluating it (evaluation sessions, --baseline regression gates) — use docker-agent-deploy.
The task is about a generic Dockerfile or Compose service unrelated to Docker Agent — use docker-build-strategies or docker-compose-patterns.

Core guidance

File structure

Every config needs at least one agent under top-level agents:. The agent

named root, or the first agent defined, is the entry point that receives user messages.

yaml

  agents:
    root:
      model: anthropic/claude-sonnet-4-5
      description: A coding assistant
      instruction: |
        You are an expert developer. Help users write clean,
        efficient code. Explain your reasoning step by step.
      toolsets:
        - type: filesystem
        - type: shell
        - type: think

Required agent properties: model, description, instruction (or

instruction_file). description is not decoration — other agents read it to decide whether to delegate to this one, so keep it accurate.

Use instruction_file (a relative path, no ..) instead of an inline

instruction for long prompts; this keeps diffs focused on behavior, not YAML escaping. instruction and instruction_file are mutually exclusive. instruction_file is not supported for agents loaded from an OCI reference or URL — inline instruction there.

Models and providers

Two ways to set a model: inline provider/model shorthand, or a named

entry under top-level models: referencing a provider. Use the named form whenever you need temperature, max_tokens, thinking_budget, or reuse across agents.

yaml

  models:
    claude:
      provider: anthropic
      model: claude-sonnet-4-5
      max_tokens: 64000

  agents:
    root:
      model: claude

Built-in provider keys: openai, anthropic, google, amazon-bedrock,

dmr (Docker Model Runner, local, no API key), ollama (local). Dozens of additional built-in aliases exist (mistral, groq, xai, together, azure, github-copilot, openrouter, ...) — each needs its own <PROVIDER>_API_KEY-style env var; run docker agent models --all to see what's resolvable, and docker agent setup to register credentials interactively instead of hand-editing env vars.

Never hardcode an API key in agent.yaml. Provider credentials come from

environment variables (token_key for custom providers) or from ~/.config/cagent/.env written by docker agent setup.

Prefer dmr/<model> for agents that must run offline or must not send data

to a third party; it costs nothing and needs no credential. Use a paid cloud provider only when the task needs it.

Give resilience-critical agents a fallback so a provider outage or rate

limit does not stop the run:

yaml

  agents:
    root:
      model: anthropic/claude-sonnet-4-5
      fallback:
        models: [openai/gpt-5, google/gemini-3.5-flash]
        retries: 2      # per model, for 5xx errors
        cooldown: 1m    # stick with fallback after a 429

For a self-hosted/OpenAI-compatible endpoint (vLLM, LiteLLM, a corporate

gateway), define a providers: entry with base_url and token_key rather than putting the URL inline on every model:

yaml

  providers:
    my_gateway:
      base_url: https://api.example.com/v1
      token_key: MY_API_KEY
  models:
    my_model:
      provider: my_gateway
      model: gpt-4o

Toolsets

Built-in toolsets need no external dependency: filesystem, shell,

think, todo, tasks, memory, fetch, background-jobs, script, lsp, api. Add one per list entry:

yaml

  toolsets:
    - type: filesystem
    - type: shell

If an agent only describes a plan but never executes it, add type: todo

(or shell) — a common symptom of an agent missing the tool it needs to act, not a model problem.

For external tools, prefer an MCP server from Docker's MCP catalog over a

bespoke integration — it runs containerized and is reusable across agents:

yaml

  toolsets:
    - type: mcp
      ref: docker:duckduckgo

Local stdio and remote HTTP/SSE MCP servers are also supported; see references/toolsets-and-providers.md.

Use defer: true on a toolset (MCP or otherwise) to load its tools

on-demand instead of at startup, when the agent has many toolsets and startup latency matters.

Set readonly: true on an agent to restrict every toolset it uses to

read-only tools — use this for reviewer/analysis agents that must not mutate anything.

Multi-agent teams

A coordinator delegates via sub_agents: [name, ...]; listing sub-agents

automatically enables the transfer_task tool on the parent.

yaml

  # Fragment: coder and reviewer are defined separately in the full asset.
  agents:
    root:
      sub_agents: [coder, reviewer]

Use assets/team-agent.yaml for the complete runnable team, including the reviewer's readonly: true restriction. Keep that restriction when adapting the template; a filesystem toolset alone also exposes writes.

sub_agents also accepts external OCI references (myorg/agent:tag).

Pin external references to a digest (name@sha256:...) in production configs to skip the per-run registry lookup that a tag incurs.

Use transfer_task (via sub_agents) for delegation with a clean,

isolated result; use a commands: entry with an agent: field only when you want the user to become that agent for the rest of the session.

Safety and hygiene

Set redact_secrets: true on any agent that runs shell/fetch tools against

untrusted input. It scrubs recognized secret patterns from tool arguments, outgoing messages, and tool output. This is defense in depth, not a guarantee: arbitrary passwords, tokens, or customer data may go undetected.

Set max_iterations on any agent that loops autonomously (default is

unlimited) to bound cost and prevent runaway loops; max_consecutive_tool_calls (default 5) already guards against identical-call loops.

Keep credentials, tokens, and sensitive customer data out of instruction,

instruction_file, and command prompts, whether literal or interpolated. ${env.VAR} expands values into prompt text sent to the model; storing a value in an env file does not prevent this disclosure. Use interpolation only for non-sensitive context.

Supply provider credentials through docker agent setup or the provider's

supported environment variables. For custom providers, token_key: MY_API_KEY names the environment variable, not its value; do not interpolate it. Configure tool/MCP credentials through that integration's authentication mechanism, not through prompts or model-supplied tool arguments. Prompts should describe the authenticated capability without containing its secret. Do not ask the agent to read or print credential files or environment values to check authentication.

Related skills

For running the agent (docker agent run, safety modes, sandbox, aliases), use docker-agent-run.
For serving, sharing, or evaluating the agent, use docker-agent-deploy.

References

references/toolsets-and-providers.md — full built-in toolset list, MCP connection modes, and the provider/env-var table.
references/sources.md — provenance of every rule in this skill.

Assets

assets/team-agent.yaml — a runnable multi-agent team template (coordinator + coder + reviewer).

Checks

Before running an agent, follow checks/verification.md to confirm its

resolved config, exposed tools, and provider connectivity, then smoke-test it.