CompozyOS: A daemon-centric control plane for AI agents, still in beta

The problem: agents are easy to prompt, hard to run continuously

The README states the core problem plainly: anyone can prompt an agent, but making agents work continuously is an engineering project. You need loops, triggers, cron, memory, permissions, approvals, observability, and glue scripts. CompozyOS packages that entire stack into one product. It is built first for developers and technical operators who use agent CLIs such as Claude Code, OpenClaw, and Hermes. The audience is not end users; it is people who currently stitch together shell scripts and cron jobs around an agent. CompozyOS claims to replace that glue with a single daemon and a unified state model.

Daemon runtime model: one source of truth, many surfaces

The architecture centers on a home-scoped daemon. You start it with `compozy daemon start`, check it with `compozy status`, and stop it with `compozy daemon stop`. The daemon resolves the workspace, applies permissions and runtime policy, coordinates ACP agents, and persists events and resource state. Web and streaming clients read that daemon-owned truth instead of maintaining a parallel model. This is a meaningful design choice: closing a client does not erase work, because sessions and Loop runs belong to the daemon. The README emphasizes that sessions, tasks, Loop runs, memory, automation, tools, and Compozy Network activity have explicit owners and workspace boundaries. Structured output via `-o json`, HTTP/SSE, UDS, MCP, and native tools all expose the same state. The daemon is the single source of truth, and every control surface is just a view into it.

Installation: beta channels only, with a Go version trap

Installation is straightforward but carries a caveat. The verified installer pins the latest published beta and verifies Sigstore provenance on macOS or Linux: `curl -fsSL https://compozy.com/install.sh | sh`. NPM users get `npm install -g @compozy/cli@beta`. Go users face a trap: `go install github.com/compozy/compozy@latest` still resolves the v0.2 stable line while v0.3 is in beta. The README instructs you to install with the explicit tag shown on the latest release, for example `go install github.com/compozy/compozy@v0.3.0-beta.21`. Homebrew still serves the deprecated v0.2 line and is intentionally omitted during the beta window. From source, you clone, `cd compozy`, and run `go build -o ./bin/compozy .`. The configuration files live in `~/.compozy/config.toml` with workspace overrides in `.compozy/config.toml`, and command flags win over workspace, which wins over global and built-in defaults. You can inspect config with `compozy config path`, `compozy config validate`, and `compozy config show -o json`.

Reusable agents and Task Schema v2: a break from v0.2

Agent definitions live under `~/.compozy/agents/<name>/` or `.compozy/agents/<name>/`, each with an `AGENT.md` and optionally an agent-local `mcp.json`. Workspace definitions override global definitions as a whole. You list agents with `compozy agent list -o json`, inspect one with `compozy agent info general -o json`, and start a session with `compozy session new --agent general`. Task files remain portable Markdown with typed frontmatter, but the v0.3 runtime imports them into durable tasks and executes them through Loops. It does not revive the v0.2 `tasks run` pipeline. This is a hard break. The README points to MIGRATION_GUIDE.md for the exact schema and command changes. If you have existing v0.2 task files, they will not run as-is. The v0.2.15 product is deprecated and maintained only for critical fixes on the `legacy/v0.2` branch. This is a genuine migration cost, not a cosmetic rename.

Extensions: code-first or resource-only, with a three-command start

Extensions add versioned resources and runtime behavior through declared provide surfaces. The daemon owns discovery, enablement, trust decisions, lifecycle, and hooks; extensions do not bypass public runtime contracts. The README shows a three-command build: `compozy extension init hello --template tool-provider-go`, `compozy extension dev hello`, then `compozy tool invoke ext__hello__search --workspace . --input '{"query":"compozy"}'`. Executable extensions are code-first: you declare the tool once in code and `compozy extension build` generates the manifest. Resource-only extensions can hand-write `extension.toml` and use the same build, dev, reload, and watch loop without running extension code. SDK support includes `@compozy/extension-sdk` (npm, MIT) and `github.com/compozy/compozy/sdk/go`, both version-matched to the daemon. Extension CLI commands include `compozy extension list -o json`, `compozy extension status <name> -o json`, `compozy extension provenance <name> -o json`, and `compozy extension logs <name> --follow`. The provenance command is notable: it suggests a trust model for third-party extensions, which is a real concern when extensions can execute tools.

