Multi-engine deep research

The point of running one question through several deep-research products is coverage, not consensus. What should come back is a deduplicated list of sources, with a column showing which engine found each one. The researcher then works the list. Sources found by one engine only are the interesting rows, in both directions.

The prose each product returns is a byproduct. ChatGPT, Gemini, and Claude Deep Research all write competent syntheses, and three competent syntheses of the same question are three pieces of writing nobody needs. Strip them. Keep the citations, the retrieval dates, and any claim that carries a specific number or a named actor.

This sits at the source stage, and it produces candidates. It does not produce findings. Every source on the merged list is unverified until a person opens it. Treating the merged output as a literature review, because three systems agreed, is the mistake this method makes easy.

The effort is genuinely low. Three subscriptions, one query, twenty minutes of merging. The value depends entirely on whether anybody does the reading afterward.

Small wording differences change what comes back, which destroys the comparison. Compose the query once, in a file, and paste the same text into each product. If a product needs a different format, note the change on the record. A comparison of three engines that were asked three slightly different questions tells you nothing about the engines.

Put four things in the query. The question itself, tightly bounded. The date range that matters. The jurisdictions or populations in scope. And an instruction on what to do when nothing is found, which should be to say so. Without that last instruction, at least one engine will produce a well-formed answer about an adjacent jurisdiction.

Record the date and time of each run. These products index the live web, and a question about a moving regulatory file returns different sources in the morning and the afternoon. Undated runs cannot be compared with each other or repeated later.

Do not run this on a question that has not been scoped. The method multiplies whatever question you feed it by three, including a vague one. If the branches are still being argued about, finish the hypothesis tree and screening criteria first. A vague query returns three vague briefs and a satisfying feeling of thoroughness.

Build one table keyed on the source. Each row is a document: title, publisher, date, locator, and a column per engine marked found or not found. Then add the claim each engine drew from it. Sorting the other way, by claim, hides the fact that two engines cited the same paper for opposite things.

Match on identifier where one exists. A DOI, a document number, a regulation reference. Titles get paraphrased, publishers get renamed, and URLs differ between a landing page and a file. Where no identifier exists, merging by title similarity works, and it is the same technique used for merging near-duplicate candidate records.

Keep a separate list for sources that cannot be resolved. An engine will sometimes cite a document that does not exist, or attach a real publisher to a title that publisher never issued. Those rows go on the unresolved list, not in the corpus, and the researcher checks a sample of them because their rate tells you how much to trust the rest of that engine's output.

Then sort by engine count ascending, not descending. The rows every engine found are the obvious literature, and the researcher probably already knows them. The rows one engine found are where the marginal value is, and they are also where most of the errors are. Both reasons argue for reading them first.

Consider an invented example. A parliamentary research service has been asked for a briefing on how other jurisdictions handle end-of-life electric vehicle battery recycling, ahead of a committee session in three weeks. The researcher has two days for sourcing. The scope names six jurisdictions and a five-year window.

The same query goes to three products on the same morning. Merged, the table holds sixty-two distinct sources. Nineteen were found by all three. Twenty-four by two. Nineteen by one engine only. Four rows go straight to the unresolved list: three cannot be located at all, and one turns out to be a real consultancy report with a title that has been altered.

The nineteen everyone found are the expected set: two directives, several trade association position papers, and the review articles that turn up in any search on this topic. The researcher would have found them in an hour. They still go in the corpus, and they take fifteen minutes to confirm.

The single-engine rows are mixed and worth the time. One engine surfaced a regulator's consultation response file from a jurisdiction the others treated superficially, which contains the operational detail the committee will actually ask about. Another surfaced a set of trade press articles that add nothing. A third surfaced a national standards document in a language the others did not search, which the researcher cannot read and routes to a colleague who can.

The consultation response file is the return on the whole exercise. It was found once, by one product, and it would have been missed by a single-engine run. Nothing about the other two engines missing it says anything about its quality, in either direction.

This is the failure that matters. Three products converging on the same claim feels like triangulation and is not. They read overlapping web indexes, they weight authority in similar ways, and they inherit the same upstream errors. If one widely quoted secondary source misstates a figure, all three will repeat it, and the merged table will show three ticks next to a wrong number.

Never write "confirmed by three engines" anywhere. Corroboration means two independent sources, traced to their origins, saying the same thing. The engine column measures retrieval overlap. It is a fact about search behavior, not about the world, and it should be labeled that way in the file.

The second failure is volume without gain. Three engines on a well-trodden question return three versions of the same reading list plus noise. Save the method for questions where coverage is genuinely uncertain: unfamiliar jurisdictions, fast-moving files, fields with weak indexing. On a mature literature, a semantic search over the right corpus beats three general engines.

The third is the disappearing source. Engines cite pages that change, move, or vanish. Capture the locator and enough of the passage to identify it at the moment of retrieval. A briefing that cites a page which no longer says what it said is worse than a briefing that cites nothing.

Nothing from any engine enters a briefing without a human reading the underlying document. This is not a sampling exercise. Every source that will be cited by name gets opened, and the claim attached to it gets checked against what the document actually says.

The characteristic error is not a hallucinated document. It is a real document, correctly cited, that does not contain the claim placed next to it. That error survives every check except opening the file. Catching it systematically is the job of checking each claim against the passage cited for it.

The researcher also decides what the merged list does not cover. Three engines searching the open web will miss anything behind a paywall the institution does not hold, anything unpublished, and anything in a language none of them searched. Write those gaps into the briefing as gaps, with the date of the runs.

Keep the merged table after the round closes. It records what was reachable on a given morning, which is the only defensible answer to a later question about why a source was missed. It also becomes the starting corpus if the same file returns to committee, alongside prior internal work and what it led to.