Public alpha

Make AI work accountable.

Run one task. Watch Orcho plan, implement, reject false-ready work, repair it, and prove what is ready to deliver.

Orcho is the production harness and control plane around the coding agents you already use. They remain the workers; Orcho owns the delivery protocol, gates, evidence and final readiness decision around them.

Install the public alpha Run a pilot with us

Three commands to the first result. Deterministic mock mode runs the real Orcho CLI and lifecycle: reject false-ready work, repair it, and close with a green receipt. Click to pause.

Why now

Agent sessions got good. Delivery stayed unaccountable.

A strong agent session still ends as a transcript: no durable plan, no gate result, no record of who accepted what. Real work crosses repos, tools and reviewers — and the proof of readiness evaporates at every handoff.

The worker says done A coding agent can finish its session without proving the change is ready to deliver. Confidence is not a release gate.

The record disappears Plans, decisions, retries and review context remain trapped in private sessions. The next person inherits a patch, not the reasoning that produced it.

The boundary stays unseen Frontend, backend, mobile, data and infrastructure can all pass locally while the product fails where their contracts meet.

The human reads everything Without typed verdicts and drill-down evidence, the operator becomes the integration layer — rereading monologues, reconstructing state and deciding what was actually checked.

How Orcho works

One task becomes an accountable delivery run.

Orcho does not replace the coding agents you already trust. It gives their work a semantic shape, a visible pipeline and gates that can change what happens next. The result is one durable record: intent, plan, diffs, findings, decisions, cost and evidence.

One real feature profile

Pipeline

 ⟳² ( ▶ plan [Claude]  →  validate_plan [Codex] ) →  implement [Claude]  →  ⟳² ( review_changes [Codex]  →  repair_changes [Claude] ) →  final_acceptance [Codex]

Agents

PLAN claude-opus-4-7 high

VALIDATE_PLAN gpt-5.5 medium

IMPLEMENT claude-opus-4-7 high

REVIEW_CHANGES gpt-5.5 medium

REPAIR_CHANGES claude-opus-4-7 high

FINAL_ACCEPTANCE gpt-5.5 low

DELIVERY PROTOCOL

The workflow is explicit before code starts.

Profiles declare phases, workers, bounded loops and gates. A weak plan can be rejected before an implementation worker mutates the checkout.

/platform/agent-delivery-protocol/

CONTROL FLOW

Review can stop false-ready work.

A rejection is not a comment after the fact. It routes the run to repair, asks for a human verdict or keeps delivery blocked with named findings.

/use-cases/review-gates/

DURABLE EVIDENCE

The proof survives the session.

Plans, diffs, events, verification receipts, costs and handoff decisions remain inspectable by the next engineer, operator or tool.

/platform/evidence-and-governance/

Docs-backed demos

Watch the protocol, then inspect the receipt.

These are public recordings of the actual CLI surface. Pause the run here, then open the linked documentation for the phase rules, artifacts and controls behind it.

LIVE CLI

The run is readable while it is still alive.

Orcho turns the agent session into an operating surface: envelope, phase map, plan review, implementation, final acceptance and closing receipt.

A reviewer can see the active contract before code changes: profile, workers, verification policy and evidence paths.
Rejected planning rounds stay in the same record instead of becoming lost chat history.
The closing rollup explains what shipped, what it cost and which gates backed the verdict.

Read the live-run guide

Source recording is hosted by the public docs. This page frames the product reason; the docs page explains the stream anatomy.

ANY MODEL

The delivery protocol is not tied to one vendor's model.

This run routed every phase — plan, validation, a four-subtask implementation DAG, review and final acceptance — through a GLM-compatible worker on a non-Anthropic model, and still produced the same contract, gates, attestations and a real pull request.

Runtime identity stays visible in the record: the run reads as glm-5.2, not hidden behind the original CLI name.
Plan contract, per-criterion attestations and the verification gate hold regardless of which model does the work.
It proves portability, not a routing default: spend top-model reasoning where it matters and keep review independent of the author.

Read runtime adapters

The docs page explains the adapter boundary; Symphos uses the same asset to show the protocol is model-neutral end to end.

Small demo

Every suite is green. The product still fails.

