The pitch on the holaOS GitHub repository is disarmingly simple: “Run any agent — Claude Code, Codex, or holaOS — in one local-first workspace, over your tools, your files, and one shared memory.” The project, from the holaboss-ai organization, is an open-source desktop application that treats the agent as a swappable component rather than the center of the universe. That inverts the current market logic, where every lab is racing to make its agent the one you never leave.
The core architectural claim deserves attention. holaOS runs Claude Code, Codex, and its own built-in agent side by side, all sharing the same memory, tools, skills, and app surfaces. The memory is stored locally as plain files, structured and embedded so context returns when needed. Switch agents, close the app, come back a week later, and the workspace remembers. That is a direct challenge to the lock-in strategy every frontier lab is quietly pursuing. Anthropic wants you in Claude Code, OpenAI wants you in Codex, and neither wants your context portable.
What makes this technically interesting is the shared-memory layer. Most agent frameworks treat context as a session artifact, something that lives and dies with the process. holaOS treats it as durable infrastructure, a filesystem the agent reads and writes. The README is explicit: “Context, preferences, and project history live in a single shared memory — stored locally, as plain files you can read and edit.” That is a bet that the agent is a transient executor and the memory is the permanent asset. For AI builders, that is the right inversion. The model will be obsolete in eighteen months; your accumulated project context will not.
The integration story is equally deliberate. The project claims 100+ integrations plus Model Context Protocol (MCP) support, with one-click OAuth for Gmail, Notion, Slack, GitHub, Linear, and 50+ more. Skills can be packaged once and run by any agent. Combos bundle skills and integrations into single-click installs. The MCP angle is the important one. MCP is the emerging standard for giving agents tools, and holaOS is betting that the protocol makes the underlying agent almost irrelevant. If every agent can speak MCP, then the workspace that manages the servers, the credentials, and the memory becomes the durable layer.
The model strategy is a tell. holaOS bundles “cost-efficient Kimi K3 and GLM 5.2 for everyday volume, plus top-tier GPT 5.6, Claude Opus 5, and Fable 5 for the hard problems.” It also supports BYOK for OpenAI, Anthropic, or any compatible endpoint. That is a provider-agnostic stance that no single lab would ever ship. Anthropic will not offer GPT 5.6 as a built-in option. OpenAI will not bundle Claude Opus 5. Only an independent aggregator can do that, and it is exactly the kind of neutral ground that enterprises want when they are tired of picking sides in the model wars.
The local-first commitment is the sharpest contrast with the current wave of cloud agent platforms. The README emphasizes that memory lives “on your machine, visible and editable, not locked in someone else’s cloud.” The desktop app runs Electron, installs via a one-line curl script, and can be self-hosted under a modified Apache 2.0 license. The license carries “additional commercial-distribution and branding conditions,” which is a reasonable hedge for a project that also sells an enterprise tier with SSO, per-role permissions, and audit logs. The open-source core is real, but the commercial surface is clearly the on-ramp to a managed product.
There are open questions the README does not answer. The shared-memory format is described as “structured and embedded,” but there is no schema documentation, no migration story, no interoperability story with other agent memory systems. If you want to leave holaOS, can you export your memory in a format another tool understands? The local-first ethos suggests yes, but the repository does not say. That matters for trust. A memory layer you cannot leave is a lock-in by another name.
The agent-portability thesis also has a performance cost. Running Claude Code and Codex side by side means maintaining compatibility with two rapidly evolving agent frameworks, each of which is moving fast and breaking things. The holaOS team is signing up for a permanent game of catch-up. Every Anthropic release that changes Claude Code’s internal state format, every OpenAI update that alters Codex’s tool-calling conventions, is a potential breakage. The project’s own install instructions, which hand the setup to a coding agent in one sentence, suggest the team is comfortable with that churn. The question is whether the maintenance burden becomes unsustainable.
The enterprise pitch is where this gets real. holaOS offers SSO with per-role permissions for every agent, skill, and app, plus audit logs on every action, deployable on-prem or in your own cloud. That is aimed squarely at the compliance problem that has kept agents out of regulated industries. A bank cannot let an agent roam free across internal systems without audit trails and role boundaries. An aggregator workspace that standardizes those controls across multiple agents is a more attractive procurement target than any single lab’s offering, because it does not force the bank to bet on one model provider.
The broader implication for the AI economy is uncomfortable for the labs. If holaOS works, the model becomes a commodity layer, selected per task by cost and capability, while the workspace, the memory, and the integrations accrue the switching costs. That is the opposite of the current market structure, where OpenAI and Anthropic are trying to make their models and their agents inseparable. The BYOK model, where your keys run on your account and not the holaOS plan, makes the aggregator’s economics even cleaner: the platform does not even need to mark up inference.
For AI builders, the practical takeaway is to start treating agent memory as a first-class artifact. The holaOS approach of plain files, structured and embedded, is a reasonable default. Whatever agent you use today will be replaced, but the context you accumulate should survive the transition. Build your workflows so the memory is portable, the tools are MCP-compatible, and the agent is the only thing you swap. The labs will keep fighting over which agent you run. holaOS is betting that the workspace underneath is the asset that actually lasts.
The repository is young, the integration surface is ambitious, and the maintenance burden is real. But the direction is correct. The agent is a means, not an end, and the first project to make that explicit in a shippable, local-first form has articulated the right problem. The next twelve months will show whether the shared-memory format becomes a standard or a dead end.