How to Write a Literature Review: Find Everything Before You Write Anything

Writing a literature review comes down to three things: find the literature relevant to your question, all of it; read it by grouping and comparing papers until you can see how the field is structured; and then write your own judgment of the field, which is the review's argument. The first two set the floor of a review, and the third sets its ceiling. This guide goes through them in that order, with a real example at each step.

There are plenty of guides on writing a literature review, and they mostly agree on the steps: pick a question, search the databases, evaluate sources, find themes, outline, write, revise. After reading a stack of them, I think they share two problems. The search step almost always gets a single sentence, "search the relevant databases," even though a review can only discuss what it found, and a search that stops at the first page of Google Scholar produces a review of the first page. And the writing part often shrinks to "synthesize, don't summarize," with little on how to synthesize, where a review's argument comes from, or what to do when papers contradict each other.

This guide tries to fill in both ends. Search is where I started with Parallax: general-purpose agents only get the top-k results from search APIs and can't tell you how many papers exist on a topic, so I built something that scans the whole arXiv corpus instead. But doing that made it clear that finding everything only sets the floor of a review. The ceiling is still set by the writing. So there are three parts below, finding, reading and writing, and writing gets the most space. I have in mind people who work with preprints, whether in physics, mathematics, computer science, statistics, quantitative biology or economics.

Types of literature review: know which one you're writing

A literature review answers a question by comparing existing work, not by listing it. Its form depends on where it appears. A related work section places your paper among existing research in a few paragraphs. A thesis chapter is a structured map of a field that ends in your own research question. A standalone survey is larger still, and very common in the computer science and physics sections of arXiv. Medicine and the social sciences add systematic reviews, which register their search and screening protocol in advance and report counts at every stage, and scoping reviews, which map what exists without judging quality. The method below works for all of them; what changes is the scale, and how much of the process you write down formally.

How to search for literature: make sure you've found it all

Write the question and the boundary as sentences someone could check

Before searching, write down the question your review answers, and what's in and what's out. The test is whether someone else, holding those sentences, would sort a given paper the same way you would. "Papers about memory in LLM agents" is too vague. "Include papers that propose, evaluate or analyze how an LLM-based agent stores and retrieves information across steps or sessions; exclude KV-cache compression work with no agent setting" gives you something to decide with. Fix the time window and sources at the same time, and if you only cover arXiv since 2020, say so in the review. You'll use these sentences again for screening, for checking gaps and for the scope section.

Estimate the size, then search from several angles

Ten papers and ten thousand papers call for completely different plans, so it's worth estimating how big the area is first. Google Scholar's "about 2,000,000 results" is mostly noise, and an AI assistant returns about ten papers whatever the real number is. A rough method is to search a few phrasings, note how many results each returns, and skim a few from each to see how many are relevant. If one phrasing gives 300 hits and half look on-topic, and another gives 5,000 and one in twenty does, you know where the bulk of the field is and which terms are too broad.

Then comes a more awkward fact: fields don't agree on vocabulary. In computer science, looped transformers, recurrent-depth models and universal transformers overlap a lot. In mathematics the same object can have different names and notation in different subfields. In physics, work on one phenomenon is often spread across hep-th, gr-qc and astro-ph. Search one name and you find one community. So rather than chasing one perfect query, run several narrower ones: keyword searches for established names, acronyms and variants; semantic searches that describe the idea in plain words, to catch papers that use different terms; and a pass through the references of a few central papers, to recover older work written in older vocabulary. Merge, deduplicate, and note which route found each paper. If a whole cluster of relevant papers came from only one route, the others probably share a blind spot.

It's fine for the merged set to be far larger than what you'll keep. In one search on memory in LLM agents, 6 keyword and 5 semantic routes merged into over thirty thousand candidates, most of which were screened out later. If screening is cheap, casting wide costs little, and missing an entire community costs a lot.

Screen, then check for gaps

Screening means going through the candidates with the sentences from the first step, and title and abstract are usually enough on a first pass. Record a short reason when you exclude something, even just "out of scope" or "no new result," and keep the papers you can't decide on in their own pile instead of forcing a yes or no. Then do the thing many people skip: list the papers you already know belong in the review and check that each one made it through. If one didn't, work out whether the search missed it or the screening dropped it, fix that route, and look at what else the fix brings in.

Screening thousands of papers by hand takes days, and this is where an AI model genuinely helps, as long as it applies your criteria and every decision can be audited. Parallax uses Jev, which gives each paper a calibrated probability against each criterion (I wrote about how the search and screening pipeline is built separately). Papers at 0.5 or above are included, and every probability is stored, so you can sort by it and read the borderline ones. Whatever tool you use, read twenty included and twenty excluded papers, and if they look wrong, rewrite the criteria first.

Reading the literature: from a list to a map

Group first, then read

With a final set in hand, resist reading from the top and group the papers first. Grouping turns a list into a map, and the map is usually the skeleton of the review. Computer science and applied mathematics tend to group by method or approach, physics by the system or phenomenon studied, and you can also group by type of contribution or by time. A paper can belong to two groups. Groups that get too large need splitting: in one review of multimodal work, "benchmarks and datasets" ended up with over a hundred papers and was split again into 11 subcategories, because a group of a hundred papers isn't a theme yet, it's a pile. And if a large "other" group is left over, don't ignore it. It usually means the grouping dimension isn't right yet.

Read for comparisons, not summaries

You won't read every paper in full, and you shouldn't try. The central papers in each group, the ones others build on and the strongest recent ones, are worth reading completely. For the rest, read enough to say what they add. The papers that deserve the most time are the ones that disagree with each other, because disagreements are often the most valuable part of a review.

What you note while reading should be comparisons. "A and B use the same method, but A evaluates in a different setting and reaches the opposite conclusion" is review material. "A proposes X. B proposes Y." is a table of contents. A literature matrix helps: one row for each paper you'll actually discuss, one column for each thing you want to compare. It doesn't need to cover everything, but it forces the comparisons to exist before you start writing, and later many paragraphs grow almost directly out of it.

Writing the literature review: from material to argument

After the first two parts you have a defensible set of papers, a set of groups and a comparison table. Many people now write one section per group, introducing each paper in turn. Nothing in that is wrong, but readers finish it and ask: so what? What separates a good review from a well-organized bibliography is an argument.

I'll use a real review as the running example. It's Looped and Recurrent-Depth Transformers, produced in Parallax, about models that reuse the same weights repeatedly along the depth axis, built from a candidate pool of 358 papers with 102 read in full. The full text is public in the Parallax Research section, alongside other surveys and monthly progress reports, so you can read it alongside this guide. It isn't necessarily the best possible review, but several of its writing choices are worth taking apart.

Find your argument

A review's argument isn't "this paper surveys field X." It's the handful of judgments you've formed about the field after working through the material. The looped transformers review states four claims in its introduction: the design space is small and discrete, with almost every architecture amounting to one choice on each of four axes; training stability, not expressive power, is what actually constrains these models; the evidence for looping mostly comes from parameter-matched rather than compute-matched comparisons; and adaptive depth at inference is the most active and least validated direction, with gains that are real but fragile. The rest of the review is evidence for those four claims.

Where does an argument come from? Usually from your comparison table. A column that barely varies across papers is a consensus. A column where papers give opposite results is a disagreement. A column that's mostly empty may be a gap. The architecture comparison table in the looped transformers review has a column for evidence scale, recording the largest setting each paper actually reports, and the authors note underneath that it's often much smaller than the setting the claims are stated for. A column like that is itself a judgment.

You don't need the argument at the start. A practical approach is to finish reading and filling the table, then try to answer in three to five sentences what state the field is actually in. If you can't, you need to read or compare more.

Literature review structure: let it carry the argument

Once you have an argument, the structure is easier. Organizing by theme, one group per section, is the most common choice; organizing by method suits fields with distinct technical lines; a chronological structure works when the history explains the present. But more important than which one you pick is making the structure itself express the argument.

The looped transformers review first gives a single formal definition, then proposes a four-axis taxonomy, then goes chapter by chapter through architecture, training, inference and theory. Its chapter titles are judgments in their own right. The training chapter is called "Training: stability is the binding constraint." A reader who only looks at the table of contents already knows where the author stands, which is far more informative than "3. Training methods."

Within a section the same logic applies: open with what the group of papers has in common, compare within the group, and end with what's unresolved. That order gives every section a point to land on, instead of stopping abruptly after the last paper is described.

Writing the introduction: state your scope and the limits of your evidence

The introduction should say what the question is, why it matters now, and what the review argues. A part that often gets left out is the scope: the time window, the sources, what's excluded and how you searched. Stating these gives readers a reason to trust your coverage, and tells them within what limits your conclusions hold.

The looped transformers review has a whole section called "Scope and evidence boundary." It says it's a narrative review of one architectural family rather than a systematic review, that the candidate pool was 358 papers from six search routes, with 102 read in full and the rest screened at title and abstract level, and it lists three caveats readers should keep in mind, including that three foundational papers weren't in the library and had to be cited from outside, and that the field is dominated by preprints, so much of what's cited hasn't been peer reviewed.

