Context/Motivation

What if we change CLI and GUI as ACP clients to interact with all these agents based on the Agent-Client Protocol (https://agentclientprotocol.com/protocol/overview)?

In that case, we can possibly re-use Claude-Code (https://github.com/zed-industries/claude-code-acp), the Gemini CLI ACP that Zed already implemented, and launch these different agents inside our sandbox and treat them as an agent there 🤔

This should allow us to leverage the ACP ecosystem and position OpenHands as a model-agnostic agent platform (e.g., you can even use your Claude-code subscription / Codex / Gemini CLI subscription with OpenHands via ACP) — and all these agents are using OpenHands as a unified interface.

This will actually allow us to directly integrate Claude-code/Gemini CLI into OpenHands & allowing users to utilize their Claude-code/Gemini CLI subscription via OpenHands.

Challenge: How do we make microagents, etc., work there? It will be a bit tricky unless we integrate the Agent-Client Protocol more deeply into the SDK.

Approach

One thing we can potentially do would be to create an ACPAgent that inherits from AgentBase -- we input the same stuff to the agent, but internally inside the agent, we implement the "agent" as an ACP Client & have Claude-Code/Gemini being an ACP Server.

Because we manage stuff like microagents at the conversation-state-level, we can make them work by assemble inputs to these different ACP servers

It is ok that we don't yet support most of the stuff within SDK - as long as we throw errors when user tries to set them.