PACR vs Elicit: Which Is Better for Literature Reviews?

Oct 7, 2026

It was a Tuesday night in March, around eleven, and a postdoc in our group was sitting in the corner of the shared office with three browser windows open and a spreadsheet she'd clearly been fighting with for hours. Grant deadline Friday. She had 340 records, maybe 60 she'd actually read, and a column labeled "notes??" that was half empty. She looked up and said, "I've screened all of these. I just can't remember which ones I screened in which tool."

That sentence has stayed with me for years, because it names the actual problem. Not finding papers. Not summarizing them. Losing track of your own thinking as it moves between tools.

I get asked about Elicit a lot. Usually the question is framed as "should I switch?" or "which one is better?" and my honest answer is that it depends on what part of the review you're struggling with, and most people haven't diagnosed that yet. So let me try to be useful rather than tribal.

What Elicit is genuinely good at

Elicit built its reputation on a specific and real capability: you ask a research question in plain language, and it returns papers with extracted information laid out in a table. Columns for intervention, population, outcome, sample size, that kind of thing. For a first pass on a question you don't know much about, it's a nice way to see a field's shape quickly.

I've watched students use it well. A second-year in epidemiology told me last spring that she'd used it to figure out, in about twenty minutes, whether a question she'd been handed by her supervisor had already been answered to death. It had. She saved herself a month. That is a genuinely good use of the tool, and I'd recommend it for exactly that.

The tabular extraction idea is also sound pedagogy, frankly. It forces you to think in terms of structured comparison rather than vague impressions, which is how a review should work anyway.

So when people ask me to trash it, I won't. If your problem is "I need to orient myself in an unfamiliar literature fast," it's a reasonable choice.

Where the trouble starts

The trouble isn't the search. The trouble is everything after.

Think about what a real literature review actually involves. You search. You screen titles and abstracts. You pull full texts. You read, and while reading you form opinions, spot contradictions, notice a methods problem in one paper that makes you reconsider three others. You take notes. You build an argument. You write. Then a co-author reads a draft and asks, "where did this claim about dosing come from?" and you go hunting through six weeks of accumulated mess.

The vast majority of discovery tools stop at step three. They hand you a result set, maybe an export, and then you're on your own. Your search lives in one place, your PDFs in another, your notes in a third, your draft in Word, your references in whatever manager you set up in 2019 and have resented ever since.

Every one of those handoffs loses something. Usually it loses the why. You remember that you excluded 40 papers; you don't remember why you excluded any particular one. That's the gap the postdoc in our office fell into.

How PACR approaches this differently

PACR is an AI-native research workspace, and the design bet behind it is that the steps shouldn't be separate products at all. Finding literature, reading it, summarizing, writing, collaborating and getting to a submitted manuscript all live in one connected workflow, and each step keeps the context from the one before it.

That sounds abstract until you see what it means in practice. When you search and explore literature in PACR, the papers you keep don't become a dead list. They stay attached to the question you asked, the screening decisions you made, and the notes you wrote while reading. When you start drafting, the material you've gathered is already there, with its provenance intact. You don't re-explain your project to a new tool at every stage.

I think of it as the difference between a filing cabinet and a conversation. Most tools give you a better filing cabinet. The useful thing is a system that remembers what you said last week.

A concrete example

Say you're a clinician looking at whether a drug class has consistent cardiovascular benefit across trial populations. You might start with something like a PubMed search for GLP-1 receptor agonist cardiovascular outcomes trials to anchor yourself in the indexed record, then bring that question into PACR to broaden the net and start structuring what you find.

You screen. For each exclusion you type a half-sentence reason, because future-you is an ungrateful reader of past-you's notes. You read six full texts and realize two of them share an open-label design that matters for your argument. You write that thought down where you're reading it, not in a separate file.

Three weeks later you're drafting the discussion and you want that open-label point. It's attached to the papers, in the same workspace, with the citations already linked. No archaeology.

That's the whole pitch, really. It's not glamorous. It's just that the twenty small reconstructions a review demands stop happening.

Quick searches versus systematic reviews

This is the distinction most comparison posts skip, and it's the one that actually determines your answer.

If you're doing a quick scoping search

You want speed and breadth. You want to know what exists, who the main groups are, whether anyone has done your study already. You're not going to report your methods. Nobody will audit you.

