Does More Orchestration Make Better Research?

What eleven research systems revealed about orchestration, cost, and the limits of AI judges.What really makes one AI-generated research report stand out from another? Is it the underlying model, the quality of the sources, the way the workflow is stitched together, or just how much heavy lifting…

What eleven research systems revealed about orchestration, cost, and the limits of AI judges.What really makes one AI-generated research report stand out from another? Is it the underlying model, the quality of the sources, the way the workflow is stitched together, or just how much heavy lifting the system is allowed to do?In practice, these factors tend to blur together. If you’ve ever watched a polished demo, you’ll know how convincing the results can look, even when it’s hard to tell which design choices are actually doing the work. I found myself wanting to get under the hood and figure out which choices were genuinely worth testing.Deep-research systems are a useful way to explore this puzzle. They chase leads, comb through sources, and try to turn what they find into a coherent report. Some systems try to do everything with one agent, while others break up the work, bring in different viewpoints, or pass drafts through multiple rounds of review.Orchestration is the set of instructions that decides what happens next, who takes over, how information gets passed along, and when the job is finished.My curiosity about these questions started with work around CivTech Challenge 11.5 in 2025. The challenge was to make impact assessments more efficient and effective, work that involves gathering and making sense of evidence.That got me wondering whether AI could help. Exploring research agents as a possible approach led me to a comparative study of workflows using research benchmarks.Letting a system take another pass, whether by searching again or drafting afresh, struck me as a practical way to catch missed evidence or misread sources. But I wanted to see how workflows that built in those extra opportunities actually performed when put to the test.Building my own foundation model was well beyond my reach, and I had little interest in reinventing search tools from scratch. So, I compared nine research workflows, all built around GPT-4o, plus two local-model systems, to see how their results stacked up.But then I ran into a familiar snag: how do you actually decide which report is better? You can check facts and citations, but a full research report rarely comes with a neat answer key. Two reports may both be reasonable, even if they reach different conclusions.A longer report might look more thorough, but it could just as easily introduce more mistakes. More citations can give an impression of rigour without adequately supporting the conclusions. So, comparing these systems meant not just looking at the reports themselves, but also at the judgments used to assess them.In Bounded Returns to Orchestration, several workflows scored above the simple baseline, but the main comparison could not reliably distinguish the top five from one another. Changing the evaluator also changed the apparent size of the gains.I came away more sceptical that simply adding more layers of orchestration would reliably improve a research report. Some workflows did help, at least according to the judged results. But those higher scores deserved a closer look before I could say what a builder should actually take away.To get there, I need to start with what these workflows actually did, then show how I compared their reports and what the results can really support.Which orchestration approaches did I compare?When to search again — The simplest system I tested already had access to research tools. It did one round of retrieval, pulled out information from the sources, and made a single call to write the report. This single-pass baseline gave me a starting point: a system that could gather evidence and produce a sourced answer, with minimal orchestration around the writing stage.Iterative retrieval — first split the question into multiple searches, then gave the system a chance to go back to the research after drafting. It would look over its own draft for gaps, search again, and use whatever it found to improve the next version. This struck me as a sensible way to catch questions the first search missed.The reactive workflow — handed the model more freedom to decide its next move. It could choose whether to search, read, or work on a section, depending on how the investigation was unfolding. Its choices were still constrained by the available actions and the number of steps it could take.Simplified flows for the tested implementations. “Write once” means a single report-writing call; gathering and extracting evidence may involve additional model calls. Iterative retrieval also decomposes the initial question into multiple searches. Loops remain subject to stopping checks and execution limits.Dividing the investigationOther systems split the investigation into separate strands, so several lines of inquiry could contribute to the report.The supervisor-worker system planned research topics and delegated them to workers operating in parallel. It combined their findings, then checked for gaps that needed further investigation.The STORM-inspired workflow tackled the subject from several perspectives and simulated conversations. In my version, I also added a triangulation stage that sought additional evidence and compared claims. The idea was to broaden the investigation.Graph research built up a network of connected subquestions. Chasing down one question could lead to new follow-ups and fresh branches. The graph helped organise the inquiry, but it didn’t guarantee that the final report would be consistent or correct.These are the implementations or adaptations tested in the study. Different agent roles can be implemented through separate calls to the same GPT-4o model. STORM’s conversations are simulated, and its triangulation stage includes additional searching.Reviewing drafts and selecting directionsMERIDIAN grouped source material into topics and used an internal evaluation loop to review drafts and request revisions.The hierarchical breadth-and-depth workflow combined broad investigation with concentrated analysis. It reviewed gaps and decided where to direct further research. After writing, the implementation recorded a citation check, although that check did not automatically repair the report.Beam research explored several candidate research directions, retained promising ones, and developed them further. It selected paths through the investigation rather than choosing between finished reports.Calling all these activities ‘review’ can be misleading. Deciding what to investigate next is different from asking for a better draft. Neither necessarily checks whether a sentence is supported by its cited source.I needed to keep those activities separate when interpreting what each workflow had achieved.These internal checks help produce reports. They are separate from the external judges that score the finished outputs and do not constitute independent factual verification.The two local-model systemsThose were the nine GPT-4o workflows. I also wanted to see how practical it would be to conduct research locally, so I included two local model systems in the mix.One used Qwen2.5–7B in the simple research scaffold. The other used DeepResearcher, a local model already trained via reinforcement learning, with a learned loop to carry out multiple searches.This gave me a chance to compare two local deployments, though both training and search control changed at once. The local systems also used quantisation and stricter limits on generation and evidence than the GPT-4o workflows. Those differences made it hard to pin any results directly on model size.DeepResearcher was already trained before these research tasks. The comparison changes the deployed model and its research procedure; it does not measure reinforcement learning or parameter count in isolation.All nine GPT-4o workflows used the same model and interfaces for web search, academic search, and page extraction. They could still pull in different sources, make different numbers of calls, and spend different amounts. Those differences mattered when interpreting the results, because the comparison included the evidence and resource use that came with each workflow.To compare those reports, I needed to give the systems the same questions and decide what a good answer should contain.How I compared the reportsEach system faced the same set of ninety English-language questions. Forty came from DRACO, twenty from DeepSearchQA, fifteen from ResearchQA, and ten from LitQA2, with five custom questions completing the set. These were research benchmarks, not a test of whether the systems could carry out government impact assessments.A thorough human assessment of all the reports was beyond my resources for this investigation. Instead, I used three model judges: Claude Opus 4.1, Claude Sonnet 4.5 and GPT-5.2. Each assessed the reports against a rubric with nine dimensions, including factual accuracy, coverage, attribution and organisation. Those assessments contributed to an overall score between zero and one.It mattered to keep these dimensions separate. A workflow might produce a more complete report without actually improving its factual accuracy. Another could organise the material beautifully but still leave important parts of the question unanswered. A single overall score could easily hide those differences.There was a reasonable basis for trying model judges. In their study of MT-Bench and Chatbot Arena, Zheng and colleagues found that strong judges such as GPT-4 agreed with human preferences more than 80 per cent of the time in their conversational evaluations.But agreement about which answer people prefer does not establish that a judge can verify a long, sourced research report. Their study also documented biases involving answer order and verbosity, with susceptibility varying between judges.Writing a rubric didn’t guarantee that a model could apply it accurately. None of these report judges opened the cited pages; they just looked at the content in front of them. So their factual scores were really judgments about the reports, not independent checks against the underlying sources. I would need to test how well those judgments corresponded to checkable answers.For the comparisons, I paired reports answering the same question. If STORM and the baseline both answered a question, I compared their scores for that question, then repeated the comparison across their available matched outputs. This avoided treating a difference in question difficulty as though it were a difference between workflows.I used paired Wilcoxon tests to assess whether those score differences showed a systematic separation. There was another problem to account for: with eleven systems, there were many possible comparisons. Testing enough pairs creates opportunities to find an apparently convincing difference by chance. I used Holm correction within each judge to account for that multiplicity.The headline results also had to meet an extra requirement: a difference needed statistical support in the same direction under all three judges.That was a tough rule to meet. It helped reduce the risk of declaring a winner by accident, but it also made real differences harder to spot. If two systems failed to separate under that rule, I couldn’t claim they were equally good. And even if all three judges agreed, they could still be making the same mistake.Research workflows could search and extract pages. The report judges assessed the supplied text without opening cited pages. Comparisons used available reports that answered the same questions, with corrections within each judge and a strict requirement for supported agreement across all three.What the system comparisons showedThree workflows scored above the single-pass baseline under that strict rule: iterative retrieval, STORM and the reactive workflow.This lined up with part of what I expected: giving the system a chance to return to the research could help. But the successful approaches organised that work in quite different ways. Iterative retrieval circled back to fill gaps in a draft. STORM looked at different perspectives and compared claims. The reactive workflow let the model decide what to do next. The results gave me several candidates to consider, rather than a single obvious design to copy.The five highest average scores across the panel belonged to those three workflows, plus graph research and beam research. None of the ten pairs among those five passed the same all-three-judge rule. Other analyses indicated differences, so this was really an unresolved ranking under the main comparison, not evidence that the leading systems were interchangeable.I also tried changing the rubric weights, removing citation quality from the overall score, and, in turn, leaving out benchmark sources. The broad groupings held up better than the fine ranking. That made me more confident that the baseline contrasts were worth investigating.The questions themselves mattered too. Raw score gaps tended to be bigger in task groups where the baseline struggled, and smaller where it already did well.One relocation question made the difference especially easy to spot. The baseline just returned the question itself, whereas STORM produced a report. Whatever you might say about the quality of those outputs, one system had finished the job, and the other hadn’t.That doesn’t prove that STORM’s report was factually correct, or tell me which part of its workflow prevented the failure. But it does show why a useful workflow gain isn’t always about a subtle improvement in prose.What the extra work costThe unresolved ranking among the leaders still left a big question about spending.The estimated API execution cost of the baseline was about $0.32 per question. The leading five ranged from $2.42 to $5.66, with STORM at the expensive end. Its estimated bill was about 17.5 times higher than the baseline.That price difference would matter to me if I were building a system. I’d want to compare STORM with a cheaper leading candidate on the questions my application actually needed answered. Maybe a real difference in quality would show up, or maybe reliability and latency would settle the choice.The benchmark gave me no reason to assume that either the cheapest or the most expensive candidate would be the best pick for my needs.The dots show raw mean scores across the three judges; the bars show estimated API execution cost per question. Each workflow contributed between 87 and 90 available reports. These are point estimates, with no uncertainty intervals drawn. Close means do not establish equivalent quality. The cost estimate does not cover engineering or the operational consequences of latency and failures.This raised a classic attribution problem: were the workflows actually benefiting from how they organised the work, or just from being allowed to do more of it?A limited follow-up cut iterative retrieval’s budget closer to the baseline’s on twenty-nine questions. It still spent about two and a half times as much as the baseline. Under GPT-5.2’s judging, its estimated advantage dropped, but the direct comparison between the full-budget and reduced-budget runs remained uncertain. The result couldn’t tell me how much of the original gain came from the extra spending.A stronger baseline can also change what seems impressive. In their main comparison, Zhang and colleagues found that published multi-agent debate methods generally struggled against alternatives using step-by-step reasoning or selecting among independently generated answers.Follow-ups improved some debate results by changing prompts or mixing models. These were knowledge, mathematics, and coding tasks, with total token use not matched throughout. They do not settle my research-report comparison, but they strengthen the case for testing a capable simple alternative.The question of spending also comes up in providers’ own accounts. Anthropic writes that “multi-agent systems work mainly because they help spend enough tokens to solve the problem.” For a provider that charges per token, extra usage also means more revenue.That gives me a reason to look closely at the economics of a recommendation. It does not establish why a provider recommends a particular design. Their practical guidance is also conditional: OpenAI recommends developing a single agent’s capabilities first, while Anthropic recommends increasing complexity only when needed.For my own application, I’d still want evidence that the extra work actually bought me something I needed.What the model comparison addsChanging the model offered another possible route to better results.Under the simple research scaffold, GPT-4o scored about 0.23 higher than the deployed Qwen2.5–7B system on the panel mean. Adjusting for report length roughly halved that gap, but didn’t erase it. This was a sensitivity analysis, not a way to recover a known unbiased score. Training and deployment conditions also differed, so the comparison didn’t isolate parameter count.DeepResearcher scored above the simpler local system, but it changed training and search control at the same time. That was useful evidence about the two deployments, but it didn’t show how much either change contributed.There’s a reasonable objection here: maybe a small model needs more capability before it can make good use of a complicated workflow. A twelve-question probe ran iterative retrieval and STORM on the 7B backbone, with GPT-5.2 serving as the judge.It didn’t detect statistically supported gains, but the uncertainty still allowed for meaningful improvements. That left the capability question open.That uncertainty is really about what the local model could do with more orchestration. It doesn’t explain the relative scores of the nine workflows that all used GPT-4o. I’d assess a model and its deployment settings alongside its workflow, rather than assuming a general capability threshold based on this small probe.How far did the findings travel?The main results came from my own implementations on one question set. But I also wanted to know whether the same contrasts would show up elsewhere.A reduced comparison using GPT-4.1 again found a positive STORM-versus-baseline score difference under GPT-5.2. Its coverage was incomplete, with some expensive questions absent from the matched results. A separate, broader GPT-4.1 batch also found an average advantage for a selected group of workflows under GPT-5.2 and newer Claude judges, but coverage was uneven across systems. It did not establish a dependable detailed ranking either.A further comparison generated six hundred reports on fresh questions using the single-pass, iterative-retrieval, and STORM workflows. GPT-5.2 judged them. Iterative retrieval and STORM again had higher mean scores than the baseline, but their order differed from that judge’s main-study order.This was evidence from three workflows under one judge. The planned comparison against expert annotations was incomplete, and the exercise did not repeat the main all-three-judge test.Taken together, these follow-ups gave me more reason to take certain baseline advantages seriously, while leaving the fine ordering less secure.The task also changes the value of coordination. In Towards a Science of Scaling Agent Systems, Kim and colleagues found substantial benefits from coordination on a financial-analysis benchmark. At the same time, all four multi-agent architectures had lower mean performance than the single-agent baseline on PlanCraft, a sequential-planning benchmark.Their single agent could already use tools and work through several steps. The benefit depended on the task and the arrangement of the work. My research-report comparison cannot establish what that benefit would be in a different application.Changing the model or the questions wasn’t the only way to change the apparent result. Even when the reports stayed the same, changing the judge changed how much improvement I seemed to have found.What the comparison revealed about AI judgesFor six workflows selected by their average panel scores, the advantage over the single-pass baseline was about 0.145. These were the leading five discussed earlier, plus the hierarchical workflow.When I used GPT-5.2’s scores alone, their average advantage was about 0.066. Nothing about the reports had changed, yet the estimated gain was less than half as large.The same six selected workflows are compared with the single-pass baseline, first using the three-judge mean and then GPT-5.2 alone. Points show raw overall-score differences; whiskers show reported 95 per cent paired bootstrap intervals, resampling the 90 questions. Selection used panel means; the intervals do not account for that selection. The panel includes GPT-5.2, so these are overlapping assessments, not independent replications.That didn’t make GPT-5.2 the right judge. It meant I needed to understand the disagreement before treating either figure as a measure of better research.The judges agreed much more about organisation than about factual accuracy or information recall. They could give similar assessments of how a report was presented while disagreeing over its substance. The two Claude judges also contributed overlapping judgments. The paper’s estimate of that redundancy put the three-model panel at about 1.65 effective judges.That is an estimate of correlated information, not a literal count of independent votes. Choosing models from different families might help, but it would not by itself establish that their errors were independent.Checking the judges against known answersI checked the factual scores against a limited set of mechanically checkable answers. The check covered 259 reports from twenty-seven questions, with passing reports coming from eleven of those questions.It included a check for whether the expected information was present, so passing did not guarantee that every claim in a report was correct.GPT-5.2’s factual-score AUC was about 0.65. One way to understand that number is to take a randomly chosen passing report and a randomly chosen failing report. GPT-5.2 gave the passing report the higher factual score about 65 per cent of the time, counting ties as half. A value of 0.5 would mean chance ordering. This is not the same as correctly classifying 65 per cent of all reports.The corresponding estimates were about 0.54 for Opus 4.1 and 0.49 for Sonnet 4.5. Only GPT-5.2 showed a statistically significant difference in factual scores between passing and failing reports. The other comparisons remained unresolved. The check covered only part of factual quality. It was not a human audit of the reports and their sources.Points show AUC for 259 reports from twenty-seven questions; passing reports came from eleven questions. The 0.5 reference indicates chance ordering. No confidence intervals are drawn, so statistical significance cannot be read from the dots alone. AUC is not classification accuracy.What the report judges could seeThe known-answer check made the absence of source checking harder to overlook. Some STORM reports used entries such as “Web Search Synthesis” where a reader needed a followable citation.These were labels from the search software, not necessarily invented sources. But a reader could not open the label to check the supporting passage, and the report judges did not perform that check either.Citation density raised another concern. The two Claude judges associated denser citations with higher factual scores, even after accounting for the measured provenance features. GPT-5.2 did not show that association. This did not prove that adding citations caused a higher score, but it left open how much the judges were responding to support and how much to its appearance.Report length posed a similar problem. All three judges associated longer reports with higher scores. Adjusting for length sharply reduced the selected workflows’ apparent advantage, sometimes leaving it statistically undetectable.Yet a longer report might contain useful additional evidence as well as unnecessary prose. Those sensitivity analyses couldn’t separate the two or reveal a known ‘true’ score hiding under a verbosity bonus.The paper also examined evaluator dependence across six external research codebases. In Open Deep Research, switching from Azure Search to Tavily produced an uncertain change in score with GPT-5.2, while Opus 4.8 and Sonnet 5 showed positive increases in the same comparison.These were newer Claude judges than those in the main panel. Different budgets, some model assignments, and completion rates meant this was a separate comparison rather than a controlled repeat of the main study.I couldn’t just shrug off these problems as harmless differences of opinion. They weakened what the scores really told me about factual quality, and made fine rankings harder to defend. Still, the recurring advantages in scores and the differences in cost were hard to ignore.A higher score could come from finding better evidence, using it more effectively, or producing a report that the evaluator preferred. The supporting experiments asked narrower questions about the evidence and the writing.What sources and revision changedWhat happened when I supplied the sources? I gave the nine GPT-4o workflows a common pool of previously retrieved sources for each of thirty questions. This let the simple workflow draw on material gathered through more extensive research. The pool was not known to contain everything needed for a complete answer.The supplied material came from earlier retrieval and was not guaranteed to contain everything needed for a complete answer. Whole-report scoring and excerpt checking covered different subsets and answered different questions.Under GPT-5.2, the selected six-workflow group’s overall-score advantage over the baseline narrowed from about 0.04 with live retrieval to about 0.01 with pooled sources.The uncertainty around that reduction included the possibility of no change. It was a reason to investigate source access, without establishing how much of the workflow advantage it explained.The rubric dimensions told different stories. Across 179 matched report pairs from those six workflows, citation quality rose by about 0.162 and information recall by about 0.071, while the whole-report factual score changed by about minus 0.007.These were absolute changes on zero-to-one scales. The simple baseline was outside that aggregate; its estimated factual-score increase was about 0.05, with uncertainty spanning no change.The judge had registered improvements in citation quality and information recall. But had factual accuracy also improved without showing up in the whole-report factual score?A smaller automated check looked at whether evidence excerpts supported individual claims. GPT-4o performed that check on fifty-three report pairs from five workflows. This was a different sample and a different measurement from the whole-report assessment. Under the strict support rule, the average change across the five workflows was 0.092.But the definition of support mattered enough to reverse the estimated advantage. The checker could label an excerpt “neutral” when it was about the right topic without stating the claim. When those neutral verdicts were counted as support, the estimated change became slightly negative, at about -0.011.The checker also saw excerpts or fallback material rather than necessarily all the relevant evidence. It could miss a supporting passage or an inference that depended on several sources together. No human panel validated its verdicts.The 0.092 improvement was therefore an absolute change in strict claim support, not a finding that retrieval fixed 9.2 per cent of the reports’ factual errors.Upper panel: 179 pairs from six selected workflows, assessed by GPT-5.2, with reported 95 per cent intervals. Lower panel: fifty-three pairs from five workflows, checked by GPT-4o under two support rules. Lower intervals are omitted because the released calculations used different resampling procedures. The panels do not distinguish between factual errors in retrieval and in writing.The paper describes a possible limit on how well a model uses available evidence, a kind of synthesis ceiling. I’d treat that as a hypothesis suggested by these experiments.A flat factual score could mean the writer struggled to use the evidence, the evaluator missed an improvement, or the source pool still lacked something important. The claim check didn’t tell me how much each explanation contributed.Writing again from the same evidenceA separate experiment held the evidence fixed and compared different ways of writing from it. GPT-4o-mini wrote the reports. A three-call sequence that drafted, critiqued, and revised scored higher for factual accuracy than writing once: about 0.079 under GPT-5.2 and 0.125 under a separate Sonnet 5 evaluator.The experiment also tried summarising evidence in groups, investigating alternative drafts, and selecting drafts with a verifier. None detectably beat writing once under the primary judge.A method’s failure to beat the baseline did not establish that it was worse than revision. Those baseline tests could not settle the relative ordering, and the methods also used different resources.This supported a particular writing procedure with evidence held fixed. It did not explain the gains in the main GPT-4o architecture comparison.Giving the revision specific guidanceAnother experiment asked whether guidance helped when revision was already taking place. This time, GPT-4o revised existing single-pass and STORM drafts.Both arms revised without new retrieval. In the guided arm, a checker first read the question, draft, and rubric, then suggested fixes. The rewriter received the question, draft, and suggested fixes. Neither the checker nor the rewriter received source pages.The first experiment compares writing once with drafting and revising from the same evidence. The second compares guided with unguided revision of existing drafts. The guided checker receives no source pages; the guided arm permits additional checking work.Under GPT-5.2’s overall rubric, guided revision scored about 0.04 above unguided revision for both sets of drafts, with thirty questions in each comparison. Both gains survived correction for the two comparisons. This was an improvement in the overall rubric score, distinct from the factual-score result in the fixed-evidence experiment with GPT-4o-mini.There is a budget claim in the paper that I need to correct. It describes the guided and unguided revisions as budget-matched. The released code gives both arms the same rewriting allowance but permits additional checks in the guided arm.The available records do not establish equal total compute for the original run. Guidance improved the judged score against this control, but the result does not establish that it was a better use of a fixed total budget.Upper panel: factual-score changes against writing once, with thirty paired reports under GPT-5.2 and twenty-nine under Sonnet 5. Lower panel: overall-score changes on thirty pairs per workflow, with both arms revising. Whiskers show individual reported 95 per cent intervals. Equal total compute remains unverified for guided revision; neither panel independently verifies factual repairs.The guided reports were judged using the same rubric that supplied the suggested fixes. That is useful evidence that guidance can improve performance against those criteria. To establish that a factual error had been repaired, I would still need to check the claim against its sources.Other revision studies show why it is worth being this specific about the comparison. Madaan and colleagues’ Self-Refine reported improvements across several tasks when a model generated feedback on its own output and then revised it.That comparison was against an initial response, rather than an alternative using the same total inference budget. It supports investigating revision, but does not establish that revision is the best use of the extra computation.Huang and colleagues later identified a specific problem in one of those tasks. The model had to write a passage containing a supplied set of concepts. Making that requirement explicit in the initial prompt produced better concept coverage than the earlier revision procedure.Applying revision to the stronger initial response then reduced coverage. In that experiment, some apparent benefit of revision depended on instructions that the first attempt should already have received. That challenges the attribution of the gain, without showing that revision fails on every task.My guided comparison asked a different question because both groups revised an existing draft. It tested whether structured feedback helped that revision. Huang’s result suggests another control for a future investigation: give the initial writer the same general requirements expressed in the feedback, then check how much the additional revision still contributes.Conclusion: What I would test nextI came away from this comparison with reasons to use orchestration, but fewer reasons to believe that simply adding more of it would help. Iterative retrieval, STORM, and the reactive workflow scored above the simple baseline under the main judging rule.But the comparison couldn’t reliably rank the top five, even though their costs varied widely. These findings give me candidates to test, but they don’t make complexity itself a reason to prefer a system.The investigation also changed what I’d accept as evidence of improvement. The judges could agree about presentation while disagreeing about substance, and swapping out the judge changed the apparent gains.Their scores were still useful for comparing performance against the rubrics, but not enough to establish factual correctness. Statistical correction can help guard against chance findings, but it can’t make a judge spot an error it has missed.The source and revision experiments offered more specific possibilities. Supplying sources improved citation and recall scores, while the factual results depended on how support was measured. Revision produced promising score gains in the particular comparisons I tested.But neither result removes the need to check whether the intended factual repairs actually happened, or whether another use of the same resources would work better.For the impact-assessment work that first got me thinking about this, I would start with a simple, capable system focused on the questions people actually need answered. I would keep examples of where it fell short, along with the evidence it had when it wrote the answer.If relevant information never reached the writer, I would test retrieval. If the report misrepresented information already available, I would test writing or revision. If the evaluator missed an error I could demonstrate from the source, I would improve the assessment before using its scores to choose a system.Guided revision is one candidate I would take seriously. I would compare it on the same drafts with a budget that counted checking as well as rewriting, then examine the original errors, any new errors, cost, latency, and failures.I would ask the same of another search stage or an additional agent. If the score improved but the errors that prompted the extra work remained, the system would have failed the test I needed it to pass.This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!Does More Orchestration Make Better Research? was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source: Generative AI Pub — Published September 11, 2026 at 00:23 UTC — Category: Image AI