Why we built AI Orchestrator

An AI coding session can produce useful changes. But a chat conversation is a poor record of a longer engineering job. The work may span several sessions, AI models from different companies, tests, reviews, and decisions that only a person should make.

AI Orchestrator records that work as a clear process. It keeps the objective, the approved plan, each attempt, the evidence, the budget, and every decision in one place. A worker, a separate program that does the hands-on work, carries out one limited task at a time. The orchestrator then decides whether the result is ready for the next step.

Why the rules sit outside the AI models

A model's answer is a proposal, not permission. The orchestrator checks every plan. It enforces limits on which code projects the work may touch, what it may do, and how much it may spend. A model cannot raise those limits by writing a persuasive instruction into its answer.

No single AI company owns the whole process. One company's model can write a change while another's reviews it. Either way, the records and the approval rules stay with the orchestrator.

Why the work runs apart from the records

The orchestrator and its database run all the time. A worker contacts the orchestrator to ask for work, rather than the orchestrator reaching in. It does each task in its own separate copy of the code, called a Git worktree. A lease gives the worker time-limited permission for one attempt. If the worker disconnects before reporting back, the lease runs out and set rules decide how to recover.

Separate copies stop two tasks from editing the same files. On their own, they do not make a harmful test command safe to run. So the project tracks two more safety jobs separately: isolating the computer that runs the work, and proving the process on real projects.

How the process developed

The first phase built sign-in, the records, plans, and the points where a person decides. The next phase added worker identity, leases, an event log, and recovery. Later work joined up the steps. A change is written, then checked by tests that give the same result every time. It gets an independent review, and is then published as a draft pull request. A draft pull request is a proposed change that a person still has to review and accept.

The order matters. The tests and the review must check exactly the same version of the code that will be proposed. If any evidence is missing, the process stops. A failed review leads to a limited round of fixes, not an endless loop of retries.

A paired practice project, the sandbox, holds test cases the orchestrator must pass before it is trusted with a real project. Tests and review give a person evidence to decide on. They do not approve a merge or a release on their own. Current readiness and access arrangements are documented privately.

Scope and limits

A proposed change is not permission to merge it or put it live. This page describes the process. Private records hold access details and the current test evidence.

Continue reading

Read the case study for what is actually built, and How I Build for the working method the orchestrator turns into software.