Hi everyone,
I’m currently developing an ACP Client and ran into a UX issue.
Many users get confused after they have already installed tools like Claude Code or Codex, because they still need to install an additional ACP adapter separately.
From my understanding, the root cause is that these agents do not provide native ACP support themselves, so the community provides adapters to bridge the gap.
I’ve been thinking about whether it makes sense to add a field in the schema to explicitly mark an ACP agent as an “adapter”. With that information, clients could:
- adjust the UI presentation,
- better explain the relationship to users,
- or distinguish native ACP agents from compatibility adapters.
I’m not sure this is the best approach, so I’d like to hear how others in the community are handling this problem today, especially from a UX and ecosystem design perspective.
Hi everyone,
I’m currently developing an ACP Client and ran into a UX issue.
Many users get confused after they have already installed tools like Claude Code or Codex, because they still need to install an additional ACP adapter separately.
From my understanding, the root cause is that these agents do not provide native ACP support themselves, so the community provides adapters to bridge the gap.
I’ve been thinking about whether it makes sense to add a field in the schema to explicitly mark an ACP agent as an “adapter”. With that information, clients could:
I’m not sure this is the best approach, so I’d like to hear how others in the community are handling this problem today, especially from a UX and ecosystem design perspective.