Proof

Proof is a run record, not a claim.

These pages show the delivery record from different angles: one real full-spend run, two recorded demo runs, and screenshots rendered from run artifacts. The point is not a polished demo; it is whether a reader can inspect why the work was accepted or blocked.

Docs-backed demos

Selling points with the receipts behind them.

Each recording is hosted on the public documentation site. Symphos gives the buyer reason to care; the linked docs page explains the technical anatomy.

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
orcho run / real run streamdocs asset
Source recording is hosted by the public docs. This page frames the product reason; the docs page explains the stream anatomy.

PLAN GATE

A weak plan can be rejected before code starts.

The value is not a nicer checklist. A gate changes the run state: reject, re-plan, continue, pause or require a human decision.

  • Plan validation catches unclear scope before an implementation worker mutates the checkout.
  • Automatic retries are bounded, so control does not quietly turn into an infinite agent loop.
  • Findings resolve into evidence the final reader can inspect, not a vague memory of review.
Read plan contracts and DAGs
orcho run / plan rejected, then repaireddocs asset
The same recording powers the docs explanation of plan contracts; Symphos uses it to show why review belongs inside control flow.

CROSS-SYSTEM

The delivery unit can be the feature, not the repo.

For cross-system work, Orcho keeps one feature intent while projecting scoped runs into each repository and judging the boundary as one delivery.

  • API and web workstreams keep their local evidence while the cross-run keeps the shared verdict.
  • The contract check reads the seam between repositories, where single-repo success often misses product breakage.
  • Cross final acceptance blocks the set until the delivery, not just one patch, is ready.
Read cross-project projection
orcho cross / one feature across api + webdocs asset
The docs page explains the projection model; the selling point is simpler: the product boundary becomes visible.

MCP CONTROL

Your AI client can drive the run without owning the truth.

MCP gives an agent client typed controls over Orcho while Orcho remains the run system of record: start, watch, inspect evidence, return a verdict.

  • The client operates through typed tools instead of scraping terminal output.
  • Evidence and diff stay in Orcho, so the client reports on the record rather than replacing it.
  • The operator still owns the decision while the client handles the mechanics.
Read the MCP front door
Claude Code / driving Orcho over MCPdocs asset
This is the agent-client front door: lighter to operate, still backed by the same run record.

RECOVERY

A paused run can resume as the same delivery record.

Long agent work should not restart from a fresh prompt every time a gate pauses or a worker fails. Orcho treats recovery as lifecycle, not cleanup.

  • Resume starts from the existing run state, not a reconstructed story.
  • Handoffs preserve the plan, findings, artifacts and human decisions already made.
  • The next worker sees the same record the reviewer and operator will inspect later.
Read recovery and resume
orcho run / pause, recover, resumedocs asset
The technical page covers recovery semantics; the business point is continuity across interruption.

LIFECYCLE

The run gets a contract before action.

Intake is where Orcho turns an operator request into a run envelope: task, project, profile, policy and observable state before work begins.

  • The first screen tells the reader which profile and verification posture will govern the work.
  • The lifecycle has named phases, so later review is anchored in state rather than prose.
  • Every surface can point back to the same run anatomy: CLI, docs, evidence and MCP.
Read the run lifecycle
orcho run / intake to phase mapdocs asset
The docs page teaches the lifecycle. Symphos uses the same asset to show why the contract appears before action.