The promotion gate: an agent never approves its own work order

🚦 Two agents, one loop

A common pattern: a senior agent writes a work order for a cheaper agent, and the order is put in a queue. If the same system that writes the order can also approve it, nobody has decided anything. A mistake in the order goes straight to execution, and the bill follows.

🧩 Three separate steps

In our setup the cycle has three steps, each a separate command.

1. Prepare. The senior agent writes the order: a specification for the worker and an acceptance contract, in one file, with the field approved set to false.
2. Promote. A named person approves the file. This is a separate action, written to a log with who, when and which file. The agent cannot do it for itself.
3. Enqueue. Only an approved file can go into the queue.

A global switch in a service definition that turns the dispatcher on is not approval. Our design note removes one that did exactly that, because a process-wide flag approves everything at once and records nothing about who decided.

💵 Reserve the whole task

The second rule is about money. A check that the remaining balance is above zero lets one expensive task consume everything. Instead, the budget for the whole task is reserved before the first request. A timeout, a kill or an error leaves the charge marked uncertain and blocks new tasks until a person reconciles it. The whole trajectory counts: tool loops, thinking, critic passes, retries and fallbacks, not only the last answer. An unknown cost is not zero.

📊 In numbers

Each task token in our transport is tied to a task packet fingerprint, and since 2026-09-21 1,415 tokens have been issued. The transport has recorded 4 reservations. Both are counted from the database on 3 November 2026, 21:53 UTC.

🛠️ Practice: add a gate to your queue

1. Add an approved field to your work order format and default it to false.
2. Write the promote command: it needs the file, a person's name and a reason. It appends a log line and flips the field.
3. Make the queue refuse any order whose field is false or whose hash differs from the one the log recorded.
4. Remove every global "enable dispatch" switch from your service definitions.
5. Reserve the order's budget when you enqueue, not when you start. Refuse to enqueue if the cap would be exceeded.
6. Mark timeouts and killed runs as uncertain and stop the lane until someone reconciles.

✅ Check yourself

• Edit an approved file by one character. The queue refuses it because the hash changed.
• Try to promote with an empty name. It fails.
• Run the dispatcher with no approved orders. It does nothing.
• Pick any order from last week and find who approved it and when.

🚧 When this does NOT work

• Rubber-stamp approval. If one person approves fifty orders in a minute, nobody reads them. Limit the batch size.
• Slow lanes. Approval adds minutes. For tiny read-only tasks consider a standing rule instead of a per-order decision.
• Approving the wrong thing. A person sees the summary, not always the tool calls. Show the file hash and the budget in the prompt.
• Single approver. When that person is away, the lane stops. Name a deputy.
• Agents that edit the log. Keep the approval log out of any path an agent can write to.

📊 Evidence

➡️ Next

Write the order itself with Spec-driven development with existing task packets, and recover from a stuck lane with Recovery after a failed, stuck or uncertain run.

Sources

• Spec-driven development with existing task packets: writing the order.
• Recovery after a failed, stuck or uncertain run: stuck lanes.
• Costs, budgets and limits: budgets.
• An AI usage policy and register a small team can enforce: who may do what.