LitAgent: AI Literature Review Agent

LitAgent is a multi-agent AI system that automates the single most time-consuming part of academic research: the literature review. Given a research topic, five specialized agents work in sequence, planning research questions, retrieving papers from arXiv, parsing and summarizing them, linking evidence back to each question, and synthesizing everything into a structured, publication-ready draft in Markdown.

A thorough literature review means finding the right papers, reading them closely, tracking which findings answer which research question, and writing it all up with proper citations. Work that routinely takes days before a researcher writes a single sentence of original analysis.

Build a fully autonomous pipeline with a real interactive web UI that takes a single research topic and returns a structured draft paper with evidence-linked claims and a references list, while keeping the user's own LLM API key out of any persistent storage.

1. Planner Agent

Takes a raw research topic and expands it into a concrete research strategy: a set of specific, answerable research questions and the search queries needed to investigate them.

2. Retriever Agent

Queries the arXiv API for candidate papers, applying temporal, keyword-relevance, and study-type filters (max papers, start year, category) so the pipeline works from a focused, relevant set.

3. Summarizer Agent

Parses full papers with the GROBID parser and produces structured summaries covering Motivation, Methods, Datasets, Findings, and Limitations while preserving full reference lists, all stored in SQLite for reuse.

4. Linker Agent

Connects each research question back to specific papers, rating relevance as high, medium, or low and extracting the exact supporting evidence. This is the step that keeps the final draft traceable to sources.

5. Synthesizer Agent

Assembles everything into a structured Markdown draft: Introduction, Related Work and Gaps, Literature Review (prose plus a summary table), Problem Statement and Research Questions answered with evidence, and a References list limited to works actually cited.

The five agents run as a single asyncio-driven pipeline, each stage's output feeding the next, visible to the user in real time rather than as an opaque background job.

The flow moves through five handoffs:

• Planner to Retriever: Research questions become targeted arXiv search queries
• Retriever to Summarizer: Retrieved PDFs are parsed with GROBID and reduced to structured summaries
• Summarizer to Linker: Stored summaries are matched back against each open research question
• Linker to Synthesizer: Evidence-linked findings are assembled into the final Markdown draft

The output is not a wall of text. It is a structured draft the user can read directly in the browser, with a sidebar to inspect exactly what each agent produced along the way.

Every generated draft follows the same structure:

• Introduction: Frames the topic and why it matters
• Related Work and Gaps: Names the specific gaps in existing literature
• Literature Review: Synthesizes the retrieved papers into prose plus a summary table
• Problem Statement: Directly answers each research question with cited evidence

A synthesized draft is only trustworthy if its claims can be traced back to real sources. The Research Artifacts sidebar exposes every intermediate output the agents produced, so nothing is a black box.

• Research Questions: The question set generated by the Planner Agent from the original topic
• Retrieved Papers: Every paper the Retriever Agent pulled from arXiv, with authors and a direct PDF link
• Extracted Summaries: The Summarizer Agent's structured breakdown of each paper
• Linked Evidence: The Linker Agent's question-to-paper matches with relevance rating and evidence text

Handling a User-Supplied API Key Without Storing It

The pipeline runs on the user's own Gemini API key, entered at runtime through a Bring Your Own Key (BYOK) modal rather than an environment variable. That meant the key could never touch disk or a persistent store. It had to live only in-session and be threaded through every agent call for that run, then discarded. This zero-persistence constraint shaped the LLM wrapper from the start, rather than being bolted on afterward.

A Five-Stage Pipeline That Cannot Deadlock or Silently Hang

With five agents running a 10 to 15 minute end-to-end job including network calls to arXiv, PDF parsing through a separate GROBID server, and multiple LLM calls, any single blocking step could stall the whole run. The fix was a high-concurrency asyncio architecture where I/O-bound steps run without blocking the Streamlit UI thread, with each agent's status surfaced live so a long-running step reads as progress, not a frozen page.

• Traceability is a feature, not an afterthought. Exposing the Research Artifacts panel turned out to matter as much as the final draft itself. A synthesized paragraph is only useful if a reader can check where each claim came from
• Long-running agents need honest status, not a spinner. Naming each agent and its current action turned a long wait into a legible, trustworthy process
• Security constraints should shape architecture early. Committing to zero-persistence API key handling from the start meant the LLM wrapper was designed around passing credentials through the call chain
• Parsing real PDFs is harder than parsing clean text. Routing every paper through GROBID rather than naive text extraction was what made structured, section-aware summaries possible

• Agent Orchestration: Five-stage sequential pipeline with per-agent status reporting
• Document Parsing: GROBID-based structured extraction from scientific PDFs
• Data Modeling: Pydantic schemas and SQLite persistence for summaries and references
• Concurrency: High-concurrency asyncio design avoiding blocking I/O and deadlocks
• Web UI: Interactive Streamlit dashboard with live progress and artifact inspection
• Secure Key Handling: Runtime BYOK modal with zero-persistence API key management
• LLM: Google Gemini via LangChain