Goose, BeeAI Desktop, Hermes Agent, OpenClaw’s local mode. Four tools with four different architectures, four different governance models, four different answers to the question of how an agent should run on your machine. And the most useful thing you can do this morning is stop comparing them like they’re competing products. They aren’t. They’re competing architectural answers to the same problem, and the problem is bigger than any one of them.
That problem, the one that opened this week’s arc, is straightforward enough to state: an agent that runs in someone else’s cloud resets between sessions, and a resetting agent is a forgetful agent. The local runtime solves this by keeping state where you keep your work. Your filesystem becomes the agent’s memory. Your tools become the agent’s tools. Every session inherits the context of every previous session because the context lives on your machine, not in a vendor’s ephemeral session store. But stating the problem is the easy part. Building a runtime that actually delivers on that promise, across operating systems, across model providers, across the patchwork of tools and credentials and APIs that define how a working engineer actually spends their day, is the hard part. The four tools in this arc are each solving a different piece of it.
Goose solved breadth. It runs on macOS, Linux, and Windows as a native desktop app, a CLI, or an API. It connects to 70-plus MCP extensions and 15-plus LLM providers including fully local Ollama models. It compiles to a single Rust binary with no runtime dependency chain. It is the most credible answer to “can a desktop agent actually work across the environments I use every day?” The answer Goose gives is yes, and here’s the screenshot to prove it. What Goose did not solve was depth. It does not learn from its own execution history. It does not build a library of reusable workflows that compound over time. Each session starts clean. Goose is a stateless tool with extraordinary breadth and zero institutional memory.
Hermes Agent solved depth. Its skill system records proven workflows with verification steps, failure modes, and recovery patterns. Every successful session makes the agent more capable. Those skills are not stored prompts. They are execution paths that have been tested against real outcomes and refined by repeated use. A Hermes skill is closer to an operations runbook than a prompt template. The agent genuinely gets better the longer you use it. What Hermes did not solve was OS-level integration. It does not have a native desktop GUI, does not treat running processes as discoverable tools, does not respond to system notifications. It is a runtime, not an operating system companion. The depth is unmatched. The breadth is narrow.
BeeAI Desktop solved interop. It built its architecture around A2A for agent-to-agent communication and MCP for tool discovery, treating protocol interoperability as infrastructure rather than an afterthought. Its constraint enforcement layer ensures that governance rules survive a model swap. Its serialization module saves and loads full agent state, not just conversation history. What BeeAI did not solve was community. At roughly 3,380 stars, it is an order of magnitude smaller than the other tools in this arc, and the ecosystem of pre-built integrations reflects that. The architecture is sound. The adoption curve has not started yet.
OpenClaw solved the event model. Its unified event journal records every input, every tool invocation, every LLM response as an immutable log. On restart, the journal replays. The agent picks up exactly where it left off. Its 385,000-plus stars reflect the genuine demand for an agent runtime that treats everything as an event and events as the source of truth. What OpenClaw did not solve was the self-improvement loop. It remembers what happened. It does not learn from what happened. The distinction between replaying an event log and extracting reusable skills from it is the gap between a reliable runtime and a compounding one.
These are not competitors. They are components of a stack that does not exist yet.
The stack you actually want, the one that the individual practitioner needs and the market has not shipped, looks something like this. Goose’s breadth for OS integration, native GUI, and tool access. Hermes’s depth for skill accumulation and self-improvement. BeeAI’s interop model for agent-to-agent communication and constraint enforcement. OpenClaw’s event journal for durable state and reliable recovery. And all of it running locally, on your machine, with your files, your credentials, your accumulated context.
Nobody builds that today. Nobody can build that today. The protocols are not mature enough. The skill extraction pipelines are not standardized enough. The handoff between a Rust desktop binary and a Python skill system is not a solved engineering problem. The category exists. The product does not. And that is the most useful thing to understand about the agent desktop right now: you are not choosing between competing products. You are surveying the components of a stack that the next two years of open-source development are going to assemble.
The pattern beneath all four tools is the same because the problem forces the same architectural constraints. Local state is non-negotiable. The agent’s memory, preferences, learned workflows, and accumulated context live on your machine, not in a vendor’s database. File system as memory is the default integration. Your documents, your code, your notes, your configuration files are the agent’s primary source of context without requiring you to explicitly connect and authorize each source. OS-level tool access is the differentiator. Running processes, system notifications, file system events, and hardware sensors are tools the agent can use, not APIs it must be granted. Persistence by default means the agent survives a restart without manual checkpointing. The runtime owns the loop, not the framework.
Those four constraints define the category. Anything that meets them is an agent desktop. Anything that does not is something else. The constraints are not opinions. They are the architectural minimum for an agent that compounds rather than resets.
The thing none of them have solved yet is the handoff to mobile. Your desktop agent knows your files, your tools, your workflows, your preferences. It has weeks or months of accumulated context. The moment you close your laptop and walk out the door, that context becomes inaccessible. Your phone cannot query it. Your tablet cannot resume the session. The agent desktop is a category with a hard boundary: it ends at the edge of your machine. Solving mobile handoff requires solving trustless context synchronization, encrypted state transfer, and a model for partial context delivery that does not require streaming your entire agent state over a cellular connection. Nobody has cracked this. Nobody is close. The first tool that does will define the next phase of the category.
The bridge to tomorrow’s reference architecture is straightforward. If the agent desktop is a category made of components that do not yet compose, what does the composition look like when they do? The personal agent stack: a runtime layer that owns the loop, a tool middleware layer for MCP and A2A, a memory tier for local vector stores and structured state, an execution sandbox for isolation, and a UI layer that unifies CLI, desktop GUI, and eventually mobile. Tomorrow I will walk through each layer, where it lives, how it talks to its neighbors, and the one integration that makes the whole thing feel like a single agent rather than five components in a trench coat.
The agent desktop is not a finished product you can buy. It is an architecture you compose from the pieces that exist today, and the pieces that exist today are better at different things. Breadth. Depth. Interop. Events. The stack that has all four does not exist yet. But the shape of it is visible for the first time, and the tools in this arc are the ones building its components.
If this was useful, forward it to one engineer who needs less noise in their feed.