The agent that does not wait for me

Six minutes after I handed over the work, the Dispatcher sent me a Word document with five questions and seven decisions it had already taken. By then it was already building. This part is about the agent that built the three features from Part 1, and about a trade I made on purpose: speed now, corrections later.

Step 3: the Dispatcher does not wait for me

With the scope settled, I hand the work to the Dispatcher, an AI agent I built on Superpowers and on my own delivery experience. It plans the work and directs other agents; more about it below. It runs in its own session, splits the work into packages and runs coding sub-agents in parallel. I rarely talk to it directly. I talk to one main session, and that session sends the Dispatcher its instructions.

I set the Dispatcher up so it does not stop to wait for me. It takes each decision on its own recommendation, writes its questions into a Word document and starts building straight away. Six minutes after it started, the document was ready: five questions and seven decisions it had already taken, each with alternatives.

From then on the work runs in two lanes. The agent builds. Next to it, I read the document, review what it chose and type my answers into grey boxes. When I send the document back, the agent changes course on code that is already half written. In this run my answers changed four of its recommendations, including one that doubled the assistant's daily budget. A sample of that document, with my answers, is at the end of this part.

When I want to know how it is going, I ask. The Dispatcher does not write code itself; its sub-agents do, and they report back to it, so it always knows the state of every package. I can ask for a status or for screenshots of what has been built so far. In this run I asked for screenshots of the admin panel and the article page and got five of them, on test data, while the work was still going on.

Watch out: decisions nobody made. The agent decides first and asks second, which is why it is fast. It also means that a late answer costs rework, and a missed answer turns into a decision nobody made. Decide which decisions the agent may take alone, keep a written record of the ones it took, and keep ideas that arrive mid-flight in the backlog. The record pays off later: each time I overrule one of its assumptions, the agent learns how I decide, and over time fewer of its decisions need my review.

The agent learns how I decide

During a short break in this run I took that one step further. The Dispatcher now compares the decisions it took with the ones I kept or changed. On its first full pass it went through 22 earlier decisions: it had matched me in 16 and missed in 6. From the misses it drew two lessons about how I decide. One of them: when it picks the simplest option, I usually want the fuller scope. It did not adopt the lessons on its own. It asked me about each one: should it apply to every project, to this one only, or not at all?

So the decision log has a second use. It is my record, and it is also what the agent learns from. Every delivery manager will soon have to answer a new question: who approves what an agent has learned about the way you decide?

Failure 2: a link nobody wanted

The Dispatcher usually sends me screenshots of the pages together with its next round of questions. This time I had a free moment, so I asked for them while the build was still running. On the article page I found a "Read in Polish" link that should not have been there; the language switch in the header already does that job. I told the Dispatcher.

Its answer changed the picture. The page was already in production, deployed at 16:25, before I had seen a single screenshot. It was behind the hidden-section flag, an old trick from traditional development, so no visitor had seen it. And the link was not a sub-agent's mistake: the Dispatcher's own brief had asked for it. The fix went into a package that was already working on the article page, and the Dispatcher logged the failure with its cause.

I do not count shipping before my review as the failure; I designed it that way. I built the Dispatcher to keep going until the work is done, take its own decisions and let me correct them afterwards. I learned that the hard way. Before, I built features while being asked something every few minutes and could not focus on anything else. Now the Dispatcher works, and at the end of each round it shows me what it built and lists every decision it took. The "Read in Polish" link would have come up in that review anyway, and the flag kept unfinished work away from visitors until then.

Watch out: review after release, by design. Letting the agent decide and ship first buys you focus, and you pay for it with corrections afterwards. That only works with guard rails: feature flags so visitors do not see unreviewed work, a written list of every decision the agent took, and an implementation review that really happens. If your setup needs more stability, let the agent release to a test or staging environment instead of production. I have a test environment as well, where agents test their own work. Decide which one you use before the first run.

What the Dispatcher is

The Dispatcher is a workflow I built for Claude Code on top of Superpowers (Part 3 explains how the agents plan) and on what I learned building software with it. It is a set of written instructions, a "skill", that turns one AI session into the delivery lead for a round of work. I talk to one session, and the work runs in parallel behind it.

How it works, in short:

1. Collect. I give it every idea for the round.
2. Split. It reads the code, splits the ideas into work packages and maps the dependencies between them.
3. Decide or ask. Where one option is clearly better, it decides, builds it and records the decision with its alternatives, so I can reverse it later. Only what it cannot know comes to me (strategy, money, accounts, facts about me), all at once, in one document.
4. Run. Each package goes to its own coding sub-agent on its own branch. Many can run at once; the limits are the machine, the budget and the code itself. How many independent features are there, and how many agents can work on the same files before they get in each other's way? A thousand agents on one file make no sense.
5. Integrate. It opens pull requests, waits for the automated checks, merges, deploys, checks production and rolls back if a check fails.
6. Report. It comes back only when everything is done or blocked.

It works this way because my attention is the scarcest resource in the process. Questions come in one batch instead of a stream of interruptions. Decisions do not wait for me when the answer is clear, but each one is written down. Some things always stay with me: passwords, payments, messages sent in my name and external accounts.

What I get from it is long stretches of focused work and a written record of every decision.

I am not a professional developer any more, and there are better coding tools than mine. If it helps you, use the simplified version below.

If I ran your team

I would agree on a short list of decisions the agent may take on its own, and ask for every other decision to come back in one document per round. I would also review that decision log every week, not only when something breaks.

Downloads

With repository links, server details and internal paths removed:

• Sample: Dispatcher questions (PDF, 148 KB). The document the Dispatcher wrote six minutes into the run: five questions, seven decisions already taken, and my answers.
• A simplified Dispatcher skill (MD, 6 KB). A generic version of the instructions behind the Dispatcher, to adapt to your own project.