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

Defect work on the code lanes 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. An intent waiting on an external decision or dependency can move to blocked; Ark will not dispatch it until a person restores status: aligned.

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.

Who sets which status

The kernel writes exactly one intent status: in-flight, set by os run when it decomposes an aligned intent. Every other status (draft, aligned, blocked, ready-to-release, released, validating, proven and the rest) is set by a person. If a status changed and nobody ran os run, a person changed it. People working an intent by hand set in-flight too; the run log has to show that work, or os run refuses it.

Intent status and task status are different vocabularies. An intent is in-flight; the tasks inside its graph move through pending, in_progress, done, failed, or blocked. "In progress" is a task word. An intent stays in-flight between runs and while its tasks are still moving. A task a stopped run left in_progress goes back to pending when the next os run starts. A task a person finished outside Ark is recorded with os task done and shows completed_by: person.

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 governed workflow that decides who owns the gates, what evidence is mandatory, and where the work ships. Seven lanes are official and five are experiments aimed at official next cycle. Each lane's operators, gates, and evidence policy are on the Lanes page.

Lane	Rollout	Owner	What it is
`patch`	official	Magda	Customer fixes on that customer's release line
`sweep`	official	Alex	Standing unblock loop over a project channel, config only
`regression`	official	Ragnar	Per-customer agentic test packs
`tech_health`	official	Claudia	Reliability, performance, tech debt, platform tooling
`golive_gap`	official	Ragnar and product leads	Minor product gaps and enhancements
`migration`	official	Alex	Customer data runs into a Kaptio org
`business_tools`	official	Jon	Scorecards, dashboards, internal tooling
`product_pitch`	experiment	Product leads	Internally funded product features
`funded_pitch`	experiment	Ragnar	Customer-paid features, including mini-SOWs
`support_push`	experiment	Magda	One customer's sev-3 batch into a mainline release
`presales`	experiment	Tomas	Prospect POCs and demos; nothing ships to production
`concepts`	experiment	Product leads	Launches, showcases, throwaway prototypes