What is Orcho?

Short mental model

Every agent tool gives you a worker that writes code — but none of them decide whether the result is actually ready. That decision is Orcho’s job. As a local-first control plane and delivery protocol, it wraps each task in a run with a chosen shape, gates that can reject, and recorded evidence — so “done” becomes something you inspect, not something you take on trust.

intentprofilepipelinegatesevidence

Read the 5-minute storyRun one task

not a replacement agentnot a loose transcriptdelivery protocol first

orcho ownsdelivery state

task intent
-> profile
    chooses lifecycle depth
-> pipeline
    routes phases to worker runtimes
-> gates
    approve, reject, or request repair
-> evidence
    records artifacts and receipts
-> next action
    deliver, resume, or follow up

The worker may write code. Orcho decides how that work is planned, reviewed, evidenced, recovered, and accepted.

01When it mattersUse Orcho when one private agent transcript is no longer enough.02Profile planeThe semantic layer that makes workflow depth explicit.03BoundariesOrcho surrounds worker runtimes; it does not replace them.04Trust questionCan this agent-produced change be treated as delivery-ready?

The short version

Use Orcho when one prompt in one private agent session is no longer enough.

Orcho is useful when you need:

• a planned run instead of a loose transcript;
• review and repair as part of the workflow;
• a final readiness decision, not just “the agent says done”;
• evidence that can be inspected later;
• recovery paths when a run halts, rejects, or needs operator input;
• workflow memory that survives a specific agent, model, IDE, or terminal;
• one control surface that can be driven by CLI or MCP.

The profile plane

The foundation of Orcho is not “more agents.” It is a protocol-shaped semantic plane for AI work.

A profile describes the intended shape of a run:

• how much planning happens before implementation;
• which phases participate;
• which gates can approve or reject;
• what evidence must exist before a result is trusted;
• how much operator control and recovery the run exposes.

That is why the same task should not always use the same workflow. A typo fix, a feature implementation, a review-only pass, and a participant-set workflow carry different risk. Orcho makes that difference explicit.

Read Profile semantics before treating profiles as just configuration.

What Orcho is not

Orcho is not a replacement for a coding agent. It uses worker runtimes such as agent CLIs through adapters.

That means Orcho can call an existing agent workflow instead of competing with it. The difference is the surrounding delivery protocol: the same kind of work can be run, reviewed, evidenced, resumed, and inspected in a repeatable shape.

Orcho is not a general graph framework. It ships an opinionated software delivery protocol rather than asking you to assemble one from primitives.

Orcho is not a dashboard first. The dashboard and MCP views read durable run artifacts; the run itself remains the source of truth.

The core promise

Orcho is built around a simple operational question:

Can this agent-produced change be trusted as delivery-ready, and what should happen next if it cannot?

The rest of the system exists to answer that question with artifacts rather than vibes: plans, diffs, receipts, gates, events, findings, and typed next actions.

If you are evaluating Orcho as a technical leader, read For technical leaders next.

If you want the same model as one concrete run story, read Orcho in 5 minutes.