Runtime Overview
What Compozy Runtime is, why it exists, and when it's the right operating model for your agent work.
- Audience
- Operators running durable agent work
- Focus
- Runtime Overview guidance shaped for scanability, day-two clarity, and operator context.
Compozy is the runtime you reach for when one-off terminal sessions stop being enough. It takes the agent CLIs you already trust — Claude Code, OpenClaw, Hermes, and others — and turns them into durable work with replayable history, workspace-aware memory, automation, and one control surface across the CLI, HTTP/SSE, and the web UI.
You can call Compozy an agent operating system, but the useful part of that label is not the metaphor. It is what the runtime actually gives you: agent work that stays alive, inspectable, and governable after the terminal window is gone.
Start by job
Choose the right docs path
Use this when you are unsure whether you need a tutorial, guide, use case, concept page, CLI reference, or API route map.
Run your first durable session
Start the daemon, register a workspace, create one session, follow events, stop it, and resume it.
Move from v0.2.15 to v0.3
Map legacy commands, configuration, skills, extensions, SDKs, and runtime state onto the v0.3 hard cut.
Solve an operator problem
Choose a surface, debug a failed session, or coordinate agents through Compozy Network without reading every subsystem page first.
Start from a real operating scenario
Review a code change, run a release readiness sweep, or hand off work between agents with concrete commands and evidence checkpoints.
Understand the runtime model
Read the operating model behind sessions, workspaces, agents, memory, tools, automation, hooks, and extensions.
Look up exact commands
Use the generated CLI reference for flags, output formats, subcommands, and command-specific examples.
The problem Compozy solves
Most agent CLIs are excellent at doing work inside one session, but weak at everything around the session:
- the run disappears when the terminal closes
- there is no clean replay or audit trail
- each project needs its own context, defaults, and guardrails
- coordinating multiple specialized agents turns into custom glue code
- operators end up stitching together scripts, logs, and dashboards that never become a product
Compozy fills that gap with a local-first runtime that keeps work durable and observable without asking you to abandon the agent CLIs you already use.
What Compozy Runtime adds
Run real agent CLIs as durable work
Compozy does not reimplement agent logic behind API wrappers. It orchestrates real agent CLIs as managed sessions, so Claude Code stays Claude Code, OpenClaw stays OpenClaw, and Hermes stays Hermes.
That matters because you keep the native tools, context behavior, and interaction style of each agent instead of flattening everything into one abstraction layer.
Keep sessions durable, replayable, and auditable
Each session becomes a durable unit of work. You can stop it, resume it, inspect the event history, and reconstruct what happened when a run needs review or recovery.
Instead of losing the context after a crash, restart, or handoff, Compozy keeps the operational record around the work itself.
Standardize behavior per workspace
Compozy layers configuration, memory, and skills around the workspace, so each project can carry its own defaults without forcing one global setup to fit every team and repository.
That gives operators a cleaner way to keep agent behavior consistent without rebuilding prompts and context on every run.
Operate from one control surface
The same runtime is available through the CLI, HTTP/SSE, and the web UI. Sessions, memory, automation, bridges, and observability live in one local control plane instead of a pile of separate tools.
Add Compozy Network when agents need to coordinate
Compozy Runtime is only half the story. When you need specialized agents to discover peers, delegate work, exchange updates, and report results cleanly, Compozy Network provides the open coordination layer behind the runtime.
That layer is intentionally separate: Compozy ships the reference implementation, but the network boundary is documented so other runtimes can adopt it too. Agents can publish capability catalogs so peers discover outcomes instead of internal tool names.
Under the hood, Compozy runs as a single local daemon that manages sessions, persists events, and talks to compatible agents through a standardized protocol layer. The operating model matters more than the internals — head into Sessions when you want the package-level view.
Why Compozy vs. other models
The AI agent ecosystem is crowded. The useful question is not "which project exists," but "which operating model are you actually buying into?"
Compozy is the local-first runtime for durable agent work, plus Compozy Network — the open agent network protocol for interoperable coordination across runtimes. That is a different lane from a channel-native assistant, a hosted gateway, or a framework for building custom orchestration from scratch.
| Operating model | Best fit | Where Compozy differs |
|---|---|---|
| Personal assistant or channel-native helper | You want one assistant surface that lives inside chat tools and user-facing channels. | Compozy focuses on durable runtime governance and an open agent network, not on being one assistant persona everywhere. |
| Hosted or multi-tenant gateway | You need a centralized control plane, shared tenancy, and platform-style operations. | Compozy stays local-first and self-hosted on the machine doing the work. |
| Agent framework | You want to design custom reasoning loops, graphs, or orchestration logic from scratch. | Compozy manages real agent CLIs you already use instead of asking you to rebuild them as a framework abstraction. |
| Tool protocol only | You need one agent to talk to tools and resources. | Compozy covers runtime behavior and durable sessions; Compozy Network is the open agent network protocol. |
| Durable agent runtime | You want local sessions, replay, memory, automation, and operational control around real agent CLIs. | This is Compozy's primary lane. |
Most alternatives optimize for one of these lanes: assistant surface, hosted gateway, framework for custom orchestration, or protocol for tool access. Compozy sits at a different seam — Compozy Runtime gives operators durable sessions, replay, memory, automation, and observability around real agent CLIs, while Compozy Network gives the ecosystem a protocol boundary for discovery, delegation, and structured coordination.
When Compozy is the right choice
Compozy is a strong fit when you:
- run real agent CLIs and need them to behave like durable work instead of ephemeral chat
- want replay, auditability, and observability without bolting on external control planes
- need project-specific memory, policies, and behavior without rebuilding prompts every time
- expect specialized agents to coordinate later and want that future to stay open
When another lane may fit better
- Choose a channel-native assistant product if the main job is user-facing help inside chat tools.
- Choose a hosted gateway if the main job is centralized multi-tenant operations.
- Choose an agent framework if the main job is building custom orchestration logic from the ground up.
- Choose a protocol-only layer if the problem is tool connectivity, not runtime control or coordination.
Compozy exists for the gap between those categories: durable runtime governance for real agent work, paired with an open coordination layer that does not have to stay Compozy-only.
What Compozy is not
- Not an agent framework. Compozy does not ask you to rebuild your agents as chains, graphs, or wrapper abstractions.
- Not an API wrapper. The point is to keep real agent CLIs intact, not to flatten them into thin model calls.
- Not a hosted control plane. Compozy is local-first. The runtime lives on your machine and keeps data close to the workspace.