ai for researchers, and the sources you already read
ai for researchers has solved the wrong half of the problem, and as of september 2026 the gap is getting wider rather than narrower.
every tool in this category is built to find literature you have not read. elicit, consensus, scite and semantic scholar all search outward, into the published corpus. that is what ai for academics has meant so far. none of them can tell you what you read on tuesday, which figure convinced you, or why you abandoned a line of enquiry in march.
that second archive is where most of a research project actually lives, and almost nobody has one.
the two halves of research, and which one has tools
research splits cleanly into finding and remembering. only one half is well served.
| the task | tools that exist | how well covered |
|---|---|---|
| find relevant literature | elicit, consensus, semantic scholar, scite | very well |
| screen and summarise candidates | claude, chatgpt, gemini, purpose built screeners | well |
| store what you chose to keep | zotero, mendeley, obsidian, notion | well, if you file it |
| recall what you actually read | almost nothing | not at all |
| recall why you made a decision | almost nothing | not at all |
rows 1 to 3 are a crowded market. rows 4 and 5 are empty, and they are the ones that make a literature review painful 8 months in, when you know you read something relevant and cannot reconstruct where.
the memory features shipped by openai, anthropic and google in 2026 do not fill rows 4 and 5 either. chatgpt, claude and gemini all remember what you told them in chat, which for a researcher is a small and unrepresentative slice of the reading. we compare what each actually stores in ai memory is everywhere in 2026.
the filing tax nobody pays
reference management ai has the same blind spot as reference management without ai: it holds what you remembered to save, which is a small fraction of what you read.
think about an ordinary research week. you open 40 or 50 pdfs, skim most, read 5 properly, and save maybe 3 to zotero. you read a dozen abstracts in a search results page, a preprint someone linked in slack, a methods section you needed for 10 minutes, and a blog post that reframed the problem better than any paper did.
the saved 3 are in your reference manager. the other 95% of your reading left no trace at all.
that gap is not laziness. it is a cost per item problem. filing something takes 20 to 30 seconds of deliberate effort, and you have to decide, at the moment of reading, that this will matter later. you are worst placed to make that judgement precisely when you are making it. the same failure mode runs through every tool you have to feed, which we take apart in the best second brain apps in 2026.
what the usage data shows
people spend more of their ai time searching than doing anything else, and almost none of it reaches their own material.
per the anthropic economic index for may 2026, the single most common work task in sampled claude conversations is searching electronic sources for information at 4.95%, with reference searching second at 3.74%. that is 8.69% of conversations spent looking something up.
| request topic | share of conversations |
|---|---|
| content creation and copywriting | 22.72% |
| education and learning | 13.23% |
| software development | 11.51% |
| research and intelligence | 10.94% |
| document processing and extraction | 4.32% |
| knowledge retrieval and enterprise search | 3.61% |
| personal ai assistant | 2.86% |
| conversation and meeting intelligence | 0.26% |
research and intelligence is 10.94% of conversations, which is substantial. but knowledge retrieval and enterprise search, the category that means searching your own material, is 3.61%, and anything about a meeting or seminar is 0.26%. coursework accounts for 16.45% of classified conversations and work for 43.36%, with 51.38% of all usage being augmentation rather than automation.
read together: researchers are having long thinking sessions against the public corpus, and almost never against their own.
what an ai research assistant cannot do
a model reasons over what you give it, so the limit is your recording, not its intelligence.
five things stay invisible unless something captured them:
- the paper you skimmed and closed. never saved, so it does not exist to any tool you own.
- the figure that changed your mind. it was an image in a pdf, and your notes say "see fig 3" without saying which paper.
- the seminar comment. spoken, not written. no transcript, no record.
- the failed approach. you tried it for 3 days in april and the only trace is a deleted branch.
- the reviewer's objection. in an email thread you have not opened since.
no ai literature review tool touches any of this, because none of it is in the literature. it is in your week. this is the ceiling that no amount of retrieval tuning fixes, and it is the argument in what is context engineering.
the reading you forget, measured
forgetting what you read is well documented, and the mechanism is worse than simple decay.
people who know information is stored somewhere retrievable remember the location rather than the content, an effect documented by betsy sparrow and colleagues in science in 2011 and usually called the google effect. researchers do this constantly and professionally: you remember that a result exists and which rough area it came from, and not the number.
there is a second problem stacked on top. rereading produces a strong feeling of knowing and a weak memory trace, so the material you skimmed most fluently is the material you are most confident about and least able to recall. the full mechanism, and what actually works instead, is in why you forget what you read.
the practical consequence for research is specific. your confidence about what the literature says is calibrated to how recently you read it, not to how well you retained it.
a workflow that closes the gap
a research workflow ai setup that actually helps needs four changes, in the order that pays off fastest.
- keep the outward tools. elicit and consensus are genuinely better than a general assistant at finding papers. do not replace them.
- stop filing, start capturing. an archive of what was on screen catches the 95% you would never have saved, at zero cost per item.
- make the archive searchable, not just recorded. video with no ocr index is a hard drive full of things you cannot find, which is the point of what is ocr.
- connect it to the model you already use. an assistant that can query your own reading answers "what was that paper about hippocampal replay i read in june" instead of searching all of pubmed for it.
step 4 is newly practical. connecting a personal archive to claude or another assistant over a local connector is a config edit rather than a project, covered in what is an mcp server.
the confidentiality question
unpublished work raises a real question, and the honest answer is about architecture rather than promises.
if you handle embargoed data, pre publication results or anything under an nda, the thing to check is where the archive lives and what leaves it. a tool that uploads your corpus to a vendor is a different risk from one that keeps the archive local and sends only small retrieved slices to a model when you ask a question.
be suspicious of any tool claiming nothing ever leaves your machine. almost every real app makes network calls for sign in, updates or crash reporting, and an honest vendor scopes the claim to the archive. the full version of that argument is in private ai on your mac.
where remynd sits
remynd records the focused window on a mac, runs ocr locally through apple's vision framework so what you read becomes searchable text, and keeps the index on your machine.
the scope, stated exactly: focused window capture rather than every pixel of every display, local ocr and storage, recordings default to 30 days of retention, app and site exclusions, and history that is read only everywhere in the app. call transcription runs on device using an mlx speech model on apple silicon, which covers supervisions and seminars you record.
what it does not do: asking a question sends the retrieved slices to a cloud model, so this is not a claim that nothing ever leaves the machine. it also does not isolate separate projects into separate vaults, which matters if you work across several confidential collaborations on one machine.
if you want the category rather than the research angle, start with screen memory.