DeepTutor
Overview
DeepTutor is an open-source agent-native learning workspace from HKUDS. Its repository describes it as “lifelong personalized tutoring”: one environment for chat, quiz generation, research, visualization, problem solving, mastery practice, books, notebooks, knowledge bases, partners, and memory.
For this vault, DeepTutor matters less as a tutoring app and more as a concrete product example of agent-memory-systems applied to learning. It combines persistent learner context, multi-engine retrieval, installable skills, MCP services, CLI subagents, and inspectable memory into one user-facing workspace.
Implications: DeepTutor is useful evidence that the second-brain pattern is moving beyond personal note vaults into full application workspaces where memory, retrieval, agents, and learning workflows share one runtime.
Key Facts
- The repository presented DeepTutor as an Apache-2.0 project with Python 3.11+, Next.js 16, PyPI, source, Docker, and CLI-only installation paths.
- The GitHub page showed approximately 32.1k stars, 4.2k forks, 1,175 commits, and active 2026 releases at capture time.
- The core product claim is “one runtime for every mode”: Chat, Quiz, Research, Visualize, Solve, and Mastery Path use the same agent loop.
- Its knowledge layer supports LlamaIndex, PageIndex, GraphRAG, lightrag, LightRAG Server, Tencent IMA, and linked obsidian vaults.
- Its memory model is file-backed and inspectable: L1 event traces, L2 curated facts, and L3 cross-surface synthesis.
- Its agent layer includes Partners, My Agents, MCP Services, CLI Apps, and live consultation with tools such as claude-code, Codex, Gemini, Kimi, opencode, or MiMo.
Features
Core Architecture
- One runtime for every mode — Chat, Quiz, Research, Visualize, Solve, Mastery Path share one agent loop
- 32.1k stars — one of the most popular learning workspaces
- Apache-2.0 — open source
- Python 3.11+ / Next.js 16 — modern stack
Ingest & Processing
- Multi-format ingest — books, papers, notes, web content
- Knowledge base creation — from any source type
- Notebook system — interactive analysis and exploration
Search & Retrieval
- Multi-engine retrieval — LlamaIndex, PageIndex, GraphRAG, LightRAG, Tencent IMA
- Hybrid search — graph + vector + keyword across all engines
- Obsidian vault linking — connects to existing Obsidian knowledge
Knowledge Graph
- Three-layer memory — L1 event traces, L2 curated facts, L3 cross-surface synthesis
- File-backed — inspectable, portable memory
- Knowledge visualization — interactive graph views
MCP / Tools
- MCP Services — Model Context Protocol integration
- CLI subagents — Claude Code, Codex, Gemini, Kimi, opencode, MiMo
- Partners system — multi-agent collaboration
- My Agents — custom agent creation
Quality & Governance
- Mastery tracking — progress monitoring across learning surfaces
- Quiz generation — auto-generated assessments
- Inspection — all memory is file-backed and human-readable
Integration
- Claude Code, Codex, Gemini — live consultation with coding agents
- Obsidian — linked vault support
- Docker — containerized deployment
- PyPI + CLI — multiple install paths
Data & Storage
- File-backed memory — L1/L2/L3 layers as files
- Knowledge bases — persistent knowledge storage
- Notebooks — interactive analysis artifacts
Implications: The most relevant design signal is not any single feature. It is the integration pattern: DeepTutor treats memory, retrieval, tool use, and subagents as shared infrastructure across many learning surfaces rather than isolated product tabs.
Relationship to This Vault
DeepTutor sits near second-brain and rag, but it is not an LLM Wiki implementation in the strict artifact-first sense. It can link an Obsidian vault and expose memory as files, but the repository frames the product as a learning workspace rather than a Markdown wiki compiler.
This makes it a useful adjacent case: it shows how LLM Wiki-adjacent ideas can become product architecture. The vault can compare DeepTutor against artifact-first systems when asking whether persistent context should live as human-readable wiki pages, memory traces, knowledge-base indexes, or a hybrid.
Implications: DeepTutor should be tracked as an adjacent second-brain/agent-memory product, not as a replacement for the vault’s compile-to-wiki model.
Relationships
- “belongs-to” agent-memory-systems — product example of persistent agent memory applied to learning workflows.
- “uses” rag — supports multiple retrieval engines for knowledge bases and grounded chat.
- “uses” lightrag — names LightRAG and LightRAG Server as supported retrieval options.
- “compatible-with” obsidian — supports linked Obsidian vaults as a knowledge source.
- “uses” model-context-protocol — offers MCP Services as part of its learning-space/control-plane architecture.
- “operates-with” claude-code — can consult Claude Code as a live coding CLI subagent from a turn.
- “belongs-to” second-brain — expresses the same persistent-context ambition in a learning workspace rather than a pure wiki vault.
Implications: These relationships place DeepTutor in the bridge zone between retrieval-first systems, memory-first systems, and artifact-first second-brain systems.
Deep Research: DeepTutor is one of four systems compared for Deep Research capability in llm-wiki-deep-research-capabilities (the other three: nashsu-llm-wiki, firecrawl, atomicstrata-llm-wiki-compiler).
Open Questions
- How much of DeepTutor’s three-layer memory is directly portable to an LLM Wiki vault without adopting the full application stack?
- Does linked-Obsidian support behave as a durable source-of-truth layer or mainly as a retrieval connector?
- How does DeepTutor’s memory graph compare with this vault’s wikilink graph and community-detection artifacts?
Implications: The next useful ingest would be the linked arXiv paper or docs site, because the README establishes scope but does not fully explain implementation trade-offs.