The intent-to-outcome orchestrator

Ark is a command line interface with a large, careful kernel in the middle. You feed it intents, not tickets. It decomposes a person-aligned intent into a cross-repo task graph, dispatches Builder agents in parallel inside isolated git worktrees, has an independent Reviewer challenge the work, captures every token to a per-intent cost ledger, and only closes the intent when measurement proves the outcome was met.

Repo agnostic, work agnostic, person agnostic. It has shipped Salesforce patches, KTAPI pricing changes, data-migration probes, permission sets, contracts, and commercial close plans. Same kernel, same board, same ledger.

Why it works

The memory palace

Intents are markdown files in a git repo, each with an append-only run log. Before decomposing new work, the kernel reads the success paths of prior intents. The first Travel Studio intent was expensive; the third cost almost nothing, because it stood on what the first two learned. Feed Ark tickets one by one and this compounding never happens: a million intents, nothing shared.

Cost-to-outcome is the headline metric

Every agent run writes a ledger row. os reconcile allocates real Cursor billing (charged cents, not estimates) to intents hourly, including interactive sessions. Budgets live on intents and planning windows, with a daemon tripwire that stops new pickups when a window's reconciled burn hits its budget. You can answer "what did this outcome actually cost" for every intent on the board.

Proof, not vibes

Full-lane defect work is gated: reproduce and photograph the defect before any code change, write the red test, make it green, run the regression suites, verify the fix on an org through the path the customer reported, and carry a SIT handover in the MR describing exactly what was tested. After release, a Verifier reads live production signal before the intent may be called proven.

People stay where judgment lives

Two person gates are non-negotiable: align (before any run) and accept (before proven). Builders never merge. Anything touching auth, secrets, payments, or tenant isolation requires person architecture sign-off. Your job is to shape the intent; Ark's job is to execute it.

How an intent travels

draft → aligned → in-flight → proven, with not_met looping back to execution.

Stage	Who	What happens
1. Draft	Lead agent or person	An intent is proposed from real signal: Jira tickets, Slack threads, handovers, prior decisions.
2. Align	Person gate	A person confirms the problem, the desired outcome, the success metrics, and the constraints. The cheapest place to correct direction.
3. Decompose	Lead	The aligned intent becomes a cross-repo task graph: what changes where, in what order, with what dependencies.
4. Execute	Builders	Builder agents run in parallel, each in an isolated git worktree, each on a focused task brief, producing merge requests.
5. Review	Reviewer	An independent, skeptical reviewer with a separate context reviews architecture and code before any person sees the MR.
6. Validate	Lead	Cross-repo dependencies are reconciled and outputs checked against the success metrics.
7. Measure	Verifier	After the measurement window, live signal (Grafana, Loki, BigQuery, Salesforce SOQL) is read and actual is computed against target.
8. Verdict	Person gate	The intent reaches proven only when operational metrics pass with sufficient signal. not_met loops back with the measured gap as the new brief.

Inside one run

What os run does with an aligned intent. Builders work in parallel and never see each other's worktrees; the Reviewer starts from a clean context so it cannot inherit the Builder's assumptions.

Lanes

Every intent carries a lane: a work classification with an implied budget and harness depth. fix → lite → full is the escalation ladder; probe, sweep, migration, and gtm sit off the ladder. What happens inside each lane, with live examples from the board, is on the Lanes page.

Lane	Shape	Harness
`fix`	Trivial, reversible, single-repo	Ticket and MR only, no intent spec
`probe`	Investigation or capability proof	Lite spec; the outcome is a finding or a decision
`lite`	Bounded enhancement	Stripped spec, one success metric, collapsed gates
`full`	Cross-repo, novel, risky, payments or auth	Full lifecycle with all gates; probe evidence required before decomposition
`sweep`	Standing loop over a source (customer channel, bug queue)	Append-only run-log cycles; closes at a milestone
`migration`	Data-migration programme over a legacy dataset	Probe, design, mapping, verification cycles; every org load person-gated
`gtm`	Go-to-market programme (campaign, segment, deal close)	Research then execution cycles; every external touch person-gated