Comparative Analysis

Comparative Analysis: DeepDelve versus LLM Wiki and Deep Research Agent

This document is an in depth comparative audit of DeepDelve against two other reference implementations: nashsu/llm_wiki, which follows a persistent knowledge base and wiki paradigm, and CYC2002tommy/Deep-Research-Agent, an academic pipeline sometimes called Deep Science Writer. It walks through the core conceptual differences, points out functional gaps, and pulls out concrete, high impact features that could help move DeepDelve from a search harness toward something closer to an industrial grade research assistant.

Feature matrix

Feature / Dimension	DeepDelve (Current)	LLM Wiki (nashsu)	Deep Research Agent (CYC2002tommy)
Primary Goal	General purpose local deep web research	Incrementally built local wiki and knowledge base	Academic literature review and manuscript drafting
Output Format	Markdown (final_report.md)	Interlinked Obsidian compatible Markdown pages	APA 7th edition .docx manuscript, Obsidian
Search Engine	DuckDuckGo Search (snippets plus auto fetch top 1)	Keyword and vector hybrid search on the local wiki	Academic databases (OpenAlex, Scopus, Semantic Scholar, Exa)
Knowledge State	Ephemeral, isolated session folders per run	Persistent, a living, incrementally updated wiki structure	Ephemeral, a focused study draft output
Verification Gate	URL presence (fetched) plus deterministic term overlap	Review queue for user managed ingestion	Strict DOI lookup, Q1/Q2 journal check, peer critique
Local Model Fit	Tuned for Mistral Nemo (TUI and CLI modes)	API integrated for Claude Code or a desktop UI	Scoped for Hermes 3 Llama 3.1 8B (OpenClaw skill)

DeepDelve versus llm_wiki

The core paradigm difference. DeepDelve is ephemeral RAG: it processes every query from scratch. When a user runs a query it spins up sub agents, searches the web, downloads files, writes a final report, and saves the whole thing in a timestamped folder. Its knowledge cache is just a simple query to text map. llm_wiki treats the agent as a librarian instead. It builds and maintains a living, persistent knowledge graph, and rather than writing standalone reports, the agent incrementally updates existing Markdown files, creates new interlinked pages, and keeps indices and concept maps up to date.

What DeepDelve could adopt from llm_wiki. The first idea is a persistent wiki structure that replaces session isolation. Instead of archiving each run into its own clean, isolated directory, DeepDelve could support a wiki mode where the workspace is a persistent structure: an Obsidian compatible wiki/ folder, a wiki/concepts/ directory for topic specific pages, a wiki/sources/ directory for Markdown extractions of fetched sources, and a wiki/index.md that acts as a living table of contents the Planner keeps updated.

The second idea is automatic cross linking through wikilinks. When writing reports or concepts, the Planner should cross reference other files already in the workspace. In practice this means giving the Planner's tools a way to read the list of existing page names, and instructing it to format references as [[Page Name]], which Obsidian will then automatically resolve into a visual graph.

The third idea is a living wiki schema, carried through control files. We could introduce schema rules directly in the workspace, purpose.md and schema.md, that the Planner reads at startup to understand the style, naming conventions, and structure of the knowledge base. That would prevent it from producing unstructured or floating files.

DeepDelve versus CYC2002tommy/Deep-Research-Agent

The core paradigm difference. DeepDelve leans on general web scraping: it relies on DuckDuckGo Search, and even the AcademicSearcher uses DDGS, which means academic queries end up pulling general web summaries, news, or blog posts instead of real scholarly metadata. CYC2002tommy was built for academic rigor and anti hallucination instead. It integrates directly with open scientific APIs (OpenAlex, Semantic Scholar, Scopus) to fetch peer reviewed papers, enforces strict DOI validation, and screens journals by rank to keep source quality high.

What DeepDelve could adopt from CYC2002tommy. The first idea is OpenAlex or Semantic Scholar API integration. Instead of forcing AcademicSearcher to fall back on DuckDuckGo, we could add a dedicated academic retrieval tool, academic_search, that queries the OpenAlex API (it's free and needs no API key for the polite pool). It lets you search papers by title, author, or concept, and returns structured JSON with the DOI, journal index, and abstract.

The second idea is journal quality filtering, an impact screen. A lot of search results come from predatory or low quality journals (MDPI, Frontiers, Q4 journals, and similar). The academic_search tool could parse the journal ranking (Q1 through Q4) or citation counts that OpenAlex returns and prioritize top tier journals, which would stop the agent from sourcing low quality papers in the first place.

The third idea is a strict DOI verification gate. Rather than just checking that a URL was fetched, we'd verify the citation's actual Digital Object Identifier. A lightweight verify_doi tool could query api.crossref.org to confirm the DOI is valid and actually matches the paper metadata cited in the report.

The fourth idea is a peer review critique phase, closer to Nature or Science level rigor. In DeepDelve's Planner workflow, pass 2 is already a "Global Critic" step that checks whether claims exist in the findings. We could elevate that into an academic peer review simulation: before compiling final_report.md, spin up a temporary sub agent configured as a Peer Reviewer to critique findings.md. It would look for things like sample size limitations (for example, "Source A claims X but only tested 12 subjects"), overgeneralized results, conflicts of interest such as industry funded papers, and outdated findings from papers published more than ten years ago.

A concrete implementation roadmap

We could introduce these features without breaking DeepDelve's core architecture, by adding specialized tools and a few new options in config.yaml.

Phase A, the academic database toolkit (Academic Searcher upgrades). A new academic_query_openalex(query: str, limit: int) tool would query api.openalex.org for papers matching the given terms and return something like:

{
  "title": "...",
  "doi": "https://doi.org/... ",
  "authors": ["Author A", "Author B"],
  "journal": "Nature Communications",
  "quartile": "Q1",
  "abstract": "..."
}

A new verify_doi(doi: str) tool would perform a head request or a lightweight CrossRef lookup to confirm the DOI is valid.

Phase B, the Obsidian wiki module (Planner upgrades). A new list_wiki_links() tool would return the list of all concept files already in the workspace, for example ["Elasticsearch", "pgvector"]. PLANNER_INSTRUCTIONS would be updated so that whenever a concept from list_wiki_links comes up in discussion, it must be wrapped in [[concept_name]] formatting. And a new settings.workspace.mode: "wiki" config option (defaulting to "isolated") would let a user opt into wiki mode, at which point session isolation is bypassed and everything gets saved into one consolidated, interlinked workspace root.