The More Agent Work You Run, the More Human Steering Matters

The bottleneck moves; it does not vanish

A useful way to think about agents is not as a replacement for a person, but as a new source of candidate work. They can propose patches, investigate a failure, write a migration, or run a set of experiments. That increases the amount of work arriving at the next decision point. Someone still has to decide which proposal is worth accepting, what evidence is enough, and whether the change belongs in the system.

OpenAI published an internal view of this shift in September 2026. It reports that coding-agent use in its research organization rose sharply through the year, while researchers increasingly used concurrent agents. The same report is careful about its limits: these are internal measurements, not a universal industry baseline, and more agent activity is not the same thing as proportionally more research progress.^[1]

Agents create candidate work. Teams still create outcomes.

A single agent can be easy to supervise because its output arrives in one place. A group of agents changes the shape of the problem. You may receive several plausible answers, overlapping changes, different assumptions about the same codebase, and a larger review queue. Parallel work is useful only when the tasks are separable enough that the gains are not lost to duplicate effort, merge conflicts, or unclear ownership.

• Use parallel agents for independent investigations, isolated files, bounded test cases, or clearly separated branches of a problem.
• Keep one owner for the definition of done. An agent can prepare work, but the acceptance rule should not fragment across every run.
• Give each agent a narrow authority boundary. More parallelism should not quietly mean more credentials, broader write access, or less review.
• Make integration a first-class task. The useful unit is not a completed agent run; it is a verified change that fits with the rest of the system.

An intervention is not a failure. It is a design signal.

The appealing story is that a successful agent ran unattended. The more useful story is often what happened when it could not. In the same September report, OpenAI says that more than half of the successful tasks it classified as taking a human four to eight hours involved one or more interventions. That does not make the agents ineffective. It suggests that longer work still benefits from active human steering.^[1]

Treat an intervention as a trace of an incomplete system design. Did the agent lack a fact? Did it choose the wrong tool? Did the task leave an important trade-off unstated? Was the finish condition too vague? Was an approval missing? Each answer tells you where to improve the harness, context, task contract, or evaluation—not merely whether to try a newer model.

1. Record the intervention pointCapture the task version, agent configuration, state of the work, and the exact decision a person had to make.
2. Classify the reasonSeparate missing context, unclear authority, tool failure, a bad plan, a quality issue, and a genuine judgment call. These require different fixes.
3. Change one system layerImprove the task definition, provide a small relevant reference, tighten a tool contract, or add a deterministic check. Do not change five variables and call the next run an improvement.
4. Run the same class of work againA reduction in useful interventions may show progress. A reduction in recorded interventions without better evidence may only mean the team stopped looking.

Measure the whole workflow, not the agent's output

Lines of code, number of tool calls, and number of agents started are easy to count. They are weak measures of whether the system helped. A practical workflow metric should include the result that reached production or the intended user, the evidence behind it, the review burden it created, and the cost of correcting mistakes.

Task: versioned and independently checkable

Outcome: did the change meet the acceptance test?
Evidence: tests, trace, review, and resulting system state
Human effort: framing + interventions + review + integration
Rework: fixes required after the first proposed result
Cost: model use, tools, and compute
Recovery: can the change be safely reverted or corrected?

This does not require a large dashboard. Start with a small sample of recurring work. The point is to identify whether the new bottleneck is task definition, review capacity, integration, or the agent's actual ability to complete the task. Without that distinction, a team can spend heavily on more autonomy while the real constraint remains untouched.

A comparison you can run this week

Pick five to eight small engineering tasks with a clear, testable finish line: bug fixes, documentation repairs, focused refactors, or test additions. Keep the model, access, acceptance criteria, and task type as consistent as possible. Then compare a sequential run with a small parallel run on separate branches or isolated workspaces.

1. Define the finish line before promptingWrite the expected test result, file state, or user-visible behavior. Do not grade an agent primarily on whether its explanation sounds plausible.
2. Keep the authority boundedUse the minimum repository and tool access needed for each task. Parallel execution should not expand the blast radius.
3. Track the full cost of completionRecord elapsed time, model cost, human interventions, review time, test failures, merge conflicts, and post-review rework.
4. Compare verified outcomes, not activityA faster first draft is not a win if it creates a larger review queue or produces more work after merge.