Goose merged an optional, stripped-down agent binary on September 23. The reason is unusually concrete: an application should be able to bundle Goose without carrying features it does not need. In aaif-goose/goose PR #11961, that becomes a small executable called goose-acp.
The attractive first reading is a download-size story. The more consequential part is the compatibility boundary. Reviewers found that removing optional features could also remove familiar commands from the full portable build, and that an old recipe could ask the lean agent for an extension it no longer contains. The first problem was repaired. The second was explicitly accepted.
The application behind the smaller binary
In Buzz’s open bundling proposal, Jack Amadeo describes replacing the built-in buzz-agent with Goose as the default packaged agent. The issue says Buzz already supports Goose through its agent-agnostic harness. The remaining work is packaging and product compatibility, not inventing another way for an application to talk to an agent.
ACP, the Agent Client Protocol, supplies that conversation boundary. The new executable starts Goose’s ACP server over standard input and output, so a host application can launch it as a child process and exchange protocol messages. The entry point handles a small set of arguments and starts the server with scheduling disabled.
The merged build configuration makes syntax parsers, scheduling, app and chat-recall extensions, bundled MCP servers and ACP’s HTTP transport optional. External MCP support and the in-process developer extension remain part of the lean design. This is still an agent with tools and persistent sessions, but it is no longer the entire command-line product squeezed into another application.
Size is now a maintained constraint. The build recipe sets default ceilings of 17 MiB on macOS and 22 MiB elsewhere, with a Linux continuous-integration job running the check. Those are failure thresholds, not our measured download sizes or a promise about startup speed.
Two compatibility problems, two different answers
A Codex review comment caught a release trap: the portable CLI is built with default features disabled. Unless its explicit feature list was expanded, the new gates would silently remove its MCP, schedule and serve commands. The merged portable preset now includes those capabilities. Making a new small product should not accidentally shrink the old one.
The recipe case received a different answer. Goose’s compatibility code automatically adds an analyze extension when it reads an older recipe that declares the built-in developer extension. But the lean build omits the syntax-parsing feature that registers analyze. The review traced that combination to an extension-load failure; Amadeo’s reply accepted failure as the appropriate behavior when platform tools change.
The source supports that narrow warning: the recipe parser still injects analyze, while registration is conditional. It does not show that every recipe fails, or that the ordinary Goose CLI has lost the extension. We inspected the code and review; we did not build the binary or reproduce the recipe failure.
A smaller package leaves a migration decision
Buzz’s issue remains open. It asks whether to build Goose from a pinned source revision or download published lean binaries, how to translate existing agent settings, and whether both runtimes should coexist during a transition. A merged Goose option therefore does not establish that Buzz users have already been switched.
For an application team, the acceptance test now has two parts: can the package be shipped at the desired size, and can the configurations users bring with them still load? Pinning a revision and a feature list makes the first reproducible. Trying representative old recipes—and explaining deliberate rejections—makes the second visible.
The next meaningful signal is Buzz’s migration policy, backed by the artifact it actually bundles. A small agent is easier to distribute. The application still owes its users an answer about what comes with it.