goose and ACP (Agent Client Protocol) #7309
Replies: 2 comments
-
|
Looks very interesting! How stable is the |
Beta Was this translation helpful? Give feedback.
-
|
Smart move adopting ACP for protocol standardization. The dual implementation problem (in-process vs REST+SSE) is a classic technical debt issue that kills velocity and external adoption. |
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.
-
goose and ACP as its primary client protocol
We're standardizing how clients talk to goose by adopting ACP (Agent Client Protocol) (https://agentclientprotocol.com) as the primary interface for all goose clients — desktop, CLI, and beyond.
Why
Today, goose has two different client paths:
This split means every feature needs two implementations, and external clients have no stable contract to build against. As noted in our roadmap:
What is ACP?
ACP is a standardized agent client protocol built on JSON-RPC 2.0. It defines a small, clear set of methods:
initialize,session/new,session/load,session/prompt,session/cancelAgentMessageChunk,AgentThoughtChunk,ToolCall,ToolCallUpdate,request_permissionThis gives us session management, streaming responses, tool execution with permission flows, and session resumption — all over a single
POST /acpendpoint.We've implemented an Streamable HTTP (and websocket upgrade) based transport for ACP in the goose-acp crate, and we will explore putting this forward as a standard.
The plan
We're rolling this out in four phases (tracked in #6642):
What this means for you
Get involved
Beta Was this translation helpful? Give feedback.
All reactions