AutoRAG 2.0: A self-evolving librarian agent that reads your files instead of listing them
AutoRAG: Now your agent can find anything in your computer. It gets smarter if you are using it frequently.
At a glance
- What is it?
- AutoRAG 2.0 rebuilds the well-known RAG pipeline optimizer as a Pi-based agent that searches local documents, reads sources directly, and returns curated, numbered answers. It federates existing file stores instead of ingesting them, and it learns from usage over time.
- Who is it for?
- Adopt AutoRAG 2.0 if you manage a personal or team document collection across CLI-owned stores like katok, discrawl, or rclone, and you want search results that read the source and synthesize answers without migrating data into a central index. Do not adopt it if you need a multi-agent orchestration framework, if you require a private model provider by default, or if you cannot allow the agent to execute bash commands on configured directories.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What AutoRAG 2.0 actually is
The repository marker-inc-korea/AutoRAG has changed identity. The original Python AutoRAG, a RAG AutoML tool for finding an optimal pipeline, now lives in the legacy/ directory and is maintained in maintenance mode. The new AutoRAG 2.0 is a TypeScript agent built on the Pi agent loop, configured as a librarian. It is not a coordinator for multiple model roles. You configure one model, and that model handles retrieval, reading source files, judging evidence, and curating a structured answer. The model and provider come from the user's authenticated runtime; the project ships no private provider default. This is a meaningful shift from the original project's focus on pipeline optimization. The README describes the core value as never migrating data to search it, which distinguishes it from tools that require ingestion into a central index.
The librarian loop: retrieve, read, judge, curate
The agent's workflow is visible in the README's example: a user asks about key findings in a Q3 report, and AutoRAG returns numbered knowledge units with page references, not file paths or line numbers. The mechanism is a loop where retrieval tools supply candidate paths, then the agent opens the source material directly through a built-in bash tool. It reads the underlying documents before curating. Answers come back as a structured SearchDocumentsResponse, and results carry their real source, either a file path or a datasource id, in an internal mapping used for feedback and curation. This design means the agent is not a search tool that points you to files; it does the reading and synthesizing. The README states that no raw grep dumps are returned. This is a point of view that trades transparency for convenience, and it only works if the agent's judgment is trustworthy.
Retrieval methods and MinSync's shared chunk lifecycle
AutoRAG supports pluggable retrieval methods: local lexical BM25, semantic vector search, and hybrid, all routed through MinSync over a shared CDC chunk lifecycle. The RetrievalMethodRegistry wires these methods, and the agent invokes retrieval tools, then reads documents via bash, then merges results using a ResultMerger that performs score normalization and deduplication. BM25, vector, and hybrid are enabled by default whenever MinSync is enabled. You can disable local indexing with "minSync": false, or disable only lexical search with "bm25": false. MinSync auto-installs a verified release into <workspace>/.autorag/bin on first use when autoInstall is true. You can set autoInstall to false when managing the binary yourself. The embedder is configured via autorag init --embedder-* flags for remote endpoints, and minSync.maxChunkSize can be adjusted when a local embedder has a smaller context window. The README explicitly says AutoRAG never forces TEI or any external embedding service, and the local embedder is EmbeddingGemma via Ollama.
Getting it running: configuration and commands
The README gives a concrete example of constructing an AutoRAGAgent with searchPaths and parserOptions. The constructor takes searchPaths as an array of directory paths, which is the primary configuration. The parserOptions object includes a thinExtract section with minPages, minChars, minCharsPerPage, timeoutMs, hybrid, and hybridMode. For example, you can set minPages: 3, minChars: 800, minCharsPerPage: 40, timeoutMs: 30000, hybrid: "docling-fast", and hybridMode: "auto". The command-line flags include autorag init --embedder-* and --minsync-max-chunk-size. There is no mention of API keys, vector database operations, or pipeline tuning. The README claims it works with minimal configuration. The project installs dependencies automatically, including MinSync and the local embedder. This is a departure from the legacy Python tool, which required pipeline configuration. The documentation does not describe a full installation command sequence beyond these flags, so a user would need to consult the docs directory for the complete setup.
The thin PDF extraction retry mechanism
One specific mechanism stands out: a parser-owned quality gate for multi-page PDFs. The default PDF parser performs a cheap quality check. If local markdown is unusually sparse, specifically fewer than 800 characters or fewer than 40 characters per detected page, for at least three pages, it retries through OpenDataLoader's docling-fast hybrid backend with hybridMode: "auto" and a 30-second timeout. Dense PDFs are not retried, and hybrid is never used for single-page PDFs or as the first path for images. This is a practical safeguard against low-quality extraction, but it introduces a dependency on an external backend (docling-fast) during retries. The timeout of 30 seconds could add latency for large PDFs that fail the gate. The parserOptions are described as trusted programmatic options, which implies that untrusted callers should not be able to set them, though the README does not specify what trust boundary is enforced.
Limitations and wrong-tool cases
AutoRAG 2.0 is not a general-purpose search engine. It is a single-agent librarian that reads configured source directories directly through bash. This design has a clear failure mode: it requires the agent to have execution access to those directories, which is a security consideration for sensitive or multi-tenant environments. The README mentions scope-checked access for results with source-native identities like kakao:<chat>/<sender>/<chunk>, but it does not detail how scope checking is enforced beyond that. Another limitation is that the self-evolving memory system learns from usage, but a fresh AutoRAG "tries everything," which means early searches may be slower or less precise until it has accumulated feedback. The project is also a complete reimagining of the original AutoRAG, so users expecting the Python pipeline optimization tool will find a different product. The legacy tool is maintained in maintenance mode, which means no new features will come to it. If your need is to optimize a RAG pipeline through AutoML, AutoRAG 2.0 is the wrong tool; you should use the legacy version.
Alternatives and the competitive landscape
The README references a competitive landscape study in docs/competitive-landscape-2026-09.md, which argues that federating CLI-owned stores in place is the durable differentiator. A real alternative is the original AutoRAG (legacy), which takes a fundamentally different approach: it runs experiments over your data to find the optimal RAG pipeline, treating pipeline configuration as a search problem. AutoRAG 2.0 instead uses a fixed agent loop with pluggable retrieval methods, and it learns which retrieval methods work per query type through its memory system. Another alternative would be a traditional vector database with an ingestion pipeline, but AutoRAG 2.0 explicitly avoids forced ingestion into a central index. The README states that external datasources keep their own archive/index lifecycle. This means AutoRAG 2.0 is not comparable to tools that require you to copy documents into a proprietary store. The trade-off is that you get less centralized control over indexing, but you avoid data migration.
Maintenance, licensing, and upgrade cost
The repository shows recent activity with releases v2.4.1, v2.4.0, and v2.3.0 in August and September 2026, indicating active development. The license field is NOASSERTION, which means the repository does not declare a standard open-source license. This is a significant consideration for adoption, because without a clear license, you cannot legally assume you have rights to use, modify, or redistribute the code. The README does not clarify the license terms. The legacy AutoRAG is maintained in maintenance mode with bug fixes and dependency updates, and it continues to be released on PyPI via pip install AutoRAG. The upgrade cost for AutoRAG 2.0 is not documented in the material, but the rapid release cadence suggests that users need to track changes between minor versions. The project's self-evolving memory system means that upgrading may affect learned behavior, though the README does not specify how memory is persisted across versions. Before adopting, verify the license status with the maintainers or check the repository files for a license file, since NOASSERTION is not a usable license identifier.
Editorial conclusion
Adopt AutoRAG 2.0 if you manage a personal or team document collection across CLI-owned stores like katok, discrawl, or rclone, and you want search results that read the source and synthesize answers without migrating data into a central index. Do not adopt it if you need a multi-agent orchestration framework, if you require a private model provider by default, or if you cannot allow the agent to execute bash commands on configured directories. Before using it, verify that MinSync auto-installation is acceptable in your environment, that your local embedder (EmbeddingGemma via Ollama) can run, and that the parserOptions thinExtract thresholds match your PDF corpus. The project is under active development with frequent releases, so check the changelog for breaking changes between v2.4.x versions.
Community notes