Adopt ACP #4645
Replies: 4 comments 4 replies
-
|
in theory I like it - when I look at ACP spec it does seem fairly large and rich, more so than first meets the eye (but that doesn't mean bad, probably means good if we do adopt it to build our own user experiences on top of). Certainly wasn't hard to implement enough for the zed "client" to use FWIW. If it isn't goose-acp doing this - then it would be our own equivalent. Q: does it need to be its own crate vs in an existing one? |
Beta Was this translation helpful? Give feedback.
-
|
Related zed-industries/zed#38219 |
Beta Was this translation helpful? Give feedback.
-
|
I think this is a good idea. It's clear even just for our own CLI and GUI we'll get a lot of value out of having a standard. ACP is exciting and agree that the reuse of MCP types is fairly critical for us as maintainers to ensure compatible (and to just make things easier to understand). I also like that as a protocol, the more widely it gets adopted the more locked in we get - we can reverse the decision if we have issues early but can build confidence as it turns into more integrations. I especially think it will be nice to have an officially supported way going forward to customize the goose interface - it should get increasingly easy to vibe code your own client. We should think about another aspect that could use a standard - config. Our current system is working alright, but each client that knows about goose may want to interact with the goose config system, and I don't see it covered in ACP at the moment |
Beta Was this translation helpful? Give feedback.
-
|
We did! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Adopt ACP
This is a proposal to adopt the Agent Client Protocol ACP (https://agentclientprotocol.com) as the primary interface to the goose agent. ACP is a new protocol primarily designed for client applications to interface with agents. It was created by the company that built the zed editor to streamline the interactions between editor and agent, but they've formally specified it to enable a wider range of client <-> agent interaction.
Why should we do this?
We adopted MCP for extending the agent's ability to interact with different systems information and tools. From this one decision flowed thousands of integrations that became possible for goose to drive value in a number of external systems. This will be similar on the other side. It will enable many more clients to drive goose.
In addition to these baseline benefits, it helps that ACP has adopted many of the types from MCP. Representing things like tool calls, notifications, content, etc do not need new types. So the same representations can flow more completely through the architecture.
Lastly, there is a compelling case to move to ACP as it's a defined standard. Right now, we have a custom interface between the
goose-clicrate for CLI interactions with the agent, and a second custom interface between the electron desktop app for goose and the agent. This means we have two custom implementations of an agent API that is shared with nothing else in the industry. We will benefit from having our agent follow a standardized protocol for additional maintainability and reach.How should we do it?
I propose we do the following:
goosecrate and seed it with a modified version of the implementation in feat: Agent Client Protocol implementation of goose #4511goose-clias a client using the agent client protocol crate (ref)ui/desktoptypescript using the ACP TypeScript library (ref)_metafields on the relevant data types (ref)Beta Was this translation helpful? Give feedback.
All reactions