Extending Goose: Making the GRC More Modular #10092
Replies: 1 comment 5 replies
|
as mentioned by @i386 https://github.com/thesysdev/openui may be relevant for this too. Biggest question for me is if the GRC is the place to have extensible UI (being sort of a reference, or exemplar) or some other client which is more opinionated for end users? |
|
I think that could be the case, I believe GRC will be the client most people use for day-to-day usage or are we also planning to release another client that's more focused on end users? My thought around GRC is that people will likely want to extend it or build solutions on top of it. I'm not sure about enterprise if we are able to achieve the same features with this or not, but I imagine most users may can have the functionality they need and will mainly want to customize it while still receiving upstream updates. That said, we can definitely discuss this more if we're thinking about a separate, more opinionated client specifically for end users if we are thinking in that direction that it might be better use case for that ? |
|
if it is GRC then yeah - it would be a nice "release valve" to let people drop in extensions/assemble things. will definitely talk about this more. It probably is the right place... |
|
Yeah, in GRC I built a prototype around it, and it mostly follows the direction that you mentioned in the doc. It can do UI extensions and stuff, and most things around that. But I'm thinking if it can have the capability of supporting full add-on features and not just UI maybe ? For example, we had Mesh LLM in GRC, so if we could have an add-on for it, for people who want to use mesh LLM they can install it and use it,I thought about it, but I think it would need access to some Goose internals, If we can access those, that it might work out |
|
How are you thinking about letting extensions reuse the goose UI components in those extensions? would you provide a shadcn theme? |
|
I haven't thought about it, but yeah, I think just like extension points, we might can think of a schema, as you said. Maybe that would let those extensions use or interact with the Goose UI and maybe can solve those access problems too. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
While working on #9341 and discussing it with @michaelneale, @lifeizhou-ap and others, I started thinking more about the long-term direction of the Goose reference client.
One thing that became clear is that we probably don't want every new feature, UI component, or integration to live directly inside the reference client. As Goose grows, there will be many different use cases, organizations, and products built on top of it, all with different requirements. Trying to support every workflow in core would eventually make the reference client increasingly complex.
That made me wonder whether the reference client should instead provide a modular extension system, where developers can extend the UI and functionality through plugins rather than maintaining entirely separate clients.
The Idea
The reference client (GRC) would remain a lightweight foundation, exposing well-defined extension points that plugins can hook into.
Rather than modifying the application itself, plugins/integrations/extensions could extend the experience by contributing things like:
The goal wouldn't be to replace existing functionality, but to augment it.
This feels similar to how many successful platforms expose extension points while keeping the core application small and stable.
Why This Seems Valuable considering other aspects
One motivation came from thinking about integrations.
Many integrations (Gmail, Google Calendar, Slack, GitHub, Linear, Notion, internal tools, etc.) require much more than simply exposing an MCP or calling an API.
They often need things like:
An MCP can provide the capability, but it doesn't solve the product experience around authentication, configuration, and user interaction.
Without a shared extension model, each serious integration may eventually need to build its own setup flow or mini-client.
A plugin architecture could instead allow Goose Desktop (or another reference client) to become the common configuration and control surface, while the plugin provides the actual functionality.
Plugin Distribution
If plugins become first-class, it would also be nice if they could be distributed independently of Goose releases.
Similar to Recipes and Extensions today, we could eventually have a plugin catalog where users can discover and install functionality as needed.
Organizations could also maintain their own internal plugins without needing to fork or modify the reference client.
Design Goals
Some properties that feel important:
@michaelneale shared a more detailed design document covering this idea, including potential extension points, their expected behavior, and how it could work in practice: https://docs.google.com/document/d/1aU9J30fPuroPVihGd5fo-N1z5qUvt2GDSpNszJFMk-4/edit?pli=1&tab=t.0
Longer-Term Thought
One aspect that feels especially interesting in an agent-first ecosystem is plugin development itself.
Rather than writing extensions entirely by hand, Goose could understand its own extension API, explain available extension points, and even help generate or iterate on plugins through conversation.
That feels like a natural direction for an AI-native platform.
Open Questions
I'm mostly curious whether this aligns with the team's vision.
I'd love to hear everyone's thoughts.
Related Context
Previous discussions :
Initial design proposal (link) by @michaelneale
All reactions