Three Orchestrators, One Operator Sleep

A scout finds settled work, a nightly process builds across nine repositories, and a weekly pass integrates a wider slice of the portfolio — bounded, logged, and reviewed each morning.

Leer esto en español

For thirteen consecutive nights, one product track in the nightly lineup had nothing eligible to work: everything left in its backlog was blocked on a decision only I could make, and the run logged it dry each time. That's not unusual by itself — tracks go quiet when their backlog empties. The bigger problem sat one level up: a separate process meant to generate new product ideas had stalled at six of twenty since late June, still burning a full run every night for nothing.

On July 18 that process was retired. In its place: something smaller, earlier, and narrower — a process whose only job is finding things worth doing before the builders wake up, and that never originates an idea of its own.

A system that feeds the system

It runs at 1:15am, forty-five minutes ahead of the first builder, and it doesn't write a line of code. It reads what's already settled elsewhere — a task tracker, the residue of prior nights' run logs, TODOs already sitting in the repos themselves — and turns that into a short, prioritized queue for the night ahead.

Every item it queues carries a tag saying exactly where it came from. No traceable source, no slot in the queue — it either goes on a short list for me to decide, or it's dropped.

Two clocks, two jobs

Two more processes run on their own schedules.

The first is nightly, starting at 2am. A handful of parallel workers read the queue, plus anything I've added or reordered by hand — the scout works around those edits, never over them — and claim up to four bounded pieces of work, one per repository, side by side. It goes first, deliberately: whatever it breaks is caught by the build sweep and CI check a few hours later.

The second runs once a week, before dawn on Saturday, on a more capable model — the higher-powered, deploy-capable sibling of the nightly one, and the only one of the two allowed near a live deploy, and even then only after full verification. It used to build new products off a seed list; that mode was retired the same day the stalled idea process was cut. Now it only integrates what already exists across the portfolio, plus at most one slice advancing something already in flight — never a new product.

What a night actually looks like

Nine repositories are in scope for the nightly pass; on a full night, up to four get touched in parallel, each by its own worker, each checked independently rather than taken on its word — the process re-runs the build and tests itself and reads the diff, rather than trusting the worker's own summary of what it did.

The numbers stay boring on purpose. A portfolio build sweep — 32 or 33 modules depending on the night — has come back clean, zero failures, every night it's been logged. One test suite went from 225 tests to 229 in a single run: four new boundary-case tests and one small extraction, nothing dramatic.

The guardrails

The limits are simple. Nothing gets pushed anywhere, ever, without me looking at it first — every commit lands local-only. Nothing touches a secret or a live payment system. And the rule that matters most in practice: if a worker is unsure whether something is safe, it skips it and says so, instead of guessing.

That rule got tested directly. One Wednesday, the nightly pass reached its fourth repository and found it checked out on a branch that wasn't main — one commit ahead, the branch already pushed under an open pull request. Committing that night's change on top of it would have slipped unrelated work into an unfinished PR. So it skipped the repo and logged exactly why, citing the standing rule: skip when unsure.

Three things, never more

Everything the fleet can decide on its own, it decides on its own. Everything it can't gets held for me — capped at three items, ever.

Each of the three comes with a one-page brief in the same shape every time: what's actually in tension, several real routes with tradeoffs, and a recommendation that isn't a decision by itself — I can ratify it, name a different route, or write another answer entirely. Of the ones closed out so far — three of them — I've ratified the recommendation every time.

Some weeks the list is empty; right now it is — nothing waiting on me. The review stays simple: read the run logs, see what landed, answer the three-item list if there's anything on it.