One person, many agents, no approval queue

With agents doing much of the building, writing a change is no longer the slow part of my work. The slow part is what comes after: deciding that the change is right. When one person makes that decision for every change, every change waits in the same queue, and the queue is that person.

The answer is not to review faster. It is to stop making one person the acceptor of every change.

Engineering organisations already solved this

Companies with many engineers met the same problem long before agents existed. Their answer was not one tireless approver. It was a few rules that settle, in advance, who has to look at what:

Separation of duties. The person who wrote a change is not the one who accepts it.
Sensitive areas fixed by path. What counts as sensitive is written down once, by where it lives in the code, so nobody decides case by case whether their own change is risky.
Low-risk changes accepted on their evidence. A change that touches nothing sensitive closes when its recorded checks pass, without a meeting.
Owners who read outcomes in batches. The people accountable read what finished and what went wrong together, instead of signing off each item.

None of this needs a large team. It needs the rules to be written down and the evidence to be recorded where it can be checked.

Scaled to one person

I work as one accountable person with several agents. In the products that have adopted these rules, the same shape looks like this:

Who accepts a change depends on what it touches, not on who wrote it.

A list decides, not a judgement call. Each product keeps one list of which areas need an independent review and which need my own yes. The agent doing the work does not get to label its own change.
Every change closes on its recorded evidence. The checks that ran and what they returned, on the exact version they ran on; for a change in behaviour, a check that failed before it and passes after it. A change with nothing recorded is not done, however good it looks.
A sensitive area is reviewed before it is pushed. The reviewer is a separate agent that did not write the change. It reads the change against the original acceptance, not against the author's summary of it, and looks for defects rather than style.
My areas need my explicit yes. For the areas that are mine, a review is not enough; the change waits for my decision.
I read results in batches. Instead of approving each item as it arrives, I read what finished, what the reviews found and what needed fixing afterwards, together.

The point is that I stop being the queue. Ordinary changes close on their own evidence, the ones that touch something sensitive get a second reader, and my attention goes to the decisions that are actually mine.

What it does not do

The limits matter as much as the rules:

Checks guard against forgetting, not cheating. An automatic check that refuses a change without its evidence stops an honest omission. It does not stop someone determined to get around it, which is why I still read the results.
A reviewer can share the writer's blind spots. A reviewer from the same model family as the writer may miss what the writer missed. So the review's own verdict is not the measure; what needed fixing later is. That is what decides whether an area needs more review or less, and only I move an area from one list to another.
Some actions always need my yes. A deploy, spending money, a legal step or a message to a customer still needs my yes for that specific action. Reviewed code does not carry permission to release it.

If we work together

This is what you can expect from me: the spec before the code, changes to sensitive areas reviewed by a separate agent before they are pushed, and a plain statement of which of the five states of done a piece of work has reached. The whole method is on How I work with AI agents.