Why we built AI Orchestrator

An AI coding session can produce useful changes, but the conversation alone is a poor record of a longer engineering job. Work may span several sessions, different model providers, tests, reviews, and decisions that only a person should make.

AI Orchestrator records that work as an explicit process. It keeps the objective, approved plan, attempts, evidence, budget, and decisions together. A worker carries out a limited task; the service decides whether the result is ready for the next step.

Why the control service is separate from the models

A model's response is proposed work, not permission. The control service validates plans and enforces the permitted repositories, capabilities, and spending limits. A model cannot expand those limits by writing a persuasive instruction into its output.

The design also avoids making one provider the owner of the whole workflow. Implementation and review can use different providers, while the records and approval rules remain under the same service.

Why execution is separate from durable state

A worker connects out to request work and runs it in a separate Git worktree. A lease gives that worker temporary authority for a particular attempt. Expiry and recovery rules handle a worker that disconnects before reporting a result.

Separate worktrees prevent two tasks from editing the same checkout. They do not, by themselves, make a hostile test command safe. The project therefore tracks host isolation and real-repository acceptance as separate safety work.

How the process developed

The first phase established authentication, records, plans, and human decisions. The next phase added worker identity, leases, events, and recovery. Later work connected implementation, deterministic tests, independent review, and publication of a generated branch as a draft pull request.

The order matters. Tests and review must refer to the same commit that is proposed for publication. Missing evidence should stop the process, and a failed review should become bounded correction work rather than an endless retry loop.

The paired sandbox supplies acceptance cases before a repository is entrusted to the workflow. Tests and review provide evidence for a human decision; they do not authorise a merge or deployment. Current operational readiness and access arrangements are documented privately.

Scope and limits

A proposed change is not approval to merge or deploy it. This page describes the process; private operational records hold access arrangements and current acceptance evidence.

Continue reading

Read the case study for what is actually built, and How I Build for the lifecycle the orchestrator productises.