Automation and supervision: cron, webhooks, approvals, and memory as core objects

The README lists automation features: cron schedules, webhooks, and triggers keep work running with no terminal open. Approvals, permissions, run state, artifacts, and agent activity stay inspectable while work continues in the background. These are not plugins; they are core objects in the runtime. The daemon-owned state means a web client or a streaming client sees the same run state as the CLI. This is a different approach from running agents in a terminal and hoping they finish. The README also mentions Compozy Network, where sessions can discover peers, exchange typed messages, delegate work, and close it with receipts over `compozy-network/v0`. That is a peer-to-peer layer for agent communication, but the README gives no protocol details beyond the version string. The supervision model is the strongest part of the pitch: you can approve or deny actions, set permissions, and inspect artifacts without opening a terminal.

Local-first and remote access: explicit boundaries

CompozyOS is local-first by default. One Go binary and SQLite-backed stores keep runtime state on the operator's machine unless a configured provider or extension owns an external boundary. That means your agent sessions, memory, and loops live on your disk, not in a cloud service. Remote access stays explicit: the Gateway pairs devices and exposes only the private or public surfaces an operator enables. This is a deliberate contrast to hosted agent platforms. The trade-off is operational: you run a daemon, manage SQLite stores, and handle the Gateway yourself. The README warns that configuration, credentials, and provider-home policies have different owners, and tells you to follow the configuration guide instead of copying v0.2 state into a v0.3 home. That is a practical caution: the v0.3 home directory is not a drop-in replacement.

Limitations and the wrong tool cases

The most obvious limitation is the beta status. The v0.3 line is in beta, and the README itself warns about it. The previous v0.2.15 product is deprecated, so you cannot fall back to a stable line without losing v0.3 features. The Go install trap is another limitation: `@latest` resolving to v0.2 is confusing and could lead to installing the wrong version. The Task Schema v2 break means any investment in v0.2 task files is not directly reusable. CompozyOS is the wrong tool if you want a hosted, managed agent service with no daemon to operate. It is also wrong if you only use one agent CLI occasionally and do not need background sessions, cron, or approvals. The daemon and SQLite state add operational overhead that a simple terminal session does not. For a single developer running one-off prompts, the complexity is not justified.

Alternatives: the difference in approach

The closest alternative is running agent CLIs directly with your own orchestration. Claude Code and OpenClaw already run in a terminal; you can wrap them in shell scripts, cron jobs, and tmux sessions. The difference is that CompozyOS replaces that ad-hoc glue with a daemon that owns the state. Another alternative is a hosted agent platform like OpenAI's Codex or a managed MCP server, which handle state and scheduling in the cloud. CompozyOS is local-first, so you keep control of data and state, but you also keep the operational burden. A third alternative is using a general-purpose workflow engine like Temporal or Prefect to schedule and supervise agent calls. Those engines handle retries, cron, and state, but they do not understand agent sessions or ACP protocols natively; you would still write integration code. CompozyOS's bet is that agent-specific supervision, approvals, and memory are better as first-class objects than as workflow steps. The trade-off is lock-in to its state model and its beta maturity.

Editorial conclusion

Adopt CompozyOS if you run agent CLIs like Claude Code or OpenClaw regularly and want them to survive terminal closes, run on cron, and stay inspectable through a single daemon. Do not adopt it if you need stable production behavior today: v0.3 is beta, v0.2.15 is deprecated, and the migration path is explicit but breaking. Before replacing an existing v0.2 install, read MIGRATION_GUIDE.md and check that your task files convert to Task Schema v2. Verify that the Go install tag matches the latest release, since `go install @latest` still resolves v0.2, and confirm your extensions use the version-matched SDKs. The daemon model is sound, but the beta status and the v0.2 deprecation are real costs.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes