Google Deep Review Is Here to Check Long, Hard Documents
On October 14, Google Research publicly launched Deep Review, a tool built to read a long technical document closely and tell you where the logic wobbles, where a claim lacks support, and where one section quietly disagrees with another. I read a lot of dense documents in my work, and I often finish one with a nagging feeling that I missed something on page thirty. A patient second reader built for exactly that job got my attention fast.
Google describes Deep Review as an agentic system that gives rigorous feedback and technical checking on complex documents, in a post by research scientists Rajesh Jayaram and Vincent Cohen-Addad on the Google Research blog. It started as a helper for academic papers. Anyone can now try it with a small free allowance each week.
What Google launched on October 14
Deep Review grew out of the Paper Assistant Tool, which Google offered to authors before submission deadlines at STOC 2026, ICML 2026, NeurIPS 2026, and ICLR 2027. Google says authors of more than 16,000 manuscripts chose to take part over the past year. That history matters. This tool has already read a large pile of real, difficult papers.
Writing has become much faster with AI help, while careful reading still takes the same human hours it always did. Google points to its own field, saying ICLR, NeurIPS, and ICML together drew over 74,000 submissions this year, up from about 45,000 in 2025. Treat those as Google’s own figures. The direction is still easy to recognise. Documents arrive faster than anyone can read them well.
Access is simple on paper. Google says Deep Review is available worldwide, every user gets two complimentary document reviews per week, and people with heavier workloads can connect a Gemini API key for higher limits and programmatic use through the Deep Review API. At launch it accepts PDFs and plain text, with support for multi-file inputs still to come. R and D World, reporting from Google’s Research@ event in Mountain View, adds a practical detail I liked. Jayaram told the audience that a review takes about 10 to 20 minutes and that comments come back anchored to the text they refer to. Anchored comments are the difference between useful feedback and a vague list you have to hunt through the document to apply.
How Deep Review reads a long document
Google lays out a four stage pipeline, and the design is the part I find most sensible. A single model call on a very long document tends to skim. It runs out of room to think, loses track of a definition from an early section, or accepts a confident claim without pressing on it. I have seen all three happen when I paste long reports into chat tools.
Deep Review starts by splitting the document into logical segments, such as an introduction, a method section, and experiments. Next it decides how much effort each segment deserves. Google gives the example that a section dense with mathematical proofs may receive more compute than an introduction. Then specialist agents study each segment in parallel, with the full document in view so they can follow cross references. Finally, a synthesis agent pulls the reports together, runs consistency checks between sections, and does external grounding checks.
That shape will look familiar if you read my earlier piece on watching what AI apps and agents actually do. You trust an agent more when you can see its steps. Here the steps are visible in the design itself, and each one gives a human reader specific comments to accept or reject.
What the earlier pilots found
The strongest evidence sits in the team’s own paper, Towards Automating Scientific Review with Google’s Paper Assistant Tool, posted on arXiv. On a filtered test set of 26 papers holding 29 known mathematical and proof errors, the authors report the pipeline found 89.7 percent of the errors, while a single call to Gemini 3.1 Pro found 55.2 percent. Those are Google’s researchers reporting on their own system, on a small and deliberately narrow test set, so I would not stretch the numbers beyond that. Within those limits, the gap supports the main idea. Careful orchestration finds more real errors than one quick pass.
The paper also reports the pilot surveys. In the STOC and ICML programs, more than 90 percent of surveyed authors called the feedback very or mostly helpful, and over 90 percent said they would use it again. The complaints are listed plainly too. Early users hit date mistakes, PDF parsing trouble, and cases where the tool wrongly said a sound proof was broken.
That last point is the one I would tape to the monitor. A tool that sometimes objects to correct work is still useful, as long as you treat its comments as leads to check rather than rulings to obey.
Where this helps outside research papers
Google is pitching Deep Review well beyond journal submissions, and I can see the fit. For design documents, Google says it can surface unstated assumptions, spot edge cases, and suggest concrete improvements. For presentations, it can check that slide flow makes sense and that written takeaways match the charts beside them. For legal and financial documents, it can look for internal consistency across clauses and data tables, flag ambiguous terms, and press on claims that lack supporting evidence.
My own shortlist is more ordinary. A long proposal where the pricing table and the scope section came from different people. A migration plan where step four depends on something step two never does. A report where the summary promises slightly more than the findings support. Those documents embarrass teams a week after sending, in front of the one reader who went through every page.
Two launch limits are worth planning around. Multi-file support is still coming, so you cannot yet hand it a document with its spreadsheets and exhibits for one joined up check. Accepted inputs start at PDF and plain text, so slide decks will likely travel through a PDF export first. Glance at that export before uploading, since tables and charts are where exports go crooked. The wider pattern matches what I saw in my Codex Cloud post, where agents keep working through a task list while a person stays in charge of the result.
What to watch before you trust it
Privacy first, because these are the documents you least want floating around. Google states that uploads are never used to train, fine-tune, or improve Google models. The same paragraph says uploads are stored for one year, for the sole purpose of showing them back to you in the Deep Review interface. Both halves matter. Think about that year before you upload a contract under negotiation or anything covered by a client agreement. Your organisation’s rules should make that call, not a launch blog.
Accuracy comes second. The benchmark above used a small set of papers with known errors, chosen to suit the tool’s strengths. Real documents carry softer problems, such as a claim that is technically true and still misleading. Expect Deep Review to be strongest on logic, consistency, and missing support, and weakest where judgement needs context it cannot see. Treat a clean report as a good sign, never as proof.
Google says the system handles some of the heaviest checking while leaving higher level judgements to humans. R and D World quotes Nika Haghtalab, a UC Berkeley computer scientist and NeurIPS program chair, making a similar point at the launch, saying that detailed checking early can leave researchers more time to judge what is novel and what matters. That is the right split in my view. Machines counting cross references all day is a good trade. Humans deciding whether the work deserves to exist is not a job I want to hand over.
How I would try it this week
You get two free reviews a week, so I would spend them deliberately rather than feeding the tool the first PDF that comes to hand.
Pick one finished document that a knowledgeable colleague has already read and marked up. A design document, a proposal, or a report you have already sent is ideal, because you hold a human answer key. Run Deep Review on the same file, then compare the two sets of comments side by side. Count how many of its points are real, how many repeat what your colleague found, and how many fall apart when you check them against the text. That single comparison will tell you more about its judgement than any launch claim, mine included.
My next step is the comparison test above, with a report I already know well. Set aside half an hour, keep your own notes beside its comments, and let the tool prove itself on your pages instead of Google’s examples.
Leave a comment