Harness architecture
Docker Agent and UHP
Docker Agent is an open-source Docker CLI agent runtime with multi-agent orchestration, native MCP/A2A/ACP interoperability surfaces and a coding-harness mode for Claude Code, Codex, OpenCode and Pi. Reviewed primary sources do not establish native UHP adoption, HarnessRouter backend support or UHP conformance evidence.
Status first
Section titled “Status first”Docker Agent is a distinct agent runtime and orchestration layer, not a UHP implementation. Docker describes it as a Docker CLI plugin for defining agents in declarative YAML, running multi-agent teams, attaching tools and models, and packaging agents through OCI registries.
The latest observed stable release is v1.136.0, published 8 September 2026 at 11:08:00 UTC. Checked upstream main is 31c21a188c0677c2cb8115313760993111b078e7 at this cutoff. The stable release moves encrypted agent configuration from a request header into the request body/config-load envelope to avoid header-size constraints; that is a Docker Agent transport/runtime change rather than an interoperability-protocol version.
Why Docker Agent matters to harness interoperability
Section titled “Why Docker Agent matters to harness interoperability”Docker Agent is unusually relevant because the same runtime exposes several neighboring boundaries at once:
- agent runtime: models, tools, memory, RAG, hooks, permissions and multi-agent delegation;
- coding harness orchestration: external Claude Code, Codex, OpenCode or Pi CLIs can act as harness-backed subagents;
- MCP server: agents can be exposed as MCP tools over stdio or streaming HTTP;
- A2A server and client/tool path: agents can be exposed over A2A and can call remote A2A agents;
- ACP server: a Docker Agent can be embedded by an ACP host over stdio;
- distribution: declarative agent configurations can be pushed to and loaded from OCI registries.
That makes Docker Agent a useful case study in why protocol labels need precise directionality. A single product can be an MCP server, an A2A participant, an ACP agent process and a host for other coding harnesses without implementing UHP.
Coding harnesses inside Docker Agent
Section titled “Coding harnesses inside Docker Agent”Docker Agent’s stable coding-harness feature delegates an agent’s work to an external coding CLI instead of directly calling a model API. Stable v1.136.0 documents four harness types:
| Docker Agent harness type | External runtime | Boundary |
|---|---|---|
claude-code | claude | Docker Agent orchestrates; Claude Code owns its coding loop and authentication. |
codex | codex | Docker Agent delegates the subagent turn to Codex. |
opencode | opencode | OpenCode owns the external coding loop. |
pi | pi | Pi is launched as the external coding harness. |
The external CLI manages its own model selection and tools. Docker Agent’s ordinary toolsets: are not injected into a harness-backed agent, and Docker Agent’s model-routing pipeline does not control the harness CLI’s model path. Hooks still wrap the delegated run, so Docker Agent retains orchestration/audit policy around a loop it does not itself execute.
This architecture is adjacent to HarnessRouter but materially different. HarnessRouter presents supported harnesses behind a UHP server. Docker Agent instead composes coding CLIs as subagents inside its own orchestration system. Reviewed sources do not establish a HarnessRouter adapter for Docker Agent or a Docker Agent UHP endpoint.
Permission boundary
Section titled “Permission boundary”Docker’s stable harness documentation includes an important operational warning for Claude Code: Docker Agent invokes the CLI non-interactively with --dangerously-skip-permissions. Docker recommends trusted repositories and isolation such as an isolated git worktree. Docker Agent also states that run --sandbox does not automatically make the external CLI or its login available inside the sandbox.
That distinction matters when comparing harnesses: orchestration, approval policy and sandbox placement are implementation concerns unless a protocol explicitly standardizes them.
MCP: expose agents as tools
Section titled “MCP: expose agents as tools”docker agent serve mcp exposes Docker Agent agents as MCP tools. Stable documentation supports stdio by default and streaming HTTP with --http.
For HTTP, Docker Agent documents the MCP 2026-07-28 stateless model: modern clients use server/discover, no Mcp-Session-Id is issued, and the HTTP server accepts POST while standalone GET/DELETE session behavior is not provided. Older initialize clients remain supported through a compatibility path, but older stateful clients relying on GET streams or session DELETE teardown need to upgrade or switch to a compatible transport.
Non-loopback HTTP requires a bearer token unless the operator explicitly selects the insecure override. This is a Docker Agent security control around its MCP server; it is not part of UHP conformance.
A2A: expose agents to other agents
Section titled “A2A: expose agents to other agents”docker agent serve a2a exposes a configured agent over the Agent2Agent protocol. Stable v1.136.0 calls this support early and documents limitations: tool calls remain internal rather than becoming separate A2A events, artifacts and memory are not yet integrated, and multi-agent/subagent scenarios still need further work.
The stable server defaults to loopback. Non-loopback listeners require --auth-token unless --insecure-no-auth explicitly acknowledges the exposure. Tool safety defaults to restricted; an autonomous safety policy requires an explicit CLI opt-in.
Docker Agent also has an A2A toolset for connecting to remote A2A agents. That is separate from exposing the local Docker Agent as an A2A server.
ACP: embed Docker Agent in a host
Section titled “ACP: embed Docker Agent in a host”docker agent serve acp starts an Agent Client Protocol server over stdio for hosts such as editors or developer tools. Stable documentation says sessions are persisted in SQLite so they can survive process restarts.
The ACP surface supports configured Docker Agent tools, multi-agent delegation and model fallbacks, but the stable documentation explicitly says client-supplied MCP servers are not supported through the ACP session boundary. Persisted sessions use session/resume, not session/load.
Docker’s own documentation summarizes the intended separation well: ACP connects a host application to an agent process, A2A connects agents over the network, and MCP exposes agents as tools. UHP is a fourth boundary: client → UHP server → configured harness. Similar words such as session, tool or agent should not be assumed to have identical semantics across them.
Protocol-direction map
Section titled “Protocol-direction map”| Layer | Verified Docker Agent relationship | UHP relationship |
|---|---|---|
| Docker Agent runtime | Native multi-agent runtime/orchestrator with YAML, tools, models, hooks and OCI distribution. | Adjacent harness/runtime architecture. |
| Coding harnesses | Native delegation to Claude Code, Codex, OpenCode and Pi. | Not a UHP adapter; external CLIs remain their own runtimes. |
| MCP | Native server mode exposes Docker Agent agents as tools; Docker Agent can also consume MCP toolsets. | Separate tool/context interoperability boundary. |
| A2A | Native server plus remote-agent tool path; stable support marked early. | Separate agent-to-agent boundary. |
| ACP | Native stdio server for host/editor embedding. | Separate client/editor-to-agent boundary. |
| UHP | Not established in reviewed Docker Agent sources. | No native adoption or conformance evidence. |
| HarnessRouter | Docker Agent is not in the released ten-backend set at this cutoff. | No released adapter evidence. |
v1.136.0 release boundary
Section titled “v1.136.0 release boundary”The latest observed stable release, v1.136.0, changes how encrypted agent configuration is carried: the encrypted config moves from the X-Cagent-Encrypted-Config header into the request body and config-load envelope. Docker states that the reason is to avoid request-header size limits.
This is relevant to agent-runtime transport design but does not change MCP, A2A, ACP or UHP protocol versions. It should not be generalized into a new cross-project interoperability contract.
Evidence boundaries
Section titled “Evidence boundaries”- Observed Docker Agent stable:
v1.136.0, published 8 Sep 2026 at 11:08:00 UTC. - Checked upstream
main:31c21a188c0677c2cb8115313760993111b078e7. - Native coding harnesses: Claude Code, Codex, OpenCode and Pi in stable
v1.136.0documentation. - Native MCP: server mode plus MCP tool consumption is established by Docker Agent primary documentation.
- Native A2A: server and remote-agent tool surfaces are established; stable docs label support early and list limitations.
- Native ACP: stdio server mode is established by stable documentation.
- Native UHP: not established.
- HarnessRouter backend support: not present in
v0.15.7’s released ten-backend set. - UHP conformance evidence: none attributed to Docker Agent.
Related pages
Section titled “Related pages”Read harness composition for subagent/runtime topology, UHP vs MCP for tool interoperability, UHP vs A2A for agent-to-agent boundaries, UHP vs ACP for host-to-agent integration, TrueForge for another complete agent runtime, and ecosystem for adoption classifications.