draft: 2026 (beginning) roadmap

[michaelneale]

Wanted to start a draft of a roadmap (thought here was as good as anywhere) - not actual roadmap yet, just add your thoughts:

Mine: first class ACP support, focus on desktop (and other visual clients) to make goose appealing for "power users", grow goose into a meta agent (managing sessions, workflows, recipes) but can embrace any and all agents (ACP), a goose SDK (for those that want to embed things), MCP apps

[blackgirlbytes]

oh i love this idea for growing goose into a meta agent +1 for this

[DOsinga]

I would love to work more on MCP Apps and turn them into full blown apps that can live outside a conversation, have access to the LLM to do clever things, that can be coded up by goose itself and shared & remixed. if you build an AI app to practice German, I should be able to take it and modify it so it can help me speak Spanish with a focus on say programming.

[justyn]

Does the roadmap include moving clients to a common goose-server backend as discussed in eg #5958 and elsewhere (and perhaps leading to #5560 )

[DOsinga]

it does now! and yeah this is something we do want to work on /cc @baxen

[baxen]

+1! we're actually doing this imminently, just figuring out how much on ACP

[upe]

First off, THANK YOU to everyone who develops and maintains Goose. As a mostly non-developer, I've been using Goose as a power-user multi-model LLM client where I can set up structured, automated workflows to generate sets of dependent documents. So my wish list is with that in mind. (Though I realize this may not be the main use case for Goose, which is geared toward development. But, can't hurt to share...)

Chat Power User Features (Note: I come from using TypingMind, which is great at a lot of the chat UI elements):

• Change models with fewer clicks (i.e, click on the model name, see a scrolling list of favorites or recently used models.)
• Being able to edit the agent's response in the chat directly
• Removing/hiding messages from the chat context
• A more straightforward way to start a new chat and switch between active chat threads
• A denser chat history manager (folders, easier way to delete chats, etc.)
• Adding or removing extensions from a chat in fewer clicks
• Canvas editing of messages in a chat (with formatting), and a download as markdown button
• Mutli-model responses
• A "regenerate" button

[spencrmartin]

Big +1 to chat history manager - generally think that space needs some love. Would also like to double click on that space too! Thanks @upe

[upe]

Awesome! Re: the chat history manager—so I've played with many of the multi-model LLM clients (OpenWebUI, AnythingLLM, MSTY, etc)—my favorite for chat history management so far is TypingMind. Their documentation has a good show and tell: https://docs.typingmind.com/chat-management/organize-chats.

One secret power is that you can organize chats into folders, and those folders can have a bunch of settings (assign agents / tools, training files, dynamic endpoints, etc.) so they double as workspaces you can come back to: https://docs.typingmind.com/chat-management/project-folders

