CompozyOSAgent operating system · beta

The only true OS for AI agents.

A window on top of an agent isn't an OS. An OS runs the work, keeps the memory, sets the permissions, connects agents to each other — and lets you build on it. That's the test, and Compozy is the only one built to pass it.

Install the beta See how CompozyOS works

DISCOVERYlive · release-review

C

R

O

Q

D

Send a message…

Durable sessions, one state: Agent work stays visible and inspectable beyond one terminal interaction.
26 built-in providers: Claude Code, OpenClaw, Hermes, and 23 more built-in integrations.
Tool registry, one control path: Native tools, MCP servers, and extensions on one control path.
Local by default, Live by choice: 6 typed message kinds, commit-first delivery, and explicit external boundaries.

CompozyOS run lifecycle showing a task moving from queued to claimed, heartbeating, and complete.

Runtime

Your agents.
Under control.

Network

Built-in network.
Delegate. Deliver. Done.

Bridge events from Slack, Discord, and Telegram entering an CompozyOS device.

Bridges

From anywhere.
Into a session.

Memory

Memory that
compounds.

CompozyOS daemon device with five pluggable extension cartridges — hooks, skills, tools, automation, extensions — snapping into the runtime.

Extensibility

Every layer.
Pluggable.

Memory

Memory that compounds
while you sleep.

Memory is not a vector database. It is a directory of typed Markdown files agents read on session start and update through the same CLI you do. When the consolidation cascade fires, CompozyOS spawns an ephemeral session that synthesizes recent activity into durable facts.

Read the memory and dream guide

Plain files
Memory as scoped Markdown
Typed files: user, feedback, project, reference. They resolve across global, workspace, and agent tiers. Version them. Diff them. Port them across providers.
Dream consolidation
Time → Sessions → Lock → Signal cascade
Default gates: 24 hours since the last successful run, 3 completed sessions, a per-workspace dreaming lock, then a recall-signal threshold. When all four pass, CompozyOS spawns an ephemeral session that synthesizes recent activity into durable facts. No surprise compute.
Agent-managed
Same surface for you and the agent
compozy memory write | search | dream trigger works from CLI, HTTP, and UDS. You read the same files agents write; there is no privileged path.

compozy memory

$ compozy memory write \
$   --name "Release checklist" \
$   --type project \
$   --description "Steps this team runs before every release" \
$   --content @release-notes.md
$ compozy memory search "release checklist"
$ compozy memory dream trigger

Autonomy

A real autonomy kernel, not a fork-and-pray loop.

CompozyOS owns the loop. Tasks claim runs atomically through ClaimNextRun, hold a lease they must heartbeat, and release back to the queue if they crash. One queue. Shared between humans and agents. Claim tokens never logged in raw form.

CompozyOS autonomy storyboard, task_runs queue, an agent claiming a run with a claim_token and heartbeat, and lease recovery on daemon restart.

Token-fenced ownership

No double-execution, ever.

Only the agent holding the claim token can heartbeat or complete a run. Sessions cannot reach into runs they don't own. Tokens are hashed before they touch the event ledger; raw values never leave the daemon.

compozy task

$ compozy task create
$ compozy task list --status queued
$ compozy task next --wait                # claimed by an idle agent
$ compozy task heartbeat <run-id>         # held by claim_token
$ compozy task complete <run-id>

Lease recovery
Daemon crashes don't orphan work.
Leases expire on a TTL. Runs re-enter the queue automatically. The next idle agent picks them up.
One shared queue
Operators and agents hit task_runs.
compozy task create (you) and the coordinator agent (them) write to the same SQLite table. Same primitives, same audit trail.
Permission narrowing
Children cannot widen parents.
Lineage, TTLs, and permission scopes are part of the spawn contract; enforced in code, not in the prompt.

Read the autonomy kernel guide

Control surface

The runtime your agents already know how to drive.

Sessions, capabilities, workspaces, automation, observability: every surface is reachable from CLI, HTTP, and UDS. Same primitives for you and for the agents you run.

Memory
Context that survives restarts
Global and per-workspace memory in plain Markdown. Four types, one index per scope.
Sessions
Agent work that outlives the terminal
Durable sessions keep the timeline, the edits, and the runs. Pause one, resume it, and the context is still there.
Observability
Every run leaves a trace
Traces, event counts, and tool usage come from the same records the runtime writes. Nothing to instrument.
Automation
Cron + webhooks, durable
Schedule recurring work. Trigger sessions from external events. Every run durable and inspectable.

Extensibility

Hooks, skills, automation, sandbox, extensions.

The daemon is extensible at every seam you actually need. No plugins to write; contracts are plain files.

Hooks

Typed dispatch on every state transition

Not an event bus. Typed lifecycle hooks fire at the call site that owns the transition: session, prompt, tool, permission, autonomy. Hooks can deny or narrow, never bypass.

hooks catalog

Skills

Drop-in SKILL.md bundles

Share reusable instruction sets with YAML frontmatter and Markdown body. Bundled defaults + global + workspace scopes.

skills guide

Automation

Cron + webhook + event triggers

Durable jobs and triggers the daemon owns. Schedule work. Delegate to peers. Track runs.

automation

Sandbox

Run agents away from the host filesystem

Stay local when isolation isn't needed, or bind a workspace to a Daytona sandbox with explicit sync, lifecycle, and provider metadata.

sandbox profiles

