Project status
Evaluating a tool means evaluating its continuity. This page collects the facts an evaluator needs in one place: who is behind Orcho, what “preview” means, what you can rely on today, and where the current scope boundary is.
Who builds Orcho
Section titled “Who builds Orcho”Orcho is built by Symphos (symphos.ai, GitHub org
symphos-ai) — a company building a
local-first control plane that turns scattered AI agent sessions into
coordinated, provable delivery runs.
License
Section titled “License”The public Orcho packages — including
orcho-core (the pipeline
engine) and orcho-mcp (the MCP
server) — are released under Apache-2.0.
Two practical consequences for lock-in assessment:
- the engine you run is open source under a permissive license;
- everything a run produces is plain local files — JSON, patch, and log artifacts in a run directory you own. There is no service-owned store to migrate off. Artifact reference documents the exact layout.
What stage this is
Section titled “What stage this is”Orcho is in public alpha: released, installable by anyone, not yet
stable. The packages are published on PyPI —
orcho (the recommended installer),
orcho-core, and
orcho-mcp — and
pipx install orcho is the default native install path. Docker is the isolated
trial and containerized MCP path, and pip install orcho is available for
managed environments. The umbrella package installs the core CLI and the MCP
server (Installation methods).
“Alpha” means pre-1.0: the protocol is real and exercised daily, but surfaces
may still change between releases, and the “preview status” notes in these
docs mark where.
The docs on this portal track the current engine — reference pages are
maintained against the actual source (orcho <command> --help and the
in-repo engineering docs stay authoritative), and each architecture page
deep-links its canonical doc in the code repository.
What is treated as a contract
Section titled “What is treated as a contract”Stable enough to build against today:
- The run directory layout —
meta.json,events.jsonl,evidence.json,diff.patch, receipts. Post-mortem tooling and the MCP surface read the same files (Artifact reference). - Event kinds as wire shape — kinds are not renamed without a migration; adding optional payload fields is compatible; adding a required key to an existing event is a breaking change (Event stream reference).
- The delivery protocol itself — phases, gates, receipts, delivery decisions — is the product; it evolves by addition, not by quiet redefinition.
Still moving before a stable release: some command and flag naming, and the pace at which new surfaces are added.
Those same artifacts, rendered — the per-subtask accounting of one real
feature run, read straight from its metrics.json:
Nothing here is a dashboard the product had to build — it is a projection of
the run’s own events.jsonl / metrics.json, the
files listed above. The run is the record.
Where the scope boundary is
Section titled “Where the scope boundary is”Orcho is currently a per-machine, single-operator control plane:
- no central RBAC or tenant-wide audit platform — the audit trail is the run directories on each machine;
- artifact retention is a project/workspace decision, not a managed service;
- run directories are plain files, so shipping them into your own storage, SIEM, or review tooling is a straightforward integration you own today.
For technical leaders covers how to evaluate within that boundary; Security and privacy traces exactly what stays local and what reaches worker-runtime providers.