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 on macOS (Apple Silicon and Intel), Windows, and Linux. 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 shared memory is a central component, though the README is truncated before explaining its implementation details.

Getting Started: Clicks, Not Config Files

The README emphasizes "set up in clicks, not months." The quick start section is not fully shown in the provided material, but the documentation URL is given: https://www.holaos.ai/docs/getting-started. Based on the repository layout, you would download a release from the GitHub releases page (the latest is dated 2026-08-06) and run the Electron app. There is no command-line installation described in the README, only a marketplace inside the workspace. 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. MCP servers can be brought in by URL. 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. The README also mentions "Fable 5" as a model, which is not a widely known name; it may be a fictional or very recent model. Verify the actual model list before relying on it.

Limitations and Wrong-Tool Scenarios

The most obvious limitation is the license. The repository metadata says License: NOASSERTION, while the README badge claims "Modified Apache 2.0." That is a red flag. A modified Apache 2.0 license is not standard open source, and NOASSERTION means the repository does not declare a recognized license. You cannot assume you have the right to use, modify, or redistribute the code without reading the actual license file, which is not included in the provided material. This alone makes holaOS unsuitable for organizations that require a standard permissive or copyleft license. Another limitation is that the README is truncated, so the full feature set and any disclaimers are unknown. The project is also young; the latest release is from August 2026, and the last push is a few weeks later. There is no evidence of long-term maintenance or a large community. 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

The closest alternative is an open-source agent harness like AutoGPT or a custom MCP client built on the Model Context Protocol. The difference is that holaOS provides a full GUI with side-by-side app surfaces, while AutoGPT is a command-line agent loop that lacks a built-in app viewer. Another alternative is to use a managed platform like LangChain's LangSmith or a commercial product like Copilot Studio, but those are cloud-hosted and often lock you into their agent runtime. 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 one of the few open-source options that attempts this.

Maintenance and Upgrade Cost

The maintenance cost is not well documented. Since the project is under active development (last push in August 2026), you can expect frequent updates, which means you must 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, but no formal support SLA. 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. There is no mention of a migration path or data export, so you should assume that your shared memory and app configurations are tied to the holaOS data format. Before adopting, confirm that the project provides a way to back up and restore your workspace data.

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.

Official sources

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