The orchestrator is my working answer to a question from my bio: what does engineer-led AI look like as real software? It is a private beta that runs in a closed environment. You describe an objective (the result you want) in plain language, and an AI proposes a plan. Nothing important happens without a person approving it. That covers plans, credentials (passwords and access keys), releases to live systems, and anything that changes a real code repository.

The work runs on workers: computers registered with the system that run AI coding tools inside sandboxes. A sandbox is a locked-down space where the AI can reach only what it is allowed to. Before each run, the system checks that the AI can read only the files it should. Tests run in a sealed space too, and if that space cannot be set up, the tests do not run at all. Each result comes back digitally signed, so it cannot be faked. A final readiness check decides when the system can be trusted with real work. A person, not an AI, makes that call by reviewing the evidence. The point is not that AI does the work. The point is clear proof that the work happened safely.

Its dashboard is a desk built with @denley/desk-engine, the same window engine this site runs on. It has windows for the queue of objectives, a step-by-step log of each run, history, and settings. The orchestrator was the second product to use the engine, and several engine features started here: moving between windows by keyboard direction, the shared window frame, and the drag handling. Each one was proven in the orchestrator first, then moved into the library.

A private system

AI Orchestrator is private. That includes its live service, source code, admin screens and operator documentation. This website shows only a short public summary that I have reviewed. I do not publish access details, credentials, internal settings, operating instructions, deployment records, customer information, or other private operating material.

What’s actually built

From a blank start to a well-secured beta

The core serviceObjectives, plans, approvalsThe core service is written in Python (FastAPI) and runs on my own Kubernetes cluster. Objectives go in as plain language, and workers propose plans. An approvals screen built for phones puts every important decision in front of a person before it happens: plans, credentials, and anything that touches a real repository.
The workersThey connect out, and take only what they are givenWorkers always open the connection themselves, so nothing on my home network is open to the internet. For each task, a worker borrows only the permissions it has been granted, for a limited time, and returns signed results. Every result carries the identity of its run, so an old result sent again can never pass as new evidence.
The sandboxChecked before every runAI coding tools run inside locked-down sandboxes. Before every run, the system checks again that the tool can read only what it should. If that check fails, the task is refused. If tests cannot run inside the sandbox, they do not run at all. They never run unprotected and call the result evidence.
The final checkA person decides when it is readyBefore the system may touch a real repository, it must pass a list of 24 test cases. Most of them need a person to sign off the result, through a screen that only a person can use. Passing the automated tests alone is deliberately not enough. An automated account cannot vouch for the system it belongs to.

I documented the build as it happened. There are more than 100 numbered releases, each with a changelog entry that says what changed and why. I dealt with security findings one at a time, each in its own reviewed code change, with tests that stop the problem coming back. More than 900 tests must pass before anything is released. They cover the core service, the workers, the messages passed between them, database changes and the interface. The project shows how I build as much as it shows the product.

Why it is still a beta

New versions of the orchestrator go live all the time. But its final check deliberately reports “not ready” until a person has signed off every case on the list. That is the point: the check will not flatter the system it protects. The orchestrator will leave beta when the evidence supports it.

The desk it runs onRead the public summaryThe shared stack