Updated Goose Roadmap

[DOsinga]

🐥 Goose Roadmap

Welcome to the latest roadmap for Goose! This document outlines where we're headed, what we're fixing, and how we’re evolving the Goose platform with and for the community.

---

🛠️ Formalize Our Development Process

We currently have around 300 open issues and 100+ unprocessed pull requests on GitHub. Our short-term plan:

• ✅ Close or merge all PRs older than two weeks within the next two weeks.
• 🕒 Response SLA: Going forward, 90% of incoming PRs will be addressed within 3 days.

We're also introducing structure around issues:

• 🏷️ Each issue will get:
  • A status label: icebox, backlog, needs clarification, in progress, or wontfix
  • A priority label: p0 (highest) through p3 (lowest)

We'll also publish:

• 📝 Our general way of working
• 🧪 The manual test script we use
• 🚀 Our release process

All of these documents will be open to community feedback.

---

📦 Support the Full MCP Standard

Goose was among the first agents to support the Model Context Protocol (MCP), but we’ve recently fallen behind:

• 🧭 We're currently compliant with the March MCP standard — but not the June 2025 update
  📄 Changelog

• 🔄 While the official MCP Rust SDK is based on Goose, we’re not currently using it ourselves.

We plan to:

• Migrate from our internal MCP implementation to the official SDK, ensuring no regressions.
• Commit to helping keep the official SDK up to date with MCP standard changes.

---

🧪 Improve Testing

Our current tests skew toward simple unit tests — many autogenerated by LLMs — and some may even hurt readability or slow down CI.

We’ll focus on:

• ✅ Improving coverage through more meaningful end-to-end tests
• 🧪 Expanding UI tests and integrating them fully into CI
• 🎬 Introducing scenario tests, simulating goose-cli usage:
  • 🧠 Mode 1: Run live against an LLM and record outputs
  • 🔁 Mode 2: Re-run tests using these outputs to ensure deterministic, CI-safe behavior

---

🚀 Make Onboarding Delightful

Goose is powerful once it's set up — but initial onboarding can be rough.

We’ll focus on simplifying the startup path, especially around getting a model up and running. We'll offer:

1. 🔑 Bring your own API keys
2. 🌐 Connect to OpenRouter
3. 🧠 Download and run a local model, with a quick scan to suggest what works best based on your machine

---

🖼️ Refresh the UI

We're updating the interface to support more integrated workflows:

• 🧠 A unified UI supporting:

  • Multiple active agents
  • Workspaces for projects and recipes

• ⚙️ A complete cleanup of the settings dialog, which has become difficult to navigate.

Here’s a preview of where we’re headed:

Home	Session History	Projects
Settings	Session Item

---

🧾 Make Recipes Work Universally

We’re evolving recipes to go beyond being just text files with prompts:

• 📘 The recipe roadmap outlines how we’ll support full agentic automation flows
• 🧩 We're enhancing recipe capabilities inside the desktop app, where some key features are still missing

---

🍽️ Eat Our Own Goose Food

Goose should be self-hosting — you’ll be able to:

• 💬 Talk to Goose inside:
  • Our GitHub repo
  • Our Discord channel

These will use Goose recipes, so you can clone and adapt them for your own use.

🧠 We’re also considering context-aware agents:
If you're in /docs, Goose understands documentation style; if you're in /src, it speaks our Rust dialect.

---

🧠 Core Agent Improvements

We’re working on foundational capabilities:

• 🧵 Support for sub-agent orchestration

  • Spawned autonomously or via sub-recipes
  • Each sub-agent handles a distinct task in a larger flow

• 🔄 Dynamic model selection

  • Agents can switch models mid-conversation
  • Sub-agents may use different models tailored to task type, cost, or capability

---

🌍 Hosting

Goose excels at vibe-coding full-stack apps in minutes, but sharing those results is still clunky.

Current path:

• ✅ Publishing via an MCP server works, but isn’t frictionless

We’re exploring:

