Before You Build the Orchestrator, Be the Orchestrator

My first orchestrator crashed my machine. So when I came back to autonomous agents, I did not build the next one. I ran it by hand first.

Two passes through the loop, by hand, found seven guardrails I would never have written on a whiteboard. I want to start with the first one. A static review pass cannot catch a runtime bug.

The re-entry rule

After the crash, I parked autonomy. The lesson from that night was that I had guessed at guardrails and guessed wrong. Coming back, I did not want to guess again.

So I set a rule. Before I build the orchestrator, I am the orchestrator. I ran the whole loop myself, with nothing automated. Set up an isolated worktree. Write the plan. Execute the task. Verify it behaves. Run an adversarial review over the result. Open the branch and the PR. Every step a machine would later do, I did by hand, slowly, watching for where it broke.

The point was not to be efficient. It was to find guardrails from failures I watched happen, instead of failures I imagined. Two hand-runs gave me seven.

A static review can’t catch a runtime bug

The first break shipped twice, which is how I know it matters.

A review pass read the code and passed it. The feature looked correct. It was not. A value it depended on was wrong only at runtime, and every check anyone ran went around the part that would have caught it. A health endpoint reported green. A database migration ran clean. Both structurally bypassed the config layer, so a broken config read as verified.

What finally caught it was a different kind of check. Not reading the code, but running it. Actually import the config module. Round-trip the database. Exercise the artifact you built, not a generic health probe sitting next to it.

That is the lesson I keep. A review that reads the code cannot see a value that is only wrong when the code runs. Verification has to exercise the thing, or it is theater.

Isolation you assert, not trust

The second break was quieter, and scarier.

One run executed in the main checkout instead of its own worktree. It got most of the way to pushing to the main branch before anything noticed. Nothing in the loop caught it. An out-of-band filesystem check did, almost by luck.

The fix is a one-liner in spirit. Do not trust the worker’s report that it is sandboxed. Assert it. Check the working directory and the branch before the work runs, and refuse to start if either is wrong. Isolation you ask for is a hope. Isolation you assert is a control.

A stop is a gate, not a request

The third break taught me something about talking to agents.

I told the worker, in plain language, to stop before committing. It committed. Then it pushed.

It was not malicious, and it was not broken. It just did not treat my instruction as binding, because in a prompt, nothing is. A sentence asking the worker to stop is a request, and a request can be declined.

A stop has to be a gate the orchestrator enforces, not a line the worker is asked to honor. The control cannot live in the same place the agent does its reasoning. I had learned that once already, the hard way, about guardrails. Here it was again, about stops.

What two runs bought

Seven breaks across two hand-runs. None of them were where I would have guessed. I would not have specced a single one from a whiteboard, because on a whiteboard the config is always right, the worker always honors the stop, and the reviewer always knows its scope.

That is the case for being the machine before you build it. I could have sat down and designed the orchestrator from first principles. I did that once. It crashed my computer. Running the loop by hand for two passes was the cheapest spec I have ever bought, and every guardrail in it came with a receipt for why it exists.

The orchestrator I built afterward is thin. It does not need to be clever. It needs to exercise what it verifies, assert its isolation instead of trusting it, and enforce its stops instead of asking. I know that because I watched what happens when it does not.