Extensions

[alexhancock]

Extensions

We have some things I think we should clean up with extensions in goose.

1. Builtins vs Platform

We maintain two ways of having extensions which are automatically included in goose.

• Platform extensions - part of the goose crate, run in-process, use an MCP like approach to tool-calling but also have privileged access directly to internal goose APIs as well
• Builtin extensions - part of the goose-mcp crate, run in a separate process and goose communicates with them as MCP servers over the stdio transport

I propose we merge these concepts. @jamadeo has started some work making them look the same in the config file (#7630). We should use the platform extension approach, and migrate all the goose-mcp extensions to the platform extension architecture. The main reason to have something built into goose should be tight integration to goose and the platform extension concept enables this better. Things that are just MCP servers (useful in other agents as well) can be included in a goose distribution via the "bundling process" referenced below, but need-not be in a crate in goose.

2. Apply the unix philosophy

Right now we group certain things into shared extensions (for example the summon extension does skills, recipes, and subagents). I propose we make extensions follow the unix philosophy of "doing one thing, and doing it well". In the case of summon, skills should be an extension, recipes should be an extension, subagents should be an extension, etc. This will make them all simpler and more composable. As an example, subagents would become a very small extension with a tool which enables a recursive goose and that's it.

3. Bundling process

We maintain a concept of "bundled" extensions which are normal MCP extensions sourced from a JSON file at build time, and automatically included in a distribution of goose. We should update this flow to make sure it works well with the new approach to "builtin" extensions going away. The end result should be extensions that look exactly the same as normal MCP extensions but perhaps have a field disallowing them from being removed/having their config modified through the UI (for corporate distributions that want to provide stable config for bundled extensions

4. New defaults

After this process we can make a decision on what should be enabled by default from

• Developer
• Computer Controller
• Todo
• Apps
• Autovisualizer
• Skills
• Extension Manager
• Subagents
• Recipes

[DOsinga]

I think recipes are too tightly coupled currently to move them out as an extension - it has its own ui, cli flags etc, so unless you'd imagine that would go away if you dissable the extension, I don't know that works.

SImilarly, I think skills are so central these days to agentic flows that having them as an extension that you can switch off, seems wrong. I'd rather have a section in the UI for it.

[alexhancock]

Makes sense about recipes - I only included them because I thought (seems incorrectly) that management/usage was already refactored into the summon extension. Leaving them as part of native goose seems fine.

I also agree we can drop the idea of skills as an extension and just move the implementation into goose.

Rest of plan remains. Does it sound good?

[jamadeo]

We could make it such that (some) platform extensions don't appear on the usual extension management page, and are instead toggled in their own dedicated part of the UI, which also enables/disables the rest of the associated UI elements