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
dockersubcommand 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
pluginrarely 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
sbxCLI 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.