Literature review is one of those workflows that sounds simple until you actually do it. Search for papers, filter noise, read the promising ones, keep notes, rank what matters, avoid duplicates, and somehow maintain a coherent picture as new work keeps appearing.
AutoScholar is an interesting answer to that problem. Instead of treating research as a one-shot search task, it frames literature review as a long-running autonomous loop. The goal is not just to find papers, but to build a living research database that improves over time.
This post is a quick walkthrough of the architecture behind the project and why the design works.
The Core Idea
At its core, AutoScholar asks a simple question:
What if an agent could automatically follow the latest research literature on a problem you care about, even while you’re asleep?
AutoScholar continuously searches for new papers, reads promising candidates, filters them against a specific research question, and records the results in a ranked research database. Over time, it builds a living map of the literature, with accepted papers, detailed summaries, and explicit rejections for work that does not fit the scope.
The result is an always-on literature review workflow that keeps improving as the agent evaluates more papers.
The Architecture in One View
Its architecture can be understood as four parts:
- Human-defined Problem Statement and Ranking Criteria
- Google Scholar & Web Search Tool
- Persistent Research State
- An Autonomous Control Loop
Here’s how those pieces work together.
1. Human-defined Problem Statement and Ranking Criteria
AutoScholar starts with explicit research boundaries. Before the agent searches for anything, the human defines what problem is in scope and how papers should be judged.
The two key files are:
PROBLEM_STATEMENT.mdRANKING_CRITERIA.md
These files tell the agent what kind of work it is actually looking for, what should be excluded, and what makes one paper more valuable than another. In the AutoScholar setup, that means the agent is not just collecting papers that sound related. It is filtering the literature against a precise question and a concrete ranking logic.
This is one of the most important design choices in the project. The research objective is defined in plain language, not hidden in code. That makes the system easier to steer, easier to audit, and much easier to adapt when the research goal changes.
2. Google Scholar & Web Search Tool
Once the scope is defined, the agent needs a way to discover and verify candidate papers.
The main discovery interface is scholar.py, which provides a small CLI for searching Google Scholar, crawling citations, and exploring authors. That gives the agent a structured way to find papers and expand outward from promising seeds.
But discovery is only part of the job. AutoScholar also relies on web search to verify the reproducibility side of a paper: whether there is public code, a dataset, or a released model. That matters because the project does not just want relevant papers. It wants papers that are useful, inspectable, and ideally reproducible.
Together, Google Scholar and web search form the research tool layer: one surface for finding literature, and another for validating the artifacts around it.
3. Persistent Research State
As the agent evaluates papers, it writes its decisions into a persistent set of research files:
RELEVANT_RESEARCH_LIST.csv— the ranked paper indexRELEVANT_RESEARCH.md— detailed summariesREJECTED_PAPERS.csv— rejected candidates and reasonssources/— saved search outputs for reference
This is the durable memory of the system.
Instead of storing state in an opaque backend, AutoScholar keeps its research memory in plain files. That makes the process legible. A human can inspect the accepted list, read the summaries, review why a paper was rejected, and understand how the survey is evolving over time.
It also enforces discipline. Every evaluated paper has to land somewhere: either in the accepted set or in the rejected set with a reason. That prevents the workflow from becoming fuzzy or losing track of past decisions.
4. An Autonomous Control Loop
The final piece is the loop that keeps the whole system moving.
Each cycle is narrow and repetitive:
- search for candidates
- select one promising paper
- hand the paper to a separate evaluator agent that starts from a fresh context
- have that evaluator read the full paper and test it against the problem statement and ranking criteria
- accept or reject it
- update the research report
- repeat
This separation is useful because the agent that selected a paper is often biased toward justifying that choice. If selection and evaluation happen in the same context, the model can drift into defending the candidate instead of judging it critically. A separate evaluator agent starts clean, with less attachment to the initial pick, which makes it better at rejecting borderline or misleading papers.
That loop is what turns AutoScholar from a one-time search script into an always-on literature review process. It keeps pulling in new candidates, making explicit decisions, and improving the research database over time.
Because each cycle handles one paper at a time, the process stays traceable. And because progress is committed continuously, the survey becomes reproducible as well as autonomous. You can see what the agent added, what it rejected, and how the ranked view of the literature changed from one cycle to the next.
A Strong Pattern for Autonomous Agents
What makes AutoScholar compelling is not just that it automates literature review. It is that it demonstrates a broader architecture pattern for autonomous agents:
- keep tools narrow
- keep policy editable
- keep memory explicit
- keep the loop small
- keep progress versioned
That pattern generalizes well beyond research. You could imagine similar systems for competitive analysis, bug triage, documentation maintenance, or internal knowledge curation.
In that sense, AutoScholar is more than a project about papers. It is a good example of how to structure an agent so that autonomy stays understandable.
Final Thoughts
AutoScholar shows that useful autonomous systems do not need to be huge. Sometimes the best design is a small number of files, a clear contract between human and agent, and a loop that keeps making steady progress.
For literature review, that means turning an exhausting manual workflow into an always-on research process. And from an architecture perspective, it is a clean example of how to build agentic software that is both autonomous and inspectable.
That balance is the part worth paying attention to.