Why I built an orchestrator

I do my own work on more than one machine. A desktop sits in one room and a laptop travels with me, with a small computer in a corner for light jobs. Over the last while I have also been handing pieces of that work to AI agents. A release build here, a test pass there, a slow page that needed profiling. Each of those agents was useful on its own. Together they became a small mess that only I could keep straight.

The day work stopped when I left

The same pattern came back most days. In the morning I would start an agent on the desktop, point a second one at the laptop, and queue up a few more things in my head. Then I would leave for a few hours. When I came back, one agent had finished and was waiting for me to say what came next. Another had stopped on a question I could have answered in ten seconds. A third had quietly done the same fix as the first, because neither knew about the other.

None of this was dramatic, only idle time and duplicated effort, spread across machines I was paying for in electricity and in attention. The agents were fast, and I was the slow part, and I was the only link between them.

I kept a list in a text file, then tried assigning machines by hand. Both worked for about a day, and then the list drifted away from what the machines were doing. What I wanted was a single place where work waits in order, and where whichever machine is free picks up the next thing.

What I built

Murongi is the result, an orchestrator for AI agents: a person or a small team who stay responsible for the work, several machines, many agents, and a shared queue of tasks. I am building it for my own work, and it is shaped around how I work, so I do not claim it fits anyone else.

The loop itself is short enough to describe in a paragraph. A task enters the queue and one agent claims it, so everyone else can see it is taken. The agent does the work in its own copy of the code. A second agent reviews the change. If it passes, it lands, and a short note goes out to tell me. That is the whole cycle, and the point of it is that I do not have to stand in the middle.

Two things surprised me while building it:

• Most of the value came from the queue and the claim, which are boring. Once a task has exactly one owner, a large share of my confusion disappeared.
• The second agent reviewing the first caught more than I expected, mostly small things I would have skipped on a tired afternoon.

Machines talk to each other through a message service. In my set-up that is svc.nz, which I also build, and it carries messages and hand-offs between machines. If a machine goes to sleep, a message can wake it. If one goes offline, its waiting work can move to another.

Why I kept a person in it

I could have tried to remove myself, and I decided against it early. Some steps are worth a pause: spending beyond a budget I set, or publishing and deleting. Those wait for me, and I can approve them from my phone while I am away from the desk. That small change turned the old problem around. Instead of work stopping because I was not there, it keeps going until it reaches one of the few steps that needs me, and then it waits with the question already written out.

I also wanted a way to stop everything at once. There is a single switch that halts new work across all the machines. I have rarely needed it, but I would not run the system without it, the same way I would not run a workshop without a way to cut the power.

Where it stands

This is a personal project, and I treat it like one. I use it daily for my own repositories, I change it when it annoys me, and I write about it here when I learn something worth keeping. The next two posts go into the parts I think about most: the guardrails that decide how work is handed out, and the usage meter that tells me what all of this costs in plan usage. The home page has a walk-through of the whole loop, with each number on it marked as an example.