Another review is not necessarily another improvement. In a paired experiment on AI-generated business reports, teams whose Manager could force revisions used more tokens and received lower usefulness scores than teams without that power.
This explainer and the film below follow the research shared in AIDB’s original X post (@ai_database). The primary source is Loop-Back Authority in LLM Agent Teams: A Paired Experiment on Flat and Hierarchical Coordination by Burak Agachan, Max van Duijn and Amirhossein Zohrehvand, a September 13, 2026 preprint. The explanation below draws on the paper and its supplementary material, not only the social post.
Watch: I Thought I Was Done.
English audio and captions · 1:48. A Writer starts a going-home vlog, receives a revision request, and wonders what actually improved. The opening and closing cards identify the AIDB post and the paper.
What changed between the two teams?
The researchers assigned five roles: Researcher, Analyst, Writer, Critic and Manager. The task was to turn product specifications and customer reviews into business-intelligence reports. They compared two configurations for each of 43 products, producing 86 runs. Role-level model assignments were matched within each product pair.
In the flat configuration, the Manager coordinated work and could leave nonbinding comments. In the hierarchical configuration, the Manager could reject a worker’s output and require another pass, with a revision cap. Both configurations included a Manager and a Critic: this was not a comparison between having a boss and having no boss.
Loop-back authority was the central intervention, but the operational configurations also differed in the history agents saw and in their stopping rules. That matters when attributing the observed differences to a single mechanism. See the methods and supplementary Section F.
More computation, lower usefulness
A five-model judge panel evaluated the reports. The table shows the authors’ reported means, not measurements made by AgentCollusion.
| Measure | Flat | Hierarchical |
|---|---|---|
| Usefulness / 5 | 4.715 | 4.621 |
| Writing clarity / 5 | 4.454 | 4.360 |
| Mean total tokens | 49,370 | 74,781 (+51.5%) |
Usefulness favored the flat configuration in the paired comparison (p = .009, paired effect size d = .417). Writing clarity also favored flat in the primary analysis (p = .030), but that finding was more sensitive to evaluator choices and alternative tests. The overall final-score difference was not statistically significant (p = .097). See Table 2, Section 4.4, and supplementary Table 12.
The token overhead was traffic across the workflow, not evidence that the final reports were half as long again. Final report length did not differ significantly. On a repaired specification-checking measure, accuracy was near ceiling in both conditions.
What did the revisions change?
The authors found more hedging—phrases that soften a claim—in hierarchical reports: 5.03 versus 3.30 occurrences per 1,000 words. Lexical diversity was similar. Their draft comparisons locate the emerging quality gap inside the revision process rather than in an obviously worse starting draft.
This motivates the film’s scene where the Writer changes a sentence into something more cautious, then pauses. The particular sentence and the character’s self-doubt are invented. Hedging can be appropriate; the study does not establish that every cautious expression is an error, or directly observe an agent’s inner motive.
The authors interpret the pattern in terms of compliance with authority. That interpretation should be distinguished from the observable changes in text and scores. The association between more loops and worse clarity is not, by itself, proof that each additional loop caused the decline: the Manager chose when to request revisions.
What this does—and does not—suggest for builders
A useful engineering question is whether a revision request points to a verifiable problem. A failed check, missing requirement or unsupported claim gives the worker a concrete target. A general request to sound better may reward the appearance of compliance instead.
Our practical proposal is to retain the reason for a revision, the evidence behind it, the before-and-after output, and the cost of the extra pass. Evaluate whether the result actually improves. These are design proposals, not interventions validated by this experiment.
The paper is a preprint about one family of open-ended reporting tasks, with 43 product pairs and model-based evaluation. It does not show that managers are always harmful, that revision should be disabled, or that the same effect holds for code with executable tests. The broader lesson is to measure oversight by the improvements it can demonstrate—not by how many corrections it issues.
