The orchestrator is the working answer to a question the bio raises: what does engineer-led AI actually look like as software? It is a private beta running at ai.denley.nz — a control plane where objectives are submitted in plain language, an AI worker proposes a plan, and nothing consequential happens without a human approval. Plans, credentials, deploys, and anything that touches a real repository all gate on a person.

The work itself runs on enrolled workers that drive AI coding agents inside constrained sandboxes: read boundaries proven before every run, fail-closed test jails, signed result envelopes, and an acceptance gate that treats readiness as a human coverage decision rather than a model’s verdict. The point is not that AI does the work — it is that the evidence the work happened, safely, is first-class.

Its dashboard is a desk: @denley/desk-engine windows for the objective queue, run traces, history, and settings — the same engine this site runs on. The orchestrator was the engine’s second consumer and drove a run of its extractions: directional focus, the shared window frame, and the gesture controller all landed in the library after being proven there.

What’s actually built

From empty control plane to hardened beta

The control planeObjectives, plans, approvalsA FastAPI control plane on self-hosted Kubernetes: objectives go in as plain language, workers propose plans, and a mobile approvals surface puts every consequential decision — plans, credentials, anything touching a real repository — in front of a person before it happens.
The workersOutbound-only, capability-leasedEnrolled workers connect outward (nothing listens on a home network for the internet), lease only the capabilities they are granted, and return signed results — replay-proof envelopes carrying run identity, so a repost can never masquerade as fresh evidence.
The sandboxBoundaries proven per runAI coding agents run inside constrained sandboxes whose read boundary is re-proven before every provider run — the task is refused if the proof fails — and test execution fails closed rather than running unconfined and calling the result evidence.
The gateReadiness is a human decisionA 24-case acceptance matrix decides whether the system may touch a real repository — and most cases require a human attestation on a human-only route. The automated subset passing is deliberately not enough; a service account cannot vouch for the system it belongs to.

The build has been documented while it happened — 100+ versioned releases, each with a changelog entry recording what changed and why, security findings worked through as their own reviewed pull requests with regressions, and a 900+ test gate (control plane, workers, contracts, migrations, frontend) run before anything ships. The project is as much a demonstration of the lifecycle as of the product.

Why a beta badge

The orchestrator ships to production continuously, but its acceptance gate deliberately reports itself unready until human attestations cover the full case list — the gate refusing to flatter the system it guards is the feature. It graduates when the evidence does.

The desk it runs onRead the documentationThe shared stack