Measure Agent Delivery Progress

This layer is for the person accountable for the delivery system, not only for the person running one task.

Use it when the question changes from “can I run Orcho?” to “is agent-assisted delivery getting safer, more repeatable, and easier to govern?”

Measurement layer

Orcho turns agent work into recorded runs. That makes progress measurable: whether gates catch false-ready work, where repair loops happen, which phases carry cost, and whether evidence is strong enough for the delivery decision.

qualityevidencecostrecoverypolicyadoption

first useful window30 days

orcho cost --window 30d
orcho metrics --last 20
orcho evidence --format md

A single run proves the mechanism. A window of runs shows whether the workflow is improving.

What to measure

Start with operating signals that a run already records or makes inspectable.

Question	Signal to inspect	Read
Are agents still saying done too early?	review_changes findings, repair rounds, final acceptance rejects.	False-ready delivery
Are gates producing proof or only text?	Verification receipts, command output, gate policy, missing receipts.	Verification receipts
Is workflow depth matched to task risk?	Profile used, phases required, gates triggered, run outcome.	Profile semantics
Where does effort concentrate?	Cost by phase, runtime, attempt, cache, and run window.	Cost accounting
Are interruptions recoverable?	Halt reason, checkpoint state, resume versus correction follow-up.	Recovery and resume
Can another reader audit the result later?	Evidence bundle, artifacts, events, diff, final decision.	Evidence bundle
Is cross-system delivery improving?	Contract-check outcomes, project aliases, cross final acceptance.	Cross-project mode
Is MCP adding useful control?	Better handoffs, fewer blind retries, clearer diagnosis.	LLM captain mode

A practical scorecard

Use this as a lightweight review loop after several real runs:

Area	Healthy pattern	Warning pattern
Planning	Rejected plans are fixed before code starts.	Implementation begins from vague scope.
Review	Findings are typed, repaired, or explicitly accepted.	Review prose exists, but the run state does not change.
Verification	Receipts name the command, tree, policy, and result.	The final verdict depends on a claim that checks ran.
Recovery	Halt, resume, and follow-up decisions are recorded.	Operators restart from a fresh prompt after every pause.
Economics	Cost is explainable by phase and profile depth.	Spend grows, but nobody can name the phase or reason.
Adoption	Engineers can read status and evidence without replaying chat.	Only the original operator understands what happened.

Reading path

Read in this order when evaluating a team rollout:

1. For technical leaders frames Orcho as a delivery-control system, not another coding agent.
2. A real run, annotated shows one complete run receipt from a real feature run.
3. Cost accounting explains phase, cache, runtime, and API-equivalent workload signals.
4. False-ready delivery shows the quality problem gates are meant to catch.
5. Verification receipts explains how checks become durable proof.
6. Security and privacy explains the local data-flow and worker-runtime boundary.

What this layer is not

This is not an organization-wide governance suite. Orcho’s public surface gives you run-level policy, evidence, cost, and recovery records for local delivery workflows. That is enough to evaluate whether agent-assisted delivery is getting more accountable before introducing heavier organizational process.

When you need exact contracts, continue to Artifact reference and Event stream reference. When you need the system design behind the measurement layer, continue to Runs as recorded state and Gates and verification.