Listen to this article
AI may have been used to generate this audio.
Press Space or K to play or pause, and J or L to go back or forward 15 seconds.Sources checked 27 September 2026.
Imagine four agents finishing four tasks while one person is in a meeting. When that person returns, they have four sets of decisions to inspect. The agents were able to work at the same time. The reviewer still has to understand what happened in each task.
This is an illustrative workflow, but it shows why counting delegated tasks can give an incomplete account of someone’s day. The person may spend less time producing a first draft and more time reconstructing context, checking changes and deciding what can proceed.
BCG researchers reported on a study of 1,488 US workers at large companies in March 2026. They examined mental fatigue associated with excessive AI use and oversight, using the term “AI brain fry”. The findings come from a workplace study of reported experiences; the term should not be treated as a clinical diagnosis or a universal limit on how many tools someone can use. [1]
The review queue
Take a hypothetical team producing changes to an application. One agent modifies permissions, another updates a report and a third edits the billing interface. The work can arrive quickly, but a reviewer may need different context for each change. The permissions task may also affect the report.
A manager looking only at completed agent runs could miss that dependency. A useful work board would show items awaiting review, items returned for correction and items accepted for release. An agent’s completion message would move the task into review, with the release decision still visible.
The size of the queue matters because waiting work can lose context. The person who requested a change may have moved on, and the reviewer may have to reconstruct why an apparently odd choice was made. Letting more tasks start while those questions remain open can create additional work to coordinate.
Eight arrivals and six reviews
Put numbers on a deliberately simplified week. Four agents each return two changes a day, giving eight arrivals. The reviewer can finish six reviews a day. Starting with an empty queue, two changes remain after the first day and ten after the fifth. Faster generation has increased the amount waiting; accepted throughput remains six a day under these assumptions.
Real work is messier. Reviews differ in length, rejected changes return, and an urgent production issue can consume the reviewer’s day. The example leaves those effects out to isolate the arithmetic. Even this generous version cannot clear a queue whose arrivals persistently exceed completions.
The team has several possible responses. It can start less work, reduce the work required to review each change, or add capable review time. Asking the same reviewer to monitor more parallel tasks does not, by itself, do any of those things. A queue limit makes the trade-off visible: an available agent may wait while the team finishes a decision already in progress.
An automated check can remove part of the review burden if it tests something consequential. A test showing that a report excludes another customer’s records is useful evidence about that boundary. A summary saying “privacy checked” makes the reviewer find out what happened. The value comes from the test and its scope, not from the confidence of the handover.
Track | What it helps the team decide |
|---|---|
Items waiting for review | Whether to start more work |
Time spent reviewing and correcting | Whether a task is suitable for delegation |
Reasons work is returned | What context or acceptance conditions are missing |
Dependencies between changes | Which tasks should proceed together |
Interruptions during review | Whether reviewers have enough uninterrupted time |
Give the reviewer something usable
An agent can return a concise account of the change, the relevant files, the checks it ran and the questions it could not resolve. The reviewer should be able to inspect the evidence. A reassuring paragraph saying that everything looks good adds another claim to verify.
For repeated work, compare the cost of reviewing an assisted result with the cost of doing it directly. A small task can be cheap to perform but surprisingly awkward to audit after somebody else has made several choices inside it. A larger task with clear tests can be easier to delegate.
These are workflow proposals, not effects established by the BCG study. The team would need to try them and observe its own review work. It should also be willing to stop delegating a task if the coordination cost repeatedly exceeds the benefit.
The reviewer has to know what to look for
Shen and Tamkin’s 2026 experiment tested developers learning Trio. The assisted group scored lower on an immediate quiz; completion-time differences were statistically uncertain. [3] A learning result this specific cannot forecast every developer’s future ability, but it gives a team something more concrete to examine than whether participants liked the tool.
The relevance to supervision is fairly direct. If the work someone delegates also supplied their opportunities to learn, the team needs to decide where that learning now happens. Giving a person an approval button does not give them the knowledge needed to evaluate the change behind it.
This does not require turning every task into a lesson. A team can identify the parts of a system that each reviewer must be able to explain and debug. For a new permissions mechanism, that could include tracing a denied request, finding the policy that caused it and identifying a test that would catch a cross-workspace leak. Those abilities can be checked with the assistant unavailable.
The study’s qualitative analysis linked better quiz performance with some more engaged patterns of AI use, but those patterns were not randomly assigned. [3] They suggest questions for training design rather than a proven instruction to “ask for an explanation”. Reading a fluent explanation and being able to diagnose a new failure still need separate checks.
A useful team experiment would reserve one unfamiliar change for a paired review. The author explains the mechanism; the reviewer changes an input and predicts what will happen; both inspect the result. Record the time as work. If it improves later reviews, the benefit should appear in fewer corrections or more accurate decisions, not merely in participants saying they understood.
DORA’s current AI capabilities model includes working in small batches among the capabilities relevant to outcomes from AI adoption. [2] A small change gives the reviewer a more bounded decision. It also gives the team a chance to correct a missing requirement before several dependent changes accumulate.
In the example with permissions, reporting and billing changes, the team may need the permissions review to finish before accepting the report. Starting another report task would add to that dependency. The work board should make the wait visible so the team can finish the decision already in progress.
Sources
One email when we publish. Research, product decisions, and what teams report back.
