holaOS — Summary

holaOS is a macOS-first Electron desktop application that runs long-horizon AI work-streams in persistent "workspaces" — context-rich environments where agents have access to a shared browser, files, apps, tools, and runtime state. The "environment engineering" thesis: the environment an agent runs in defines its capabilities more than the prompts. Each workspace has goals, context, rules, sources, artifacts, history, and a control surface; corrections made during review become "visible rules" that the next run starts with. Sub-agents handle parallel subtask execution within a workspace.

holaOS distinguishes itself through the "workspace as a living entity" pattern: unlike Aperant's task-per-worktree or Multica's issue-per-agent, holaOS workspaces persist across runs with compounding improvements. The Modified Apache 2.0 license and macOS-only support (Windows/Linux in progress) limit adoption. Compared to claude-flow (closest seed), holaOS replaces the MCP toolserver with an Electron native runtime, and replaces SPARC phases with a "workspace + recurring run" model.

holaOS — Overview

Origin

Created by holaboss-ai organization. 5,418 stars, 8 contributors. Modified Apache 2.0 license. Node.js 24.14.1 runtime. Active as of 2026-05-26.

Philosophy

The core thesis is "environment engineering": "The difference in Beta 0.1 is the product loop. Instead of giving an agent one disposable session, you give each recurring work-stream a living workspace with its own memory, history, outputs, and control surface."

Key principles from README:

• "Turn repeat work into running AI work-streams"
• "When you review the output and correct it, those corrections become visible rules so the next run starts smarter than the last"
• "holaOS is an open agent computer: a shared environment where agents can use the same browser, files, apps, tools, and runtime state you do"
• Sub-agents help complex work move forward in parallel without manually juggling chats

Use Cases

Research Radar (weekly competitor tracking), Content Engine (founder notes → posts), Customer Voice (feedback aggregation), Launch/Campaign Workstream, Client Delivery Loop.

Architecture Thesis

"The environment defines the system" — workspace architecture (goals, context, rules, sources, artifacts, history) is the primary engineering primitive, not the prompt or the agent.

holaOS — Architecture

Distribution

• Type: Electron desktop application (macOS first; Windows/Linux in progress)
• Install: curl -fsSL .../install.sh | bash -s -- --launch (one-line macOS install)
• Runtime: Node.js 24.14.1 bundled

Directory Structure

holaOS/
├── apps/
│   └── desktop/          # Electron desktop app
│       ├── src/           # TypeScript UI + runtime client
│       ├── electron/      # Electron main process
│       ├── electron-builder.config.cjs
│       ├── vite.config.ts
│       └── CLAUDE.md
├── runtime/              # Portable runtime (can run without desktop app)
├── sdk/                  # holaOS app SDK
├── scripts/              # Build + install scripts
├── website/              # Documentation
├── AGENTS.md
└── bun.lock

Required Runtime

• macOS (primary; Windows/Linux in progress)
• Node.js 24.14.1 (or bun)
• No external dependencies for standard install

Config Files

• apps/desktop/.env (from .env.example)
• AGENTS.md, CLAUDE.md

Key Dependencies

• Electron (desktop app)
• React (UI, via @base-ui/react)
• better-sqlite3 (local workspace state)
• better-auth (authentication)
• @holaboss/app-sdk, @holaboss/editor, @holaboss/runtime-client (internal packages)
• Sentry (error reporting)

Target AI Tools

Not specified as wrapping Claude Code or Codex. holaOS appears to be its own agent runtime with model API access.

holaOS — Components

Workspace Model

Each workspace contains:

• Goals — what the work-stream aims to achieve
• Context — background information
• Rules — visible constraints (including corrections from previous reviews)
• Sources — data inputs
• Artifacts — outputs produced by runs
• History — log of all previous runs
• Control Surface — dashboard maintained by agent + human

Desktop UI Views

Sub-Agents

holaOS uses sub-agents within workspaces to parallelize complex work. Sub-agents handle research, drafting, verification, synthesis in parallel.

Runtime APIs

REST API for:

• Workspace CRUD
• Run management
• Streaming events
• App lifecycle

App SDK

@holaboss/app-sdk — allows building custom workspace apps on top of holaOS.

Independent Runtime

The runtime can be deployed without the desktop app (for server deployments).

holaOS — Uniqueness & Positioning

differs_from_seeds

holaOS's "environment engineering" thesis is distinct from all 11 seeds. The closest seeds are kiro (structured workspace files applied to every agent interaction) and claude-flow (persistent multi-agent environment), but holaOS combines both approaches in a novel way: workspace files accumulate user corrections as visible rules over multiple runs, creating an emergent per-workspace instruction set that grows more accurate over time. No seed in the corpus implements this feedback loop. Kiro uses static .kiro/steering/ YAML files set once; holaOS derives rules dynamically from user corrections. Claude-flow uses SQLite+vector memory for agent state; holaOS uses workspace rules as the memory layer. The "open agent computer" framing (agents use the same browser, files, and apps the user does) is also unique — no other seed positions the execution environment as a shared human-agent workspace.

Positioning

• Environment-first philosophy: the environment defines agent quality, not the prompts.
• macOS-native, Electron-first (unlike Multica which is web-first or TinyAGI which is daemon-first).
• Recurring work-streams as the primary unit (not one-off tasks).
• User corrections → visible rules → compounding improvement across runs.
• App SDK for extensibility (third-party apps can run inside workspaces).

Observable Failure Modes

1. macOS-only: Windows/Linux users cannot use holaOS yet.
2. Modified Apache 2.0: Non-standard license modification may restrict commercial use.
3. Beta 0.1 status: README explicitly describes this as Beta 0.1 — feature completeness and stability are limited.
4. Rules accumulation: No documented mechanism for pruning contradictory or stale rules — workspace rules may accumulate noise over many runs.
5. Unknown model support: No documentation on which LLMs are supported; may require specific API keys.