Replies: 5 comments 4 replies
-
|
Agree!
We have something compelling for this I think going in https://github.com/block/goose/tree/main/ui/acp. It's not documented yet but it exposes a TS SDK for goose which wraps the goose-acp server and all its functionality. It uses the standard ACP TypeScript SDK for the default things and then sends custom requests for the things that are goose specific. The TS TUI uses it but it is also in theory useful as a standalone package. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
@fresh3nough this discussion describes ACP as the future protocol of goose. goosed/goose-server has an older non-standard protocol. |
Beta Was this translation helpful? Give feedback.
-
|
sorry about that, wrong tab, moving it elsewhere. |
Beta Was this translation helpful? Give feedback.
-
|
ok @DOsinga 7720 should cover this discussion entirely as far as the three binaries being consolidated goes, as well as the missing endpoints for the CLI Left after #7720: Remove goosed & goose-acp-server crates/binaries. Can you think of anything else? or anything that needs changed |
Beta Was this translation helpful? Give feedback.
-
|
Unifying around one binary and one protocol feels directionally right. The real win is not just distribution simplicity, it is forcing every client path to exercise the same semantics, which usually flushes out hidden divergence faster than maintaining parallel surfaces. |
Beta Was this translation helpful? Give feedback.
-
|
Take a look at the code around: https://github.com/block/goose/blob/main/ui/acp We've set up support for handling ACP custom requests https://agentclientprotocol.com/protocol/extensibility#custom-requests which model the things goose does which don't map naturally into the current protocol itself. We also have a TS interface that wraps this which can used as a kind of SDK. As things become more formalized we can make RFDs to ACP for anything deemed relevant to the protocol at large.
https://github.com/block/goose/blob/main/ui/acp/src/generated/index.ts could probably serve as a basis for this |
Beta Was this translation helpful? Give feedback.
-
|
Good direction. One binary, one protocol removes a lot of unnecessary surface area. The tricky part that remains: once you have one agent core, the instruction set becomes the main variable. CLI mode wants different defaults than the editor integration, and those differences currently live scattered across context initialization code. A structured prompt format would let you define per-context profiles (role, constraints, output format as typed fields) that get loaded at startup, rather than embedding that logic in the binary. Same agent core, different instruction config per invocation mode. I've been building flompt for exactly this, a visual prompt builder that decomposes prompts into 12 semantic blocks and compiles to Claude-optimized XML. Open-source: github.com/Nyrok/flompt The consolidation you're describing at the transport layer would pair well with a structured instruction layer above it. |
Beta Was this translation helpful? Give feedback.
-
|
thats actually a really interesting idea with the transport layer, dependency injection for system prompts |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Goose Client/Server
Where we are
Goose currently ships three Rust binaries that each wrap the same core
Agentin different ways:goose(CLI) - in process agent with full lifecycle management. No server or protocol. Used in interactive mode, to run recipes and in some headless situations.goosed(server) — wraps the Agent behind a bespoke REST+SSE HTTP API with 103 endpoints. The desktop app spawnsgoosed agentas a child process. Mobile clients and Slack bots connect to it over the network.goose-acp-server— wraps the Agent behind the Agent Client Protocol (ACP), an open standard for agent communication. Powers integration with editors like Zed and the Jetbrain family. Also has a PoC TUI implementationOne binary
We should replace all this with one binary that speaks one protocol:
goose serve, exposes the same ACP interface over HTTP and WebSocket for desktop, mobile, bots, and any other client.One binary is easier to test, version & distribute. Can be installed with
brew install gooseor evencargo install. CI pipelines, containers, and embedded devices get a single static artifact. It should be runnable on a Raspberry Pi Zero, over a serial console and on any type of container.ACP as the goose protocol
ACP is an open protocol for agent-client communication built on JSON-RPC. Its core covers the basic agent lifecycle. ACP also offers custom methods that we can use to implement the rest of the goosed API. We can continue generating an API based on our rust implementation and publish it as
@gooseprotocol/sdkor some such.Any features we implement as part of this extended protocol that make sense beyond goose, we can bring to the ACP people to see if they make sense to be part of the official protocol. The main things currently not covered are around configuration, recipes, scheduling and desktop specific features (like dictation)
Goose UIs
This way we’ll end up with three categories of UIs: the basic CLI, first party UIs and community UIs.
The goose binary can be run as a basic CLI similar to what we have; the goal should be to have something that starts instantly and runs anywhere. It’s a line-oriented CLI that can adapt to do slightly better depending on the terminal that it runs in. It can borrow some ideas from the Rust TUI work, but there’s no ambition to be a full blown TUI
First Party UIs are the UIs the goose team develops. Currently this comprises the desktop and the mobile client. We should add a decent TUI (we have a prototype in typescript) and an android client for mobile.
Once we publish the SDK, community UIs become the third category. Anyone can build a frontend that talks ACP to a running goose instance. The typescript version flows from our current way of working and we should also publish a Python equivalent. Any published package could even be launched directly from goose.
MCP proved the model: an open protocol for tool integration let the community build hundreds of extensions. ACP does the same for the client side.
Beta Was this translation helpful? Give feedback.
All reactions