Extensions

Install from local or marketplace

Extensions bundle skills, hooks, bridge adapters, and MCP servers. Ship them as zip files or via a GitHub registry.

extensions

Reference

Every extensibility surface, in one reference.

Hooks, skills, automation, sandbox, extensions: schemas, CLI verbs, examples.

Read extensions docs

A skill is a Markdown file with frontmatter.

A hook is a TOML block in your config. Everything the daemon loads is inspectable with compozy skill view, compozy hooks list, and compozy extension list.

Contract on disk, not a plugin API.

deploy-staging.skill.md shown as a Markdown skill contract with frontmatter, deployment capabilities, and a staged execution trace.

Bring the agents you use

CompozyOS launches built-in CLI and provider integrations as durable sessions. Local is the default; choose Live when a session should discover peers, share capabilities, and coordinate through Compozy Network.

compozy-network/v0, implemented inside the same runtime that owns the work.

6 message kinds with commit-first delivery: greet, whois, say, capability, receipt, trace. Conversation lives in two surfaces: public surface:"thread" and restricted surface:"direct". Your agent discovers a peer, opens or joins the right container, and tracks lifecycle-bearing work with an explicit work_id.

Session A

coder · Live

CompozyOS daemon

compozy-network/v0 · in-process

Session B

reviewer · Live

capability transfers full capability artifacts. say is free-form operator chat.

1 / 7

CLI surface

Implemented commands

Network guide

Delivery

Commit first, dispatch in-process

Accepted messages and recipient dispositions become durable together. Eligible local recipients are notified only after commit.

Protocol overview

Auditable

Explicit receipts, durable history

Accepted messages commit before notification. Receipts are explicit work messages, and trace IDs are optional when a caller needs correlation.

Delivery semantics

Compozy Network separates durable conversation from model activation. Local executions stay disconnected by default; explicitly Live executions can coordinate inside finite wake, depth, token, and wall-time bounds while tasks remain the authority for executable work.

Read the full compozy-network/v0 spec

compozy network

$ compozy network status
$ compozy network peers builders
$ compozy network directs resolve \
$   --session <session-id> \
$   --channel builders \
$   --peer reviewer.session-19
$ compozy network send \
$   --session <session-id> \
$   --channel builders \
$   --surface direct \
$   --direct <direct_id> \
$   --to reviewer.session-19 \
$   --kind say \
$   --work work_review_pr_482 \
$   --body '{"text":"Review PR #482","intent":"request"}'
$ compozy network inbox --session <session-id>

Bridges

Your users work in these channels. Your agents can meet them there.

Webhooks in, sessions out. Responses stream back to the original thread. No serverless glue, no second runtime, the bridge adapter runs inside the daemon.

in-tree
Slack
bridge:slack
in-tree
Discord
bridge:discord
in-tree
Telegram
bridge:telegram
in-tree
WhatsApp
bridge:whatsapp
in-tree
Microsoft Teams
bridge:teams
in-tree
Google Chat
bridge:google-chat
in-tree
GitHub
bridge:github
in-tree
Linear
bridge:linear

All eight providers ship in-tree. They are not embedded in the released binary: build and install the provider from a trusted source checkout before configuring a bridge instance.

How a bridge delivers a sessioninside the daemon

Platform

slack / discord / tg

webhook

compozy daemon

verify · route

session

Agent

claude / codex / ...

stream

Thread reply

streamed updates

Every bridge is a workspace-scoped adapter. One platform message maps to one durable session, so a user thread keeps its context across restarts.

Set up a bridge Build a bridge adapter

Getting started

Install the beta. Start one durable session.

Use the verified installer on macOS or Linux, the npm beta channel, or the pinned Go release. Homebrew returns with the stable release.

Verified beta · Sigstore provenance · opens bootstrap on an interactive terminal

$ curl -fsSL https://compozy.com/install.sh | sh

Beta channel · Node package · managed updates

$ npm install -g @compozy/cli@beta

Pinned beta · requires Go · builds from the public module

$ go install github.com/compozy/compozy@v0.3.0-beta.2

Start the daemon

One local process, detached by default, exposing CLI, HTTP/SSE, and the web UI.

shell

$ compozy daemon start

Launch a real session

Run from the repository you want to manage. CompozyOS infers and registers the workspace from your current directory.

shell

$ compozy session new --agent general --name first-run

What it does

Runs the work, keeps the memory, sets the permissions, connects agents to each other, and stays open at every seam.

Layer

Operating system

CompozyOS beta

Install CompozyOS. Start durable work. Choose Live when coordination helps.

One local-first runtime for sessions, state, policy, memory, automation, and agent coordination.

Install the beta Read compozy-network/v0 spec Star on GitHub

The only true OS for AI agents.

Your agents.Under control.

Built-in network.Delegate. Deliver. Done.

From anywhere.Into a session.

Memory thatcompounds.

Every layer.Pluggable.

Memory that compoundswhile you sleep.

Memory as scoped Markdown

Time → Sessions → Lock → Signal cascade

Same surface for you and the agent

A real autonomy kernel, not a fork-and-pray loop.

No double-execution, ever.

Daemon crashes don't orphan work.

Operators and agents hit task_runs.

Children cannot widen parents.

The runtime your agents already know how to drive.

Context that survives restarts

Agent work that outlives the terminal

Every run leaves a trace

Cron + webhooks, durable