All that said, it's still not perfect. My list of chat folders and chats is insanely long. I wonder if the right solution is to be more gmail like... much as gmail moved away from inbox's of old and ftheir older-first organization, moving to lightning quick search + tags/labels. (Though I'd still have a need for "workspaces").

Hope that is useful!

[upe]

@michaelneale great! Thank you for that. Give me a beat and I'll do a quick screen recording to show what I mean.

[maniksurtani]

Love the idea for 'workspaces', especially if they can be shared/collaborated on. I use equivalents on other tools all the time and find them incredibly valuable.

[upe]

@michaelneale Sorry for the delay. Attached a video of what I mean by editing the agent's response directly. When working with an agent on a doc... you could try telling it what changes you want... but often, just faster to do it yourself. Further, you can make small annotations here and there to "point" at things for the agent to fix. Much faster than trying to explain where you want something, sometimes.

Also great when workin on a checklist with an agent.

Edit.vid.mov

[DOsinga]

Another thing I've been thinking about is triggers. We have the scheduler that can do things on a time basis. could we integrate with other things that happen on your computer? email is probably the easiest - you could do something like it with the scheduler and an mcp server probably, but I think if we would integrate deeper and I could just have simple rules like, if an email like this comes in, add a line to a spreadsheet or automatically reply based on the instructions in this document, it would be superuseful for people wanting to automate their lifes. beyond that integrating with all kinds of things that happen on your local computer. home automation springs to mind

[maniksurtani]

I like the focus on meta-agent + SDK. I wonder if that means we then end up with multiple "distros" based on how people use it. E.g., a "Goose-SWE-Agent", set up for development use cases, and a "Goose-Assistant", configured for non-coding work.

[michaelneale]

yes - and at the very least, an sdk (and in fact the cli) can be distributed via npm wrapper (like codex does, which is neat)

[spencrmartin]

Wow - happy 2026 everyone! Super excited to see where goose takes flight towards this year.

Wanted to take a moment to possibly showcase some of the workings from the design side in this forum as we're always experimenting and would love to talk shop about what we might find exciting.

TOM theme being: How can goose be something that works for everyone across any task

Users who can customize goose to fit their specific needs—positioning navigation where it feels natural, composing messages with rich formatting and code, accessing the tools they use most. Creating the flexible primitives that let goose adapt to each user's unique way of working, enabling the personalization that makes AI assistance truly effective.

That looks like:

Addresses the "one-size-fits-all" problem that limits adoption. Developers, designers, and managers can each configure Goose to match their workflows, increasing daily active usage and reducing abandonment. Lays groundwork for multi-instance collaboration. Allowing users to make and pin apps to start spaces - creating widgets - customizing their experience with quick actions etc.

Transform goose's chat input from a simple text box into a powerful composition environment. Users can format text (bold, italic, lists), write and edit code with syntax highlighting, attach files with drag-and-drop, and invoke tools through contextual commands (/search, @mentions, #tags). Reduce the friction in complex workflows by letting users compose messages as naturally as they would in a modern document editor—without leaving the conversation.

A place to see everything amazing! Create a space to discover, install, and share community-built apps, extensions, and workflows. Think App Store for Goose—users browse by category, read reviews, and install with one click. Developers and power users can publish their creations, from custom tools to pre-configured workflows to workspace layouts. All open.

MCP-ui/apps in the mix more intently. Transforms goose from a chat interface into a complete workspace platform. reducing the need to switch between Goose and other tools—everything can run in one place with shared context. Build custom workflows while keeping the core experience simple for casual users. Let me run all me teeny tiny custom apps with goose flying alongside.

There is so so so much fun stuff we can do with goose - but I want to stress that goose can/should be approachable and available for everyone. I was jamming around in this space here https://github.com/block/goose/tree/spence/vision

[spencrmartin]

Also backgrounds on home

[upe]

If this is the right place for minor feature requests... I'd love to be able to set a recipe's model and extensions via the recipe GUI/editor. (So I don't have to edit the yaml directly to make changes.)

[alexhancock]

@upe A good request - I'd file an issue! This is more a "whats our roadmap for the quarter/year" type discussion.

[taniacryptid]

Happy (somewhat late) new year! Plus one to a lot of what has been mentioned already.

1. Desktop app focus - we constantly receive feedback on improving the desktop app experience. Despite any issues or inconsistencies that pop up in everyday use, community members love using goose. Making this experience the smoothest it can be would go far for long-term project health. Specifically with session management, accurate visual feedback, error handling, and the model selection interface too.
2. Config experience - this is the top support burden for maintainers based on feedback. The feeling is the app itself should accurately tell you when something is wrong or not quite working. "Let me try to plug in what I need, you tell me what I need to provide or fix." This may be the toughest one, but super important.
3. Growth into meta agent - since the introduction of features like recipes and subagents, users have been wanting more workflow and multi-agent orchestration. Especially things like managing multiple sessions and sub-recipes being top points of tension. Reducing when you are forced to open a new session outside of when you are trying to would be great too.
4. Updating goose - the update process for community members could be more straightforward.

With all the above in mind, making the desktop experience smooth, responsive and the config as straightforward as we can make it would be most ideal!

[alexhancock]

My thoughts!

UX Evolution

We need to level up the expressiveness of the desktop UX - a lot of what @spencrmartin posted earlier resonates in this area. We also need a new CLI UX that lets the user see more of what's going on (with subagents, extensions, outputs, etc) as they work.

Interface

We should decide what we're going to use ACP for. If it will remain the goose acp command for external things to connect to and tell goose what to do, or if we want our first-party clients to leverage it. This will also inform what we do with the goosed API, in terms of first party client usage, and public documenting/sharing of that API.

Flocks of geese

There is an emerging need to manage multiple interactions with goose in a more scalable and coordinated way. This will unlock multiple agents working on different parts of a shared mission (changes across multiple codebases that will work together, editing remote config on a number of connected machines, etc). This could be tackled as part of our implementation of subagents, or be a separate orchestration primitive that controls multiple geese (alongside other agents?)

Apps

I think there is a long way we can go with MCP Apps support, and #6474 addresses it nicely. Deciding how and where app content will render in goose and how it can make goose capable of much more in its UX than it is currently is interesting.

MCP completeness

We've made good strides in both the rust-sdk and goose in terms of spec compliance with MCP, but we still lag the November spec by a bit. Coming up with a process to ensure we stay up to date with everything in the rapidly changing MCP spec is important for goose in 2026.

[upe]

Came across this: https://agents.craft.do/ — there are two interesting UX ideas here:

1. Organizing chats by backlog/todo/done/cancelled
2. Having skills, MCPs, APIs, and local files all easily accessible and visible in the left nav