docs: Add ACP integration design for pluggable agent support#52
Conversation
Devaipod is currently hardwired to OpenCode with ~40+ coupling points across the codebase. This makes it impossible to use Claude Code, Goose, or another agent as the primary agent without OpenCode in the loop. This TODO proposes adopting the Agent Client Protocol (ACP) as the communication layer between pod-api and agents, enabling any ACP-compatible agent to be used as the primary agent. Devaipod's frontend would own tool permission UX (with YOLO as default), while agent harnesses run with internal permissions fully auto-approved. The Containerfile would be factored into a base image and per-harness extension Containerfiles so users can extend for proprietary agents. Also covers interaction with multi-repo (cgwalters#15), sidecar profiles (cgwalters#17), worktree mode (workspace-v2), the LLM credential proxy, and the MCP integration strategy (per-agent config now, MCP-over-ACP later). Assisted-by: Claude Code (Opus 4.6) Signed-off-by: arewm <arewm@users.noreply.github.com>
|
At a very quick skim this looks sane! however - I have a huge PR I'm queuing up for a complete rework of the workspace flow...let's try to get that in first, I'll post soon |
|
Yeah, I saw your working branch for that. I have kicked off an attempt at an implementation for this already because I wanted to see what it would look like. I'll hold off on submitting a PR until yours is done and I'll ingest your changes. |
| │ OR devaipod-agent-goose │ goose binary + auto-approve config | ||
| │ OR user's custom agent image │ | ||
| ├──────────────────────────────────────────┤ | ||
| │ devaipod-base │ pod-api, ACP client, git, scripts |
There was a problem hiding this comment.
No, the user's container should be wholly separate, there's no "devaipod-base".
This is very intentional, trying to avoid polluting or imposing requirements on the user's workload containers.
There was a problem hiding this comment.
The case that I was thinking about here is when there is no suitable devcontainer in the repository which a user is working. Either there is no devcontainer or if the devcontainer doesn't have the appropriate agentic requirements met. I think that the issue here is that I haven't been doing the right thing in this situation as I have been building the devaipod container and using that local one instead of using the one from my dotfiles repo as an override.
So to handle the cause that I was thinking about properly here, a user might just need to have multiple custom devcontainers which they can swap out as needed. Either that, or a user would just have their default devcontainer with the appropriate agent harness and then just let the agent install any tools that are needed to accomplish its job.
There was a problem hiding this comment.
Yeah, it is tempting to follow the pattern that OpenShell, ACP and various others are doing in having a pre-built container image with agents preloaded.
We could even just reuse OpenShell's I think (though I dislike how it rolls in proprietary software by default, probably worth arguing there to split it).
I think that the issue here is that I haven't been doing the right thing in this situation as I have been building the devaipod container and using that local one instead of using the one from my dotfiles repo as an override.
Yeah, what I'm thinking here is we could just error out if the config doesn't have a container more clearly. Hmm, I think I rolled a change for that into workspace v2.
Again though my thoughts on the current design is that exactly what is in your agent container is very important and people looking for tools need to make decisions on in most nontrivial cases - so while it's a bit painful to force that upfront for some, I way prefer it to the simple fact that e.g. ACP doesn't support configuring it at all, and OpenHands it's awkward and annoying, etc.
|
This is implemented in #57 . Do we need this PR still for completeness or can we just depend on the documentation of the ACP integration? |
2 participants
Devaipod is currently hardwired to OpenCode with ~40+ coupling points across the codebase. This makes it impossible to use Claude Code, Goose, or another agent as the primary agent without OpenCode in the loop.
This TODO proposes adopting the Agent Client Protocol (ACP) as the communication layer between pod-api and agents, enabling any ACP-compatible agent to be used as the primary agent. Devaipod's frontend would own tool permission UX (with YOLO as default), while agent harnesses run with internal permissions fully auto-approved. The Containerfile would be factored into a base image and per-harness extension Containerfiles so users can extend for proprietary agents.
Also covers interaction with multi-repo (#15), sidecar profiles (#17), worktree mode (workspace-v2), the LLM credential proxy, and the MCP integration strategy (per-agent config now, MCP-over-ACP later).
Assisted-by: Claude Code (Opus 4.6)