Most desktop AI agents are thin wrappers around a chat window. Goose is not that. It is a general-purpose agent that lives on your machine, talks to your filesystem, connects to 70-plus tools through MCP, and runs against 15-plus LLM providers including fully local models through Ollama. At 52,584 stars and backed by the Linux Foundation’s Agentic AI Foundation, it is the most credible open-source answer to the question that opened this week’s arc: what happens when your agent runs where you work, not where a vendor hosts it?
Block built Goose inside Square and Cash App before donating it to the Linux Foundation under Apache 2.0. That origin is important. This was not a side project from a research lab. It was built by engineers who needed an agent that could navigate internal codebases, automate operational workflows, and survive the constraints of a production environment where “just use the cloud” is not an acceptable answer for every problem. The architecture reflects that. CLI, desktop GUI, and API are all first-class interfaces. The desktop app runs on macOS, Linux, and Windows. The CLI installs with a single curl command. The API lets you embed Goose inside your own tools. None of these are afterthoughts.
The MCP integration is where Goose gets interesting as a desktop agent. Most tools that claim to work with your filesystem actually mean “you can upload a file to our cloud and our agent will read it.” Goose runs the MCP servers locally. Your files stay on your machine. Your credentials stay on your machine. The agent talks to the tools directly through the protocol, and the data never leaves your control unless you explicitly route it to a cloud LLM provider. With 70-plus documented MCP extensions, Goose can interact with databases, browsers, code editors, project management tools, and the operating system itself. A desktop agent with this breadth of tool access starts to look less like a chatbot and more like an OS companion that actually knows what is on your machine and can do something about it.
The provider story matters for the same reason. Goose supports Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, Bedrock, and more. The Agent Client Protocol lets you use your existing Claude, ChatGPT, or Gemini subscriptions without paying per-token API rates. For practitioners who want complete data locality, Ollama support means you can run a 7B or 13B model entirely on-device and Goose will use it as its reasoning engine. That combination of local execution and local inference is what makes the desktop agent thesis credible. A cloud agent resets between sessions because its context window is someone else’s infrastructure. A local agent accumulates.
What Goose does not do is self-improvement. This is the comparison that matters against Hermes Agent, which I covered last week. Hermes has a skill system where proven workflows compound over time. Every successful session makes the agent more capable. Goose does not have that mechanism. It does not learn from its own execution history. It does not build a library of reusable patterns that get better with use. It is a stateless tool in the sense that each session starts fresh, and what you did yesterday does not make it more effective today. That is not a flaw. It is a design choice. Goose optimizes for breadth: any tool, any provider, any interface. Hermes optimizes for depth: a self-improving runtime where the agent genuinely gets more capable over time. Pick the one that matches your problem.
The desktop app itself is worth a closer look because it reveals what Goose thinks an agent should feel like. It is not a terminal emulator with a chat pane bolted on. It is a native application with session management, a tool inspector that shows you what the agent is doing in real time, and a provider switcher that lets you change models mid-session. The GUI is not a veneer. It is a genuine attempt to make an agent feel like a desktop application rather than a command-line utility with a window. For practitioners who want an agent that sits alongside their IDE, their browser, and their terminal, that distinction matters. The CLI is there when you want it. The GUI is there when the workflow benefits from visibility into what the agent is actually doing.
The Rust implementation is another architectural signal. Goose compiles to a single binary. It starts fast. It uses less memory than Python or Node equivalents. On a desktop where you are already running an IDE, a browser with too many tabs, and probably Docker, every megabyte of agent overhead competes with your actual work. A Rust binary with no runtime dependency chain is the right call for a tool that belongs on your desktop permanently.
The Linux Foundation backing is not just governance theater. It means Goose cannot be acquired and shut down. It cannot pivot to enterprise-only licensing. It cannot deprecate the local model support because a cloud vendor became the primary sponsor. For practitioners evaluating whether to invest time in a desktop agent, the governance model is part of the architecture. An Apache 2.0 license and a foundation governance structure mean the bet you place on Goose today does not evaporate when the founding company’s priorities shift. Block donated it. The foundation stewards it. The community builds it. That is the right structure for infrastructure-level tools.
The limitations are real and worth naming. Goose does not have durable execution. If your machine restarts mid-task, the agent does not resume where it left off. There is no checkpointing mechanism, no state serialization that survives a crash, no equivalent of Restate’s guaranteed completion model that I covered on Thursday. For workflows that span hours or require reliability guarantees, this is a genuine gap. Goose is a desktop agent, not a production runtime. It runs when your machine is on and your session is active. That is the contract. Understand it before you build something that needs seven nines of reliability on top of it.
The other limitation is the MCP extension model itself. Seventy extensions sounds impressive until you realize that most of them are community-maintained, quality varies widely, and the security model is “trust the extension author.” MCP servers run as subprocesses on your machine with the same permissions as the Goose binary. A malicious or buggy MCP server has full access to whatever Goose can touch, which on a desktop is essentially everything. The protocol does not yet have a sandboxing or permission-scoping mechanism. For a tool that bills itself as your OS companion, this is the security gap that will eventually need to be closed.
Still, Goose is the desktop agent that makes the strongest case for the category. It exists for all three major platforms. It respects local data. It connects to nearly anything through MCP. It runs on any LLM you choose. The 52,000-plus GitHub stars are not just popularity. They reflect the genuine demand for an agent that lives on your machine rather than in a browser tab connected to someone else’s servers. The desktop agent thesis that opened this week is not theoretical. Goose proves there is a real product category here, and the architecture that makes it work is already shipping.
The question the category still needs to answer is not whether desktop agents can exist. Goose already answered that. The question is whether they will compound. Hermes says yes, through a skill system that learns from every session. Goose says no, through a stateless model that optimizes for breadth and flexibility. Tomorrow I will look at BeeAI Desktop, the Linux Foundation’s other bet on agent interop at the OS level, and a different architectural bet on the same problem. The desktop agent is a category now. We are figuring out what it should cost.
If this was useful, forward it to one engineer who needs less noise in their feed.