According to Opus, ACP is designed specifically for IDE clients (with coding agent “servers”), and there’s some impedance mismatch here that would need to be resolved for one agent cli to operate as a client. I havent validated this though.
—-
1. ACP Servers Expect IDE-like Clients
The ACP server interface in Claude Code is designed for:
∙ Receiving file context from an IDE
∙ Sending back edits, diagnostics, suggestions
∙ Managing a workspace-scoped session
It’s not designed for another autonomous agent to connect and say “go solve this problem for me.”
2. No Delegation/Orchestration Semantics in ACP
ACP (at least the current spec) handles:
∙ Code completions
∙ Chat interactions scoped to a workspace
∙ Tool invocations
It doesn’t have primitives for:
∙ “Here’s a task, go figure it out autonomously”
∙ Spawning sub-agents
∙ Returning when a multi-step task completes
3. Session & Context Ownership
Both tools assume they own the agentic loop. If OpenCode connects to Claude Code via ACP, who’s driving? You’d have two agents both trying to:
∙ Decide what tool to call next
∙ Maintain conversation state
∙ Handle user approval flows
