Goose Architecture and Runtime
1. The workspace shape​
The repo layout tells a clear story:
| Area | Purpose |
|---|---|
crates/ | Rust runtime and core libraries |
ui/ | Desktop-facing user interface work |
documentation/ | Product and contributor docs |
examples/ | Reference usage patterns |
workflow_recipes/ | Repeatable higher-level agent workflows |
oidc-proxy/ and services | Supporting infrastructure for auth and embedding scenarios |
This is a bigger workspace than a single-binary coding CLI, but still small enough to navigate deliberately.
2. The three runtime surfaces​
Goose deliberately exposes one agent through multiple surfaces:
- desktop app
- CLI
- API
That architectural choice matters because it pushes the core runtime to stay reusable instead of baking all behavior into one UI.
3. Providers and extensions are central, not optional​
The official docs treat provider support and extensions as core product areas. That means the real Goose architecture is not just:
model plus terminal
It is closer to:
agent core plus provider abstraction plus extension runtime
That is why the project can support many providers, local model runners, and MCP-based capabilities without becoming a vendor-locked tool.
4. Workflow recipes matter​
The workflow_recipes/ directory is a useful clue about project direction. Goose is not only trying to answer prompts; it is also trying to package repeatable agent workflows that can be reused and shared.
For many teams, that is where Goose becomes more valuable than a plain chat assistant.
5. How to read the codebase​
Start in this order:
README.md,- provider docs,
crates/,ui/,- recipes and embedding surfaces once the core loop is clear.