This isn't hedging. Readers who know where the boundary is find it easier to trust what's inside it.

Body paragraphs: synthesis versus summary, with an example

At the paragraph level, the most common problem is one paragraph per paper, each opening with an author's name. Here's an illustrative contrast, supposing the topic is whether a class of architectures beats standard models:

Listing: [3] proposes a recurrent architecture that outperforms baselines on several benchmarks. [5] builds on this by adding adaptive depth, improving results further. [8] extends a similar structure to vision. [6] revisits these architectures under compute-matched conditions.

Synthesizing: Gains for this architecture are reported across several works [3][5][8], but almost all of these comparisons hold parameter count equal. When inference compute is held equal instead, the picture is no longer consistent: the advantage largely disappears on language tasks and persists on vision tasks [6]. So the claim that recurrent architectures are better needs a prior question answered: better than what, matched on what?

The second paragraph takes more effort to read, but it gives the reader a judgment, along with its basis and its limits. A useful order to remember: state the point, cite the papers that support it, then say where they differ or what they leave open.

When papers disagree, find out why before concluding

The most valuable part of a review is often how it handles disagreement. When two sets of papers reach opposite conclusions, don't just write "this remains debated." Look for the reason they differ: a different evaluation setting, a different data scale, a different baseline, or different definitions of the same term.

The looped transformers review faced exactly this. On whether looped models beat standard ones, the literature's conclusions were all over the place. Instead of picking a side, it pointed out that these comparisons actually hold five different quantities equal: parameters, training compute, inference compute, decoding cost and effective depth. Matched on parameters, looping wins clearly. Matched on training compute, the results are mixed. Matched on effective depth, looping wins in a way that's close to tautological. It put the five cases in one table and gave readers a way to read such papers: first check what was held equal. Handled this way, a pile of seemingly contradictory results became one conclusion with real explanatory power.

The same applies in physics. The fast radio burst search mentioned earlier turned up two kinds of evidence that look contradictory. One comes from host galaxy statistics: Bochenek and colleagues compared the hosts of localized fast radio bursts and found them consistent with magnetars born in core-collapse supernovae (arXiv:2009.13030). The other comes from a single source: Kirsten and colleagues localized the repeating burst FRB 20200120E to a globular cluster in M81 (arXiv:2105.11445). Globular clusters are old stellar populations, which is hard to square with a young magnetar fresh from a supernova, so the authors favor a magnetar formed by accretion-induced collapse of a white dwarf or by a compact binary merger. Margalit and colleagues had proposed those channels earlier, starting from a burst whose host galaxy was no longer forming stars (arXiv:1907.00016).

A review that just says "the origin remains debated" gives readers nothing. A more useful version points out that the two kinds of evidence answer different questions. Host statistics describe where typical bursts come from; the one source in a globular cluster shows that at least one other formation channel exists. Both can be true at once, and how much each channel contributes becomes a concrete question for the open problems section.

Back up gaps, and let open problems grow out of the evidence

"No work has studied X" is the easiest sentence in a review to get wrong and the first thing an expert reader checks. Before writing it, search for X directly under each of its names and go back through the pile of papers you couldn't decide on. If your search had limits, put them in the sentence, as in "within the literature we searched."

The same goes for open problems. They're most convincing when they follow from the evidence already presented rather than being thought up at the end. The first open problem in the looped transformers review is a compute-matched benchmark, because the complaint that recurs throughout the review is that papers compare under incompatible matches. What's missing isn't more comparisons but a shared protocol for them. By the time readers get there it feels inevitable, because the evidence has already been laid out.

Writing the discussion and conclusion

The discussion should step back from individual groups and look across them: which problems recur in several directions, which methods have matured in one area but haven't been tried in another. Before its open problems, the looped transformers review has a chapter called "What the evidence actually supports," which first explains why numbers are hard to compare across papers and ends with a section on what the authors take to be established and what they don't. Its conclusion doesn't simply repeat the four opening claims either. It says three of them "seem to us well supported" and gives the grounds for each. That's what a conclusion should do: return to the opening question and tell readers what they can now believe, what they can't yet, and how confident to be.

Writing a related work section

The related work section of a paper is a short review with a narrower job: showing that your work is needed. The same method, compressed, is enough. Write one paragraph per group, synthesize what that line of work has achieved, and end with a sentence on how your paper differs. The usual faults are turning it into a list of citations, or ending every paragraph with "unlike our work" without saying what exactly is different.

If you used AI, say where

Many journals and universities now ask authors to disclose which AI tools they used and at what stage, usually in the methods section or the acknowledgments. The general consensus is that AI can't be an author, and responsibility for the content stays with the people who wrote it.

For a review, the easiest part to disclose is search and screening: which search terms, how many candidates, what the screening criteria were, what threshold the AI judgments used and how many papers you checked by hand. That information belongs in the scope section anyway, so stating the AI's role costs little extra. The real risk is letting AI make judgments or supply citations for you. The judgments are yours to stand behind, and every citation needs checking against the paper. In Parallax, every screening criterion and every paper's probability is stored, so you can write this part straight from the record.

Check once more before you submit

On the last pass, a few things deserve attention. Does every claim point to a specific paper, and does that paper actually say it? Are the papers you knew should be there actually there? Have the last few months been covered? In a fast-moving field, a review that stops six months ago has already missed a lot. Is every gap claim backed by a direct search? Are preprints and their published versions cited without duplicates? And if AI tools were involved in writing, can each AI-assisted claim be traced back to its source?

Doing this with an agent

None of this needs a particular tool, but finding and grouping become impractical by hand once the scale grows, and that's what I built Parallax for. In the app, one agent can run them in a single conversation. It probes the corpus to estimate size and choose search terms, builds several keyword and semantic routes over the full arXiv corpus and merges them with set operations, writes include and exclude criteria from your request, has Jev screen every candidate, and then proposes categories and sorts the papers into them. Afterwards you can discuss the set with the agent, compare papers, pull evidence from them, and have it write the review report. The looped transformers review above was produced this way.

The whole search is kept as a node graph. This is the agent memory search, with 11 keyword and semantic routes merged into 36,564 candidates and screened by Jev down to 5,170.

The same process works outside computer science. I tried the free search on a physics question: what progenitor models have been proposed for fast radio bursts, and what observations support or rule them out? It ran five routes, with the keyword routes covering different communities' vocabulary, from magnetars to neutron star mergers to model names like "blitzar," merged them into 479 candidates, kept 265 after screening and grouped them into six topics.

Notice the "Other" group: 89 papers, about a third of the set, didn't fit any of the six topics. That's the situation described earlier, and before writing you'd read a sample of it and adjust the grouping dimension.

It's worth being clear about what it can't do. The corpus is arXiv only and built from arXiv updates since 2020, so older foundational work is only partly covered and journal-only papers aren't there. Those need to come from your own pass through the references, and the agent doesn't follow citation links automatically yet. More importantly, the agent's draft is a starting point. Finding the argument and working out why papers disagree are still judgments you have to make.

If you want to try it on your own question, the free literature search needs no account. It's a quick scan of at most 5 routes and 1,000 screened candidates rather than a full review, but it's enough to see how big your topic is and how it breaks down.

Frequently asked questions

How do I start a literature review?

Not with the introduction. Start by writing your question and your inclusion criteria as a few checkable sentences, then run a handful of quick searches to see how large the field is. If there are already a couple of recent surveys on the topic, read them early: their reference lists are the fastest way into the literature, and they show you which questions are already well covered. The introduction is easier to write last, once you know what your argument is.

How many papers should a literature review cite?

There's no fixed number. A related work section might cite a few dozen, a survey several hundred. The better question is whether you've covered the field within the scope you stated. Report the size of your candidate set and your final set, and readers can judge for themselves.

Can ChatGPT or another AI assistant write it for me?

It's fine for brainstorming search terms, outlining and editing, but be careful using it as your search or your source. General assistants return a handful of results, may cite papers that don't exist, and can't tell you what they missed, so verify every citation against the paper itself.

Should I include preprints?

In physics, mathematics and computer science, yes. Much new work appears on arXiv first, sometimes years before formal publication. Mark which ones are preprints, and cite the published version when one exists.

How long does a literature review take?

A thesis chapter or a survey usually takes weeks to months. Searching and screening used to take a big share of that; with tools that scan the full corpus and screen automatically, they can fit into an afternoon, leaving the time for reading and writing.

A closing thought

When I started using AI for literature search, what bothered me wasn't that it was wrong. It was that I couldn't tell how much it had missed. The sheer number of awesome paper lists on GitHub shows how many people want the same thing: a complete, organized list of the work in an area. But building Parallax has made it increasingly clear to me that the list is only the floor of a review. Machines can now help make the list complete. Seeing an argument in it, and explaining why results contradict each other, is still where the person writing the review should spend their time.

Parallax is live at parallax.ink. If you're about to start a review, try the free search on your own question first, see how big the field really is, and spend the time you save on the writing.