A deliberately small reproduction of an expensive failure class: the API producer renames a payload key; the web consumer still reads the old one. Both suites stay green, because the break lives between the repositories — where no single-repo session ever looks. Orcho's cross-run contract check looks exactly there, and rejects the delivery before anything ships.

A clean local fix can still leave the product broken. Local success is not delivery.

Single-project runs make one repository healthier while the product state stays unknown.
The failure lives at the boundary: field names, contracts, consumer assumptions, rollout state.
Orcho's bet: make the delivery run — not the repo — the unit that must be proven ready.

Read cross-system delivery

cross-repo feature

One user flow can pass every local check and still break in the product.

API, web, review and rollout each see a slice. The failure lives between the slices.

Add a user Provision a new user record. Alice Doe [email protected] Create user HTTP 500 KeyError: 'email'

separate chats see separate truth

agent chat repo: api "Looks fixed. Tests pass."

agent chat repo: web "Form still sends the old field."

local signals look green

api terminal cd api && python -m pytest -q 31 passed in 0.08s

web terminal node --test tests/contracts.test.mjs pass 5 / built in 350ms

Runtime economics

Spend top-model reasoning where it changes the outcome.

The strongest coding models are excellent at planning, judgment and final risk calls. Orcho lets teams keep that intelligence in the high-leverage phases while routing bounded implementation and repair through cheaper compatible workers under independent review.

PHASE POLICY

Do not buy one model for every phase.

Use one worker for planning, another for implementation, and a separate reviewer for acceptance. Runtime choice becomes delivery policy, not shell folklore.

/platform/runtime-economics/

GLM-COMPATIBLE

Make lower-cost execution visible.

When implementation runs through a GLM-compatible Claude wrapper, the run record can still show a distinct runtime identity instead of hiding it behind the original CLI name.

https://docs.orcho.dev/operate/runtime-economics/

REVIEW LOOP

Keep savings under supervision.

A cheaper implementation worker is useful only when another phase can reject the result, request repair and leave the decision in the evidence bundle.

/platform/evidence-and-governance/

Read runtime economics Open the technical guide

Proof direction

The proof is a run record, not a claim.

The strongest proof is a real one: an Orcho engine feature shipped through a full-spend Orcho run, hands-off, with the delivery receipt published as-is — review rounds, repair rounds, gates, cost split and scope flags on record. The recorded demos around it show the same mechanics in isolation.

Open the proof hub

REAL RUN, FULL RECEIPT

One command. 2h 45m hands-off. Approved, with receipts.

Not a demo: a real engine feature shipped at full spend — 7 review rounds, 5 repair rounds, one P1 caught and fixed, every blocking gate green.

/proof/run-receipt/

FALSE-READY, CAUGHT

The worker says done. The gate disagrees.

A live recording: review rejects with a named blocker, the run stays blocked, repair resumes the same record.

/proof/false-ready/

CROSS-SYSTEM

One spec. Two repositories. One verdict.

A live recording: a cross run plans once, works per repo, and the contract check judges the boundary.

/proof/cross-system/

SIGNAL, NOT PROSE

Typed verdicts over monologues.

Rendered from a run's own artifacts: findings with severity, one-line verdicts, drill-down on demand.

/proof/signal-not-prose/

Start small

Use it today. Bring us in when the workflow deserves it.

The public alpha is self-serve. Start with one repository and one real task. When the pain spans systems, ownership or review policy, bring that workflow to a pilot instead of evaluating from a slide deck.

SELF-SERVE

Run one task on your machine.

Install from PyPI, initialize a workspace and watch the live CLI move from plan to final acceptance.

Open the quickstart

TEAM PILOT

Bring one painful delivery path.

Use a real cross-repo change, an unreliable handoff or a review step nobody trusts. We will test the protocol against the work.

Discuss a pilot

typed plan cross_plan.md

gate findings review_changes.json

run diff diff.patch

event spine events.jsonl

cost split metrics.json

handoff decision phase_handoff.json

Go deeper

Start with one run. Add control only when the work deserves it.

The documentation moves from a light mono-run to profiles, gates, recovery, MCP control and cross-project delivery — with the real CLI surface and artifacts attached.

Open the technical path