Adopt ACP

[alexhancock]

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-cli crate 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:

• Add acp support to the goose crate and seed it with a modified version of the implementation in feat: Agent Client Protocol implementation of goose #4511
• Connect to this in goose-cli as a client using the agent client protocol crate (ref)
• Connect to this in the ui/desktop typescript using the ACP TypeScript library (ref)
• Send all core interactions for the conversation that can be handled by ACP via the protocol.
• Send all other interactions which are not naturally covered by ACP (adding and managing extensions, saving configuration values, etc) via ACP's custom requests feature
• Represent all data fields which are not naturally covered by ACP as _meta fields on the relevant data types (ref)

[michaelneale]

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?

[alexhancock]

My first instinct was another crate to keep some definition of an agent interface that's divorced from acp - I suppose mainly as a hedge to be able to move to something else if the landscape shifts again. But that does leave the interface between goose-acp and goose rather poorly defined and custom which is part of our current problem. We could consider having the goose crate speak acp and expose the agent directly from that crate. Is that better in your view?

[DOsinga]

FWIW I don't know that this worth an extra crate or what that really would get us. until we publish the API for third parties we can make changes as much as we want

[alexhancock]

Sounds good. I'll plan to bake the ACP interface into the goose crate itself.

[alexhancock]

Related zed-industries/zed#38219

[baxen]

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

[alexhancock]

Thanks @baxen

And yes I agree on config. Something I'm thinking: use https://agentclientprotocol.com/protocol/extensibility#custom-requests for the config and other things ACP doesn't support and codify the custom requests we make into some sort of type system. This way we can see if anything makes sense as an expansion of ACP itself (storing config values/secrets, enabling extensions, changing models, etc)

[alexhancock]

We did!