holaOS Review: An Open-Source Agentic Workspace That Puts Apps Beside Your Agent

The Problem: Agents That Live in Chat, Not in Your Work

Most agent products present a chat interface and hope you describe your work well enough. But real work happens inside apps: a Notion page, a browser tab, a project management board. Chat transcripts lose the nuance of what you actually clicked, typed, or saw. holaOS addresses this by putting the agent next to live application surfaces. The README calls it "real surfaces, not chat" and "side-by-side by design." This is for teams that want to watch an agent operate an app directly, step in when it drifts, and have the result land in the app itself, not as a summary. It is also for organizations that refuse to send proprietary data to a vendor's cloud, because the pitch is "local-first, so none of it leaves your machines." That positioning is the core value proposition, and it is a real differentiator from hosted agent platforms.

Architecture: Electron, TypeScript, and a Shared Context Bus

The repository is TypeScript and runs as an Electron desktop application, with desktop build scripts for macOS and Windows in the root package.json. The architecture is built around several layers: HolaApps are web applications that open inside the workspace, and the agent can drive them. The key mechanism is that context stays in sync both ways. When you interact with an app, the agent sees what you did. The README says "whatever you click, type, or open in the UI becomes context the agent already has." That implies an event or state synchronization layer between the app surface and the agent runtime. The agent itself can be Claude Code, Codex, or holaOS's own built-in agent. All agents share the same memory, tools, skills, and apps. Integrations connect via OAuth, and MCP servers plug in to expose additional tools. Skills package workflows, and Combos bundle skills and integrations for one-click install. The README says the shared memory is stored locally as plain files you can read and edit.

Getting Started: Clicks, Not Config Files

The README emphasizes "set up in clicks, not months." The documentation URL is given: https://www.holaos.ai/docs/getting-started. The repository has an INSTALL.md at the top level and the README links a Quick Start. You install HolaApps from an in-workspace marketplace with one click. Integrations such as Gmail, Notion, Slack, GitHub, Linear, and 50 more connect via one-click OAuth. For models, the README mentions built-in models like Kimi K3, GLM 5.2, GPT 5.6, Claude Opus 5, and Fable 5, but it is unclear whether these are accessed through holaOS's own service or third-party endpoints. BYOK is supported for OpenAI and Anthropic-compatible endpoints. Any MCP server can be plugged in. The actual setup steps require reading the docs, but the intended path is graphical, not terminal-based.

The BYOK and Model Flexibility Trade-off

holaOS lets you choose the model per task. You can use built-in models with "zero-setup default," or bring your own keys for OpenAI, Anthropic, or compatible endpoints. That is useful for cost control and for compliance, because your keys run on your account, not on a holaOS plan. But there is a hidden complexity: if you use built-in models, where do the requests go? The README says "one account, every model," which suggests a hosted proxy. That contradicts the "local-first" claim if prompts and data are sent to a third-party model provider. You must decide whether the built-in models are acceptable for your data policy. BYOK mitigates that, but then you must manage keys and rate limits yourself.

Limitations and Wrong-Tool Scenarios

The most obvious limitation is the license. The repository metadata says License: NOASSERTION, though a LICENSE file exists at the repository root. NOASSERTION means no recognized license was detected. You cannot assume you have the right to use, modify, or redistribute the code without reading the actual license file. This alone makes holaOS unsuitable for organizations that require a standard permissive or copyleft license. The latest release is dated 2026-08-06 and the last push was on 2026-10-28. For a production deployment, you would be betting on a small team's continued support. Also, because it is an Electron app, it consumes significant memory and CPU, which may be a problem on older machines.

Alternatives: Open-Source Agent Harnesses vs. Managed Platforms

One alternative is a custom MCP client built on the Model Context Protocol; holaOS differs by providing a GUI with side-by-side app surfaces. holaOS's differentiator is that it is local-first and lets you run Claude Code or Codex side by side, sharing memory and tools. That is not possible in a managed platform that only supports its own agent. If you only need a single agent with a few tools, a plain MCP server and a terminal agent might be simpler. But if you want a visual workspace where the agent can drive real applications, holaOS is built for that.

Maintenance and Upgrade Cost

The maintenance cost is not well documented. The last push was on 2026-10-28, so track releases and test new versions. The Electron base means that each upgrade may bring changes to the app shell, and the MCP and integration landscape evolves quickly. The README mentions a Discord and an X account. For enterprises, this means you need internal expertise to handle breakage. The license ambiguity adds a legal maintenance burden: you cannot confidently fork or patch the code without legal review. Upgrading may also require re-approving OAuth connections if the app's authentication flow changes.

Editorial conclusion

Adopt holaOS if you need a self-hosted, local-first workspace where multiple agents share the same tools, apps, and memory, and you are comfortable assembling your own integrations. Do not adopt it if you require a permissive open-source license or a mature, battle-tested product; the NOASSERTION license and recent release dates demand careful review. Before committing, verify the exact license terms, check the documentation for supported model endpoints and MCP server configuration, and test with a non-critical workload to confirm the side-by-side app interaction meets your needs. The project is promising for enterprises that want control, but it is not a drop-in replacement for a managed agent platform.

Frequently asked questions

Official sources

1. holaboss-ai/holaOS on GitHub
2. Issues
3. Project website
4. README
5. Releases