• 🖥️ Turning projects into Goose Apps:
  Use the same Electron-based framework running Goose to also run your AI-generated applications.

---

🐳 Async Goose

Right now, there’s no turnkey way to spin up containers running agents.

We’re building infrastructure to:

• 🧱 Run Goose agents inside containers, both locally and remotely
• 🔄 Support long-running async workflows

---

♻️ Self-Improving Goose

To be truly useful, agents shouldn’t have to start from scratch for each new project.

We’re experimenting with:

• 🤖 Letting Goose maintain and evolve its own recipe collection
• ✍️ Giving it the ability to refine its own system prompt
• 💡 Ultimately: self-improving source code

This is a long-term bet, but a critical direction for robust agentic systems.

---

Let us know what you think! Got ideas? Want to help? Open an issue or send a PR 💛

[cbruyndoncx]

That is quite a roadmap, triggering a bit more questions:

• do you have a Now / Next / Later split for these ?
• I saw some things like sub-recipes in the release notes so that seems close to release
• Is goose intent on keeping feature parity through the different OS options for GUI and CLI ?

[taniashiba]

Thank you for your comment! I'll let @DOsinga answer, however I also wanted to +1 on the Now/Next/Later split. I know these are generally in order of what we may like to take care of first.

[cbruyndoncx]

asked Claude for a Now/Next/Later split - any good ? https://claude.ai/public/artifacts/164002cc-34c3-452b-ae7f-f7f2a672b2e2

[cbruyndoncx]

and a one pager landscape https://claude.ai/public/artifacts/c7225c09-90bc-4151-aedb-13eafbf00b06
gotta get some claude ROI ...

[DOsinga]

thanks @cbruyndoncx - that's actually pretty decent.

So they are roughly in order and I would say that the first 5 are "table stakes"

• Formalize Our Development Process: We've had some releases recently where we broke stuff. We are getting PRs from the community that are great, but that linger for weeks. At the same time we've added meandering features that. We will do better!
• Support the Full MCP Standard: This is the most exciting thing in agentic AI and we need to support everything
• Make Onboarding Delightful: We lose too many people when they try the product, especially in the bit where they set up the model
• Refresh the UI: It's due! We've had this for almost half a year now!

We have all of these in the works in some form, and you'll start seeing this in the coming weeks. Some of these changes are going to be bigger, so if you see odd breakages, let us know!

The other items are more speculative and directional. So that's more mid to longer term. Hope this helps!

[dcieslak19973]

For "Async Goose" there's the vibekit project https://github.com/superagent-ai/vibekit which seems to want to do this sort of thing for all cli-based coding assistants/agents. Thoughts on working with them on making the 2 projects work smoothly together?

[DOsinga]

That's cool - what do you think @jamadeo ?

[homanp]

I'm down (creator of VibeKit)

[DOsinga]

what do you need @homanp to make Goose work in that context?

[homanp]

what do you need @homanp to make Goose work in that context?

Not much, need a headless command for running goose, similar to how codex/claude code works? E.g claude -p "add login page" -m "gemini-2.5-pro"

[homanp]

@DOsinga wdyt? Would be happy to add goose to vibekit

[harkamals]

The MCP or Extensions, require goose to download a lot of stuff from internet, and is blocked for corporate proxies. This makes the most loved tool, less useful. Please consider an offline or airgapped way to download extension bundles.

[DOsinga]

yeah, this is true, but not all that easy to avoid. we could allow the user to add MCP servers directly or through a zip file, but when you run the mcp if they are uv or node based, they will try to resolve their dependencies and fail at that point

[harkamals]

It will be really helpful, please accelerate on this.

Once the .zip is available, we have local artifactory instances to serve dependencies for node, python, etc.

[cbruyndoncx]

you can add your custom server already, so if you have it installed locally, you can just run your command ? Not sure what is the exact request for goose to do ?

[Drinect]

Are you guys thinking about creating a (Python) SDK interface for interacting with a goose session from code scripts?
So one can use the Goose functionality in a similar manner as, for example, the claud_code_sdk?