Keep Agent Work Within What You Can Review

Before starting another coding-agent task, name its next delivery and how you will inspect it. If earlier work needs a missing decision or has produced an uninspectable result, another implementation can add output without making a decision easier.

A review queue asks what to inspect next. An intake decision asks whether to invite more work at all. Tasks can be independent in code and still compete for the same person's attention, access to a preview or ability to understand a change.

In one public account, a developer described the burden of continually starting tasks and switching projects. In another, the author described returning from an expanding rewrite to smaller work they could understand and check. These are individual reports; their absolute posting dates were not established. They motivate the question below, not a measured rule for how many agents to run.

Choose a review opportunity before another delivery

The following Maple Notes project, people, requests and history are entirely fictional. Rin is the developer reviewing the work. Rin chooses one 25-minute block, W1, and a separate later 45-minute block, W2.

Those numbers reserve attention in this example. They are not measured capacity, estimates of how long the tasks require, or a promise that the checks will finish. W1 has this planned allocation:

If an inspection takes longer, Rin leaves its decision open. There is no timer-based permission to accept a result. W2 is another opportunity to review, not proof that a harder change will fit.

Put review needs beside the work offers

Here is the complete intake board at the start of W1:

A17 cannot be made ready by giving an agent more uninterrupted coding time. Its product choice is missing. B08 may contain useful completed work, but Rin cannot review a completion sentence as a patch. C12 has enough input to produce a small inspectable object.

The review burdens are descriptions of needed work, not numerical complexity scores. A small file can still require a difficult behavioral check. A long analysis can sometimes be reviewed from one decisive example. Count the questions and evidence you must handle, rather than treating every task row as the same unit of effort.

Defer the work that lacks a decision

A17's original request is:

Plan a preview-sharing flow for Maple Notes.
Before implementation, establish who may open a preview link.
Do not silently broaden the visibility of existing notes.

The two options are workspace members only and anyone with the link. The product owner is unavailable during W1. An agent offers to implement one assumed audience while waiting.

Rin declines that expansion and asks for the specific input:

A17 is waiting on the intended preview audience:
workspace members only, or anyone with the link?

Keep A17-note-v1 and the two options available. Do not implement either
audience under an assumption. Record the decision when it is supplied;
the next delivery will be a small design card before implementation.

This does not rank A17 as unimportant. It identifies why another implementation delivery would be premature. The reopening condition is an explicit audience decision and current scope, not an arbitrary wait or another “ready” notification.

Reduce an uninspectable delivery before asking for more

B08 was asked for a focused toolbar change that preserves search behavior and keyboard operation. Its only current output is “Toolbar cleanup is finished.” The agent offers to continue polishing the toolbar.

More changes would make the existing result harder to identify. Rin instead requests:

For B08, make the next delivery an evidence index for the existing change.
Do not continue polishing or add another toolbar change in this step.

Identify the exact candidate and provide the complete diff/reference.
Link the preview to that candidate. For the requested keyboard behavior,
list checks actually performed and their results, or state not run.
Identify missing artifacts or an unavailable review environment directly.

Preserve the existing work. Do not reset, discard or rewrite it just to
make the delivery smaller. Further implementation waits for a concrete
review finding or a separately scoped next request.

Reducing output here means changing the next delivery from more implementation to an inspectable index. It does not mean deleting files, reversing changes or treating the task as finished.

If B08 returns a usable index, that evidence-assembly step can be complete while the toolbar change remains unaccepted. Finding the patch is a prerequisite to reviewing it. It is not a substitute for the review.

Admit a small new task with an inspectable boundary

C12 has this complete starting context:

<section class="empty-filtered">
  <h2>No matching notes</h2>
  <p>Try another search.</p>
  <button type="button" data-action="clear-filters">Clear filters</button>
</section>

The requested hint is exactly Clear filters to see all notes. The heading, button, classes and behavior should remain unchanged. Rin admits only the paragraph-change candidate:

Prepare C12 from C12-base-v1 in EmptyFilteredView.html.
In the filtered-empty view only, replace:
Try another search.
with:
Clear filters to see all notes.

Keep the heading, button, classes, action marker and behavior unchanged.
Return the complete before/after context, the paragraph-only patch and
the exact candidate identity. Separate source inspection from any actual
preview or runtime check; say not run where applicable.

Do not revise adjacent copy, redesign the empty state, change filtering,
commit or publish. If this needs another file or a behavior change,
explain the dependency before expanding the delivery.

In the invented history, C12-r1 returns this full patch:

 <section class="empty-filtered">
   <h2>No matching notes</h2>
-  <p>Try another search.</p>
+  <p>Clear filters to see all notes.</p>
   <button type="button" data-action="clear-filters">Clear filters</button>
 </section>

Rin compares the complete shown fragments and accepts that source-copy scope. The button's source is unchanged; no browser interaction or actual filter behavior was exercised in this example. The decision does not become a runtime acceptance just because the edit was small.

Why start C12 while A17 and B08 remain open? Its input and next delivery are defined, and Rin has chosen a narrow review opportunity for it. A17 still lacks a decision; B08 still needs inspectable evidence and a different kind of check. The admission decision follows those conditions, not notification order or how many agents happen to be idle.

If W1 disappears, or C12 arrives without the promised context, defer C12 too. “Small” does not grant automatic admission or acceptance.

Follow the history beyond the first decision

These are authored decisions, not a timed experiment or a log of agents working. There is no observed reduction in elapsed time, workload or review errors to report.

At H6, the request controls what output is wanted next. It does not prove that a background process stopped or that a particular host enforces a queue. Preserve the artifacts and verify task state through the actual tool when that matters.

State what reopens each task

The design card for A17 describes intended behavior; it does not establish an implemented access-control system. B08 may still require more than W2. If so, Rin keeps it pending or asks for a smaller inspectable correction rather than turning the end of a calendar block into approval.

Only admit another delivery when you can say what it is, which input it depends on and what review opportunity it needs. Otherwise defer it or ask for a smaller artifact that answers the next question. You can leave a margin unused instead of filling it with another implementation.

Reuse a bounded next-delivery request

Task and current candidate:
[Identify the work and the artifact that already exists.]

Current decision:
[Start this bounded delivery / defer implementation / reduce next output.]

Next delivery only:
[One inspectable artifact, its scope and the evidence it must include.]

Missing input:
[Exact question and decision owner, or explicitly none for this step.]

Review opportunity:
[When and with which context/environment this artifact can be inspected.]
This is a planned opportunity, not a promised review duration or approval.

Preserve:
[Existing work and constraints that must not be silently replaced.]

Reopen or expand only when:
[Concrete input/evidence/review condition.]
If that condition is absent, retain the work and report the gap rather
than producing another implementation under an assumption.

Report actual inspection, execution and remaining unknowns separately.

The useful limit is a reviewable next commitment. Sometimes that is a small patch. Sometimes it is one decision question or the evidence needed to inspect a patch that already exists.