Public alpha

Agents can write code. Orcho proves whether delivery is ready.

Orcho runs cross-agent, cross-project work as one delivery record: a typed plan, executable gates, human verdicts, diffs and evidence that survive every agent session.

When a worker says done, the run stays blocked until a gate passes, a reviewer approves or a human explicitly accepts the risk. False-ready work does not ship by default.

Watch proof demo Run a pilot with us

mono_run / delivery-42

speclocked plantyped executeagent A gateagent B evidencestored handoffready

CLI MCP review CI

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.

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

Private execution AI work became daily engineering infrastructure, yet most of it still happens in private sessions nobody can replay, inspect or govern.

No delivery object A product change needs one accountable record: intent, plan, diffs, checks, decisions and handoff. A chat transcript is not that record.

One mind is brittle An agent reviewing its own work is a conflict of interest. Orcho routes planning, implementation, review and repair across different runtimes — Claude, Codex, Gemini or internal scripts — so the reviewer is never the author.

Wrong control depth A small task should stay light. Release-bound, cross-system work needs gates, evidence and explicit human verdicts. Depth should be a choice, not a property of the tool.

Review outside the loop Tests and review usually happen after the agent declares done — too late to change what the run does. In Orcho a rejection routes the run to repair or to a human. Review is control flow.

Declarative pipelines Profiles describe the workflow as data: phases, workers, loops, gates and review points. Use a ready profile for common task types, or declare your own.

What Orcho is

The delivery run is the durable object.

Workers change, disagree and fail — that is normal. What must survive is the run: plan, gate results, handoff decisions, diff, cost and evidence in one inspectable record that outlives every session that produced it.

PLAN

No plan, no code

The plan is reviewed — by another agent or a human — before implementation starts. Rejected plans stay in the record.

/symphos/agent-delivery-protocol/

HANDOFF

Handoff inside the run

A gate can pause the run, request repair, route to another worker or wait for a human verdict — without losing state.

/symphos/workflow-portability/

LOOP

Implement-review loop

Implementation, review and repair cycle inside the run until the reviewer approves or a human intervenes. The author does not grade its own work.

/symphos/cross-system-delivery/

EVIDENCE

Proof that survives

Diffs, events, metrics and decisions stay inspectable after the worker exits. The proof outlives the session.

/symphos/control-depth/

OBSERVABILITY

See the run live

Phase state, findings, retries, handoffs and evidence read as one timeline instead of scattered transcripts.

/symphos/evidence-and-governance/

RESUME

Recoverable pauses

A paused run resumes from its checkpoint with plan, history and evidence intact. A human decision is a state transition, not a restart.

/symphos/workflow-portability/

Small demo

Every suite is green. The product still fails.

A deliberately small reproduction of an expensive failure class: the API suite passes, the web suite passes, and the user-create form still returns 500 — because the contract drifted at a boundary no single-repo session could see.

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

Proof direction

The proof is a run record, not a claim.

The first public proof is a false-ready scenario: a worker says done, the gate rejects, the run stays blocked, repair resumes the same record. Orcho is also built this way — its own engine changes ship through Orcho runs, with review gates that have rejected real work. Video and deck assets are being prepared.

CROSS-PROJECT