Goose the SDK - and some future directions (not a roadmap!)

[michaelneale]

Since goose launched 2024/early 2025 so much has happened in the harness space there is so much choice now, much open source (much sadly not).

There is a focus now on making goose a first class dev kit (SDK). There are tons of high value moving parts which so many apps and harnesses could reuse, and we want to make these easy to consume in any way you need.

For example, there is a stable of heavily maintained provider integrations for pretty much every provider, built in local inference and optimisations for open weight models (and forward looking enhancements like MeshLLM to let people pool their compute for their own private LLMs).

Also a ton of utility in libraries and code to deal with real world networks and operating system quirks and a lively community ready to build with you. Goose also works hard maintaining MCP, Skills, ACP and other emerging standards support for max interoperability (not yet a2a - but would love to have that too!). You should easily be able to remix goose into an app that suits you.

So what this means:

Goose SDK (probably known as GDK) will be first a class suite of libraries you can use from any of the following
Swift
Kotlin/Java
Rust
js/ts (soon)
Python
…

• Goose is still written in rust at its core, and that won’t change, bindings to native languages and deployments to all the places you find artifacts for your languages will exist
• Goose can be pulled in as a dependency (and can be slimmed down as needed) so it is packaged however you like
  ACP(+) is still first class, so running goose as a process/app/server and then layering on front ends to ACP will always be first class supported (the SDKs for language bindings give you lower level access if you need it)
• Goose will be able to be “unrolled” as an agent, run inside your servers (ie say you want to embed it in some scaled service - you will be able to use an external task runner like temporal to take care of that, bring your own database, not use sqlite, not need to run an external process etc).
• There will be a first class reference client(s): goose reference client (code name GRC?) - the desktop as you know it, which sits on top of ACP (potentially: mobile app clients using ACP). This app aims to be a “powertool” - this means you can use it as a “daily driver” but it will favour helping you get insight into what the agent is doing, perhaps by default. The hope is this gives people control over their agents, visibility into what the LLM is doing and so on.
• Goose will still have a cli/tui which sits on top of ACP for out of the box usage and command line extension purposes as today
• Goose is still an app, and a cli of course! It is just built on top of these primitives more as an exemplar of them, vs the app existing purely for its own sake (or cli), this is the direction shift (subtle!)

So in some ways it is a deconstruction and reconstruction so it can be used in many different ways, as the situation requires, without bringing along everything. For other users, maybe you won’t notice much change at first, but this is where things are heading at the moment.

Success will look like SDKs that are used in all sorts of surprising places, people packaging up their own bespoke agent on top of the Goose SDK, making their own distributions of things for their own specific needs, on top of open standards as they develop and emerge.