Honestly, several tools serve this fine, Elicit among them. Use whatever gets you oriented. The cost of a bad decision here is low because you'll search again anyway.

Where PACR earns its place even on quick work is when the quick search turns out to be the start of something. Which it often does. A "just checking" search in January becomes a paper in September, and if you did that first search inside your working environment, you still have it.

If you're doing a systematic review

Now everything changes. A systematic review is a methods exercise before it's a reading exercise. You need a protocol, ideally registered. You need reproducible search strings per database. You need two screeners, documented disagreements, a resolution process. You need a flow diagram that adds up, following the PRISMA reporting guidance, and you need to be able to defend every number in it eighteen months later when a reviewer asks.

Here's where I'll disagree with some common advice: I don't think AI-assisted search is the right place to build a systematic search. Your search strategy should be transparent, database-native, and replicable by a stranger. That means Boolean strings in PubMed, Embase, whatever your field uses, ideally with a librarian. Any tool that obscures how results were retrieved is a liability at that stage, no matter how good its results are.

What AI tools are good for in systematic work is the long middle: screening at volume, extracting data consistently, surfacing the paper you almost missed. The EQUATOR Network has useful material on reporting standards that'll tell you what you need to document; let the tool help with the labor, not the design.

PACR fits that middle well because screening decisions, extractions and notes all stay connected to the records and to each other. When you build your flow diagram, the counts come from work you actually did, not from a spreadsheet you reconciled by hand at midnight.

A side-by-side, written honestly

What you're trying to do

Elicit

PACR

Orient quickly in an unfamiliar field

Strong. Natural-language questions and table views are well suited to this.

Strong, and the search stays available as the project grows.

Extract structured fields across papers

A core strength and clearly built for it.

Supported as part of the reading and summarizing workflow.

Keep screening reasoning attached to records

Varies with how you work around it.

Built in; decisions and notes stay with the paper.

Move from reading into drafting

Typically means exporting to another tool.

Same workspace, context carried over.

Co-authors working on the same review

Usually coordinated outside the tool.

Collaboration is part of the connected workflow.

Reproducible database search strategies

Pair with native database searching.

Pair with native database searching.

Notice I've said the same thing in that last row for both. No AI tool should be your sole search method for a review you intend to call systematic. Anyone telling you otherwise is selling something.

Three mistakes I watch people make, regardless of tool

Screening without a written rule. I've seen a student screen 200 abstracts and then change her inclusion criteria at paper 180 because the literature "looked different than expected." She had to start over. Write the criteria down before you start, even informally. Change them if you must, but change them deliberately and note when.

Trusting an extracted summary without opening the paper. Extraction is genuinely helpful and genuinely fallible. A summary can report an effect size correctly and completely miss that it came from a subgroup analysis. For any paper carrying weight in your argument, open the methods. Every time. I don't care how good the tool is.

Treating the review as a phase that ends. It doesn't. You'll be adding papers while you write and while you revise. Which is another reason I'm skeptical of workflows that assume a clean export at the end of "the literature stage." There is no end of the literature stage.

What I'd actually tell a student asking me today

If you want to look around a field this afternoon, use whatever's fastest and don't agonize. Elicit will do that job.

If what you're starting is a project — something with co-authors, a timeline, a target journal, revisions ahead of it — put it somewhere that will hold the whole thing. Losing context between tools is a tax you pay quietly, in hours you never account for, and it gets worse the longer the project runs. That's the problem PACR was built to solve: one workspace where search, reading, writing, collaboration and publication connect to each other.

Before you start either way, do two unglamorous things. Register your protocol if it's a systematic review. And check your reporting obligations early rather than at submission; the ICMJE recommendations and COPE guidance cover more than people expect, and if you're reviewing trials, ClinicalTrials.gov will tell you about studies that finished but never published, which is a gap worth noting in your discussion.

That postdoc from the Tuesday night, by the way, made her deadline. She also spent most of the following weekend rebuilding her screening log from memory and email attachments, which is a terrible way to spend a weekend and an entirely avoidable one.

If you're at the beginning of something and the shape of it isn't clear yet, that's the best moment to set up properly. Start a project in PACR and keep your first search, so that in six months it's still there, with your reasons attached.