v1.0

[baxen]

We’ve learned a lot from the first versions of goose. Between improvements in memory/history, safer tools, and better foundational models - goose can solve pretty incredible problems. goose can migrate enterprise scale code bases to new languages. It can extend itself by developing its own toolkits. It can build and deploy working, tested backend services.

Our biggest limits are actually in making goose easy to use, and extending its capabilities into more surfaces and systems.

The first challenge most people face is getting it installed and running. We love python, but as a distributable tool, we’re missing out on a lot of the benefits of languages that can create a standalone binary.

The second biggest challenge we hear from feedback is understanding what goose can do! We’ll improve the CLI discoverability, but we also want to explore alternative interfaces that give us more options to surface what goose can do and what it is working on. We’ve got some cool setups with editor extensions, and are considering other surfaces where we can run goose. Doing that well will require goose to be more portable than it is today.

So how do we improve from here?

• We’re planning to rewrite goose in rust (or, probably, goose will rewrite itself in rust and we'll review it). Then we can distribute the CLI as a binary, but also make libraries available to python and javascript so that we can bring the same core agent functionality to other interfaces.
  • go would make another great option for the CLI. But from the team’s experience, we think rust will go a lot further integrating into other interfaces because of its portability.
• We’re planning to rename Toolkits to Systems to make it more clear they represent an entire system goose can operate, and introduce more concretely how to share system state with goose. Systems will provide tools and instructions, like toolkits, but better manage state.
• Systems will be dynamic: you’ll be able to connect to them during a session, and not need to install them into your goose runtime. Core systems, like the current “developer” toolkit, will be embedded in the rust process. But we’ll support external systems which can be loaded on the fly by communicating over http. This will also let you build systems in any language, including python.
• The core logic of the goose agent will be available via a protocol, to make it easier to build with goose outside of the CLI interface. This one looks promising, but we'll explore along the way.

Coming Soon

Look out for beta releases of 1.0 this year, where we'll be excited to gather early feedback.

[Kvadratni]

I'm off to learn rust.
As a matter of feedback I'd like to re iterate having a different mode of communication with goose akin to API. It would simplify connectivity and integration with ide extensions

[baxen]

Yes great point! It's in scope for sure, that's worth its own bullet let me add it

[blackgirlbytes]

How exciting!!! Especially this part "This will also let you build systems in any language, including python."

[jtorreggiani]

@baxen thanks for the update on Goose’s new direction! Using a systems language like Rust for a robust, local developer agent makes sense. I’ve tinkered with Rust a little, but have been looking for an opportunity to work with it on a real world problem. So here to pitch in and give it a shot!

I think renaming toolkits to systems is a good move. Semantics are important! I may be a little biased since I've been tinkering with a goose plugin for helping goose "think in systems". 😅

As the team embarks on Goose's rebuild, a few architectural questions come to mind:

• How will system boundaries be managed to prevent conflicts between core Goose prompts and those from other systems?
• Will Goose core focus on general problem-solving and planning, or will it be specialized for code generation, file manipulation, and iterative system commands?
• Will Goose core provide primitives like notifiers and tables for systems to display information in the console?
• Will a "headless" mode be possible to enable Goose’s use in CI systems like GitHub Actions where all file changes are committed as pull requests?
• With Goose agents gaining more access and control over systems, should we consider implementing roles and permissions?
• Roles might involve setting up system prompts and profile configurations to define ownership, accountability, and permissions for system and tool access.

[baxen]

Yes great questions! We don't necessarily have answers to all of these yet, but here's what we've discussed so far:

• Right now adding new systems will be updating the tools available to goose, which ultimately means the instructions they include become "system" prompts and they compete for attention. That'll likely be how the first version works, and the human will need to provide a curating role to ensure the pieces work together. Over time, i'd like to explore how we can treat integrating systems more as part of the conversation and even include a warmup process for each.
• Our top priority will remain goose being a developer agent (and so emphasizing coding etc). However everything we've done so far makes us think that we can do that just as well with an architecture and prompting that will generalize, so we'll be exploring how far that can go without hurting the developer role performance.
• Speculatively i think notifiers will go away. They were an awkward part of the old code base, and leaked abstraction details from the interface into the tool implementation. We'll likely need to instead rely on widely renderable pieces like markdown strings, svgs, etc, and leave displaying them up to the interface
• We will definitely have a "headless"/"chatless" mode on the CLI! This will become more natively supported than the current goose "run", as we see a lot of applications - like you mentioned with Github Actions etc
• Roles and permissions design i think will be a future step, right now we'll probably continue to have goose acting on behalf of the human using it. However we do have two ideas in this space: adding a secure auth flow that systems can request for confirming important actions (secure meaning the agent has no way to fake approval), and/or introducing roles as part of the system setup.

[jtorreggiani]

Thanks for this detailed response @baxen. I'm excited to see where these threads go!

[nitishmathew]

Agree on the focus on this > The second biggest challenge we hear from feedback is understanding what goose can do!

Data Engineering is a field, which we think, can use this tool a lot to improve productivity particularly in Data Modeling, Data Quality and Data Documentation.

How GenAI will impact data engineering

[michaelneale]

on Systems, some thoughts for discussion (perhaps need a distinct thread?)

• is it fair to say "systems" are the main means of extension of goose?
• external systems would be favoured way to offer extensions (as can accomodate changes faster?)
• We could consider some "domain socket" option for local systems to reduce security hazards potentially (needs exploration)
• Could we have a searchable public registry of systems - that people can add to (perhaps in a semi permissionless way)? (can search from website, or within goose?)
• Rust is certainly a thing to learn, so perhaps a lot of extension-related (and in fact, interesting!) functionality we can encourgae to be in extension which are not in rust?

lately I have bene using https://homebridge.io/ and I like the

right on the page (it's backed by NPM in that case, just as an example - but lowers barrier for people to make rapid integrations).

[Kvadratni]

Once we go from cli to an app or webapp - we should definitely build a system discovery page

[baxen]

Yes to all of this!

To reiterate one of the points, systems will be workable via both externally hosted systems and local sockets, and that will mean they can be developed in any language. And connecting a new one will no longer require updating your goose installation

[acekyd]

Looking forward to having a website for Goose with this on it. 🔥

[steve-the-edwards]

My biggest difficulty with goose is getting it to work over a large number of files (for refactorings and such). Being able to support either fanning out sessions to work on separate files or allowing for continued progress over a large set of directories would be valuable at enterprise scale.

[blackgirlbytes]

Are there any plans to add an easy UI for creating toolkits..maybe like someone just fills in a form of what actions they want the toolkit to perform and Goose just auto generates it all 🤔

[AaronGoldsmith]

Would it make sense for us to add an ImageUrl class to the Exchange package to provide better support for Vision? I noticed we have something kind of hacky here, but Images in general are not well defined.