Docker Agent

Docker’s new “Docker Agent” project aims to orchestrate AI agents and sandboxes using YAML configs and Go, but many engineers question why a container company is chasing the crowded “agent harness” trend and wiring it into the `docker` CLI. Commenters highlight gaps around security, sandboxing details, plugin/extensibility in Go, and real-world robustness, with some reporting brittle behavior when integrating with popular coding agents. More broadly, the thread reflects fatigue with proliferating agent frameworks, unclear differentiation among competing sandbox/orchestration tools, and skepticism about whether such systems meaningfully improve workflows beyond what existing LLMs and simpler tooling already provide.

Role and Positioning of Docker Agent

  • Seen as an “agent harness” / orchestration framework rather than core container tech.
  • Originally conceived as “compose for agents” using YAML; now also supports HCL and Go APIs.
  • Some find it confusing or off-mission that it’s a docker subcommand when it’s not directly about containers.

Agent Harness Ecosystem & Language Choices

  • Many note a proliferation of agent frameworks, likening them to past JS framework explosions.
  • TypeScript ecosystems are praised for plugin ergonomics but critiqued for security; Go is seen as weaker for plugins (Go plugin rarely used in practice).
  • Alternatives suggested: IPC, HTTP APIs, or embedded interpreters (Lua/JS) for extensibility.
  • Debate over language “correctness”: some extreme claims that only C++/Rust are justifiable; others push back and say LLMs change the tradeoffs.

Sandboxing and Security

  • Confusion that Docker’s AI story isn’t centered more clearly on sandboxing and attack surfaces.
  • Docker Agent can run inside “Docker Sandboxes” (VM-based) or more traditional container setups.
  • Separate sbx CLI praised for sandboxing agents and providing “sentinel value” handling of secrets.
  • Some want richer ACLs around commands, credentials, and network scopes.

Usability, Maturity, and Reliability

  • Mixed experiences: some find the tool helpful; others report brittleness, especially with Codex integration and long responses (>10k chars).
  • Lack of ACP-based integration in certain paths is called out as a design weakness.
  • Documentation and positioning described as “vague”; “no code required” messaging is questioned given that YAML is effectively programming.

Overlap with Other Tools and Use Cases

  • Confusion over how Docker Agent differs from other agent sandboxes (Kubernetes, Cloudflare, LangChain, etc.); sense that “everyone is building the same thing.”
  • Some see potential for reproducible ML/agent research, but note existing tools (e.g., uv, specialized research envs) already cover much of that.

Broader Attitudes and Hype

  • Skepticism that Docker is chasing AI trends to stay relevant rather than focusing on core strengths.
  • Frustration with growing YAML/config sprawl and “enshittification by AI.”
  • Concern that AI-written docs erode trust, but resignation that this is now the default.