Q4 Road Map

[DOsinga]

🪿 Goose/GDK Roadmap 2026 Q4

In Q3, we started separating goose into reusable provider and agent crates. In Q4, we will turn those pieces into a working developer kit and make goose its first complete user.

The main deliverable for the quarter is a supported GDK release, proven by shipping a version of goose that contains minimal agent implementation of its own.

🧰 A working GDK

The GDK will contain the parts needed to build a useful agent without depending on the goose application crate:

• Providers and model configuration
• The unrolled agent loop
• Tool execution and approval
• Developer tools
• Compaction and context management
• Skills and subagents
• Steering and cancellation
• MCP client support
• An ACP server interface

These components should be independently usable and easy to assemble. Developers will be able to replace tools, policies, or individual agent operations without forking goose.

Rust will remain the most complete GDK surface. Python and Kotlin support will grow around concrete use cases, with the differences between the language APIs documented clearly.

🪿 goose, built with the GDK

We'll prove the GDK by using it to build goose.

We'll ship an ACP-capable version of goose whose agent behavior comes from public GDK crates. The application should mainly handle configuration, command-line interaction, and packaging. Capabilities needed by goose should not remain hidden in the application when they are useful to other GDK users.

This gives us a simple test for every boundary: could another developer build the same thing using the published GDK? If not, the GDK is not finished.

🧭 Open protocols

The GDK will provide the protocol support needed to build interoperable agents and clients.

Goose will continue exposing agents over ACP, while MCP support will remain current through the underlying Rust SDK. This includes the official Tasks and Skills extensions and preparation for Events as that work stabilizes.

Protocol support should live in reusable crates rather than being implemented only inside a goose client.

📦 A release developers can use

The quarter is complete when developers can install the GDK, follow a short example, and build an agent with it.

We'll publish:

• Versioned GDK crates and language packagesa
• API documentation with clear stability and maturity guidance
• Small examples for building an agent, adding a custom operation, and exposing it over ACP
• End-to-end tests covering tools, compaction, subagents, cancellation, and ACP
• A version of Goose built primarily from those published components

"Working GDK" should mean a coherent release with documentation and integration coverage, not only that the code has been moved into separate crates.

[joostjager]

This gives us a simple test for every boundary: could another developer build the same thing using the published GDK? If not, the GDK is not finished.

The quarter is complete when developers can install the GDK, follow a short example, and build an agent with it.

I think it would help to define the scope a bit more concretely. Both tests leave some room for interpretation, since developers could fill in missing functionality themselves, and the example could be quite minimal.