A Confusing Opening
If you see holaOS's GitHub description, your first reaction might be "yet another AI desktop":
> Run any agent — Claude Code, Codex — across your tools (100+ integrations + MCP), apps, browser, and files, with shared memory.
But reading carefully reveals an unusual positioning: it doesn't replace any agent; it lets multiple agents share one working environment.
This is a completely different direction from editors like Cursor or Windsurf that ship their own built-in agent.
The Core Problem: Agent Memory Silos
If you use both Claude Code and Codex daily, have you hit this:
- Claude Code helps you refactor a module, with the full project structure in its context
- You switch to Codex to write another feature, and it knows nothing about that refactor
- You have to manually tell Codex what Claude Code did, or have it re-read the code
- Debuggable: When an agent behaves oddly, you can inspect its memory files to find the cause.
- Portable: Switching tools doesn't strand your memory.
- Trustworthy: Users get full visibility into what the AI "remembers."
- Bundled models: One account unlocks SOTA models (Kimi K3, GLM 5.2, GPT 5.6, Claude Opus 5, Fable 5) with no API key management.
- BYOK: Bring your own OpenAI or Anthropic key, billed to your own account.
- Any MCP-compatible tool can be invoked by agents inside holaOS.
- An MCP server you write can be used simultaneously by Claude Code, Codex, and the holaOS agent.
- macro: Team-oriented—integrates communication, documents, CRM, and other business tools.
- holaOS: Developer-oriented—integrates agents, MCP tools, and local files.
- Repository: holaboss-ai/holaOS
- Stars today: +380
- Platforms: macOS, Windows, Linux
- Tech stack: TypeScript + Electron
- License: Modified Apache 2.0
- Website: holaos.ai
This is the agent memory silo problem. Each agent has its own context window, conversation history, and tool configuration. Switching agents means swapping in an "amnesic colleague."
holaOS aims to solve exactly this. Its core promise:
> Context, preferences, and project history live in a single shared memory — stored locally, as plain files you can read and edit.
The keywords are shared and locally. Shared means cross-agent availability; locally means nothing is locked inside a cloud service.
Three Design Decisions Worth Examining
1. Agent-Neutral — No Vendor Lock-In
holaOS does not build its own agent. Instead, Claude Code, Codex, and holaOS's bundled agent run side by side. The README states it plainly:
> No lock-in — bring the agent you already trust.
This aligns with the principle that "division of labor beats unification"—holaOS provides workspace infrastructure; agents do the reasoning. You won't have to rebuild your entire workflow just because you switched agents.
2. Memory as Files, Not a Database
holaOS stores its shared memory in local files that users can open and edit directly. This design choice is critical:
This contrasts with OpenAI's Memory feature, which lives in the cloud and only exposes summaries to users—never the raw data.
3. BYOK Plus Bundled Models
holaOS offers two modes:
This dual-track design is pragmatic—zero-friction onboarding for newcomers, full control for power users.
Relationship with MCP
The README mentions "100+ integrations + MCP." MCP (Model Context Protocol) is Anthropic's standardized agent-to-tool interface. holaOS's MCP support means:
Back to the division-of-labor principle—holaOS doesn't reinvent tool protocols; it uses MCP, an emerging standard, to connect existing tools.
A Question Worth Asking
holaOS's positioning is clear, but one question is worth probing: what is the format of the shared memory?
The README says "stored locally, as plain files you can read and edit" but doesn't specify the format. If it's a custom JSON, cross-tool migration still requires conversion. If it uses a standard format (for example, Markdown with frontmatter), portability is much stronger.
The answer determines whether holaOS is "a product" or "an ecosystem." In the former case, users are locked into holaOS; in the latter, holaOS could become a de facto standard for agent workspaces.
Comparison with macro-inc/macro
Trending the same day was macro-inc/macro (+1,180 stars), positioned as a "unified workspace for teams: email, chat, docs, tasks, agents, calls, and CRM." Both pursue "unified workspace" but in different directions:
macro wants to replace Notion + Slack + Salesforce; holaOS wants to replace Cursor + Claude Desktop + various MCP hosts. Different markets, but both point to the same trend: tool fragmentation has reached the point where users can no longer tolerate it.
Project Data
*holaOS's core bet: users are tired of rebuilding their working environment for every new agent. If the bet pays off, "agent-neutral + shared memory" may become the foundational design pattern for AI workspaces.*