Engineering teams building AI agents quickly discover that context windows are not databases. When agents rely solely on short-term session memory or unstructured retrieval across raw documents, they can suffer from amnesia, hallucinated relationships, and context bloat. To act autonomously and reliably across sessions, agents need a durable knowledge system they can navigate, cite, and update.
This article separates three concepts. An LLM wiki is the durable knowledge system itself. A wiki tool such as Cognition's DeepWiki turns software repositories into browsable documentation and code-grounded Q&A. A database such as HydraDB provides durable storage and query infrastructure for teams building custom agent wikis. These layers can be combined, but they are not interchangeable.
For a controlled, low-concurrency prototype, a local directory of plain-text files that agents read and edit with file-system tools can be a low-infrastructure starting point. As agents execute tasks, they can synthesize findings, update state, and commit changes back to the text files.
The pressure to change this architecture arises when multiple agents attempt to write concurrently, when untyped file links fail to represent complex business logic, and when application security requires strict tenant boundaries.
The design question is twofold: which wiki workflow fits the user, and which persistence layer fits the workload's scale, concurrency, retrieval, and governance constraints.
Treating a wiki tool, a Markdown workflow, a managed memory service, and a graph database as interchangeable options leads to architectural mistakes. Teams should first identify which layer they are selecting, then evaluate it against the workload's constraints: concurrency, relationship traversal, provenance, temporal state, and access scope.
Key takeaways on LLM wiki tools and databases
- Separate the wiki application from its persistence layer. Tools such as DeepWiki generate and expose a wiki, while databases such as HydraDB provide storage and query infrastructure beneath custom wiki applications.
- Start an LLM wiki with Markdown and Git unless the workload proves it needs more infrastructure.
- Move beyond files when concurrent agent writes, weak entity links, provenance gaps, or tenant access rules become operational blockers.
- Choose a memory service when vendor-supplied personalization or conversation-memory behavior is required. Choose a graph database such as HydraDB when typed relationships and multi-hop traversal are load-bearing.
- MCP exposes tools and resources to agents and defines optional transport-level authorization, but it does not define the storage model, domain-specific authorization policy, provenance model, or schema.
LLM wiki tools and databases comparison
Evaluating products across different layers of the context stack requires understanding their primary operational role.
| Tool / category | Layer | Core strength | Choose when... |
|---|---|---|---|
| Markdown and Git | File-based wiki | Transparent, versioned plain-text knowledge | Simple prototypes or controlled single-agent wikis |
| Obsidian | Local-first knowledge app | Markdown UX, backlinks, visual navigation | Human-friendly local wiki workflows over Markdown files |
| Cognition DeepWiki | AI-generated code wiki | Repository documentation, architecture diagrams, source links, and code-grounded Q&A | Teams need a browsable, queryable wiki for software repositories |
| Notion | Workspace source | Collaborative docs, databases, and permissions | Teams already run operations in Notion |
| Confluence | Enterprise workspace source | Atlassian-native documentation and governance | Enterprise docs, Jira links, SSO, and auditability matter most |
| Letta | Stateful agent runtime | Runtime-managed long-term agent memory | The agent runtime must manage context and memory |
| Mem0 | Memory service | Managed personalization and preference memory | User-level memory matters more than ontology control |
| Zep | Context/memory service | Temporal context graphs and assembled context | Managed context from chats, documents, and business data is the primary requirement |
| Graphiti | Temporal graph framework | Time-aware entity and relationship extraction | Temporal graph memory with a customer-operated backend |
| Cognee | Graph-backed memory layer | Ingestion plus relational, vector, and graph memory workflows | A configurable memory layer across pluggable stores |
| Vector/Search DBs | Retrieval/index layer | Semantic, lexical, and hybrid search | Chunk retrieval matters more than relationship modeling |
| HydraDB | Graph database + managed context platform | Typed graph and temporal/source-aware context | Multi-hop relationship context with customer-owned app logic |
| Neo4j | Graph database | Mature Cypher graph database ecosystem | Traditional graph workloads or existing Neo4j expertise |
Wiki tools, memory services, frameworks, retrieval systems, and graph databases address different layers of the system. A product at one layer may use products from other layers underneath it.
Defining an LLM wiki
An LLM wiki is a durable, interlinked body of synthesized knowledge that AI agents can read, navigate, cite, and update over time. The wiki acts as a shared, persistent brain across different agent sessions and workflows.
Many associate the concept with Andrej Karpathy's public "llm-wiki" gist, which outlines an agent-maintained personal knowledge base. For production, keeping raw inputs distinct from synthesized claims makes source evidence easier to reprocess and audit.
Cognition's DeepWiki is a code-focused example of the wiki application layer. It indexes repositories and generates documentation, architecture diagrams, source links, and code-grounded Q&A. Its public MCP server lets agents read and query documentation for public repositories. DeepWiki is a wiki application, not a general-purpose database.
An LLM wiki differs fundamentally from providing an agent with a large context window. Context windows are ephemeral scratchpads. An LLM wiki is a persistent system of record.
An LLM wiki also differs from a simple retrieval-augmented generation (RAG) pipeline. A basic RAG implementation may retrieve source chunks through lexical or vector similarity, while a wiki adds durable, updateable knowledge organization. Explicit entity identity, typed relationships, canonical-state rules, and controlled writes become requirements only when the workload needs them.
| Term | Primary purpose | Persistence model | Best-fit use case |
|---|---|---|---|
| LLM wiki | Durable knowledge agents can navigate and update | Interlinked pages, entities, or graph-backed records | Accumulated team, product, customer, or domain knowledge |
| Agent memory | Preserve useful state across sessions | Memory blocks, summaries, profiles, or extracted facts | Personalization and long-running agents |
| RAG | Ground answers in source documents | Chunks plus lexical/vector indexes | Q&A over document corpora |
| GraphRAG | Improve retrieval with entities and relationships | Graph-enriched chunks, entities, summaries, or edges | Multi-hop questions and relationship-heavy corpora |
Markdown and Git as the LLM wiki baseline
Markdown and Git provide a credible low-infrastructure baseline for agent knowledge. Plain-text files are inspectable and portable, and models can consume them without decoding a proprietary document format. Git provides version history, rollback, and branch-and-merge workflows that can support reviewable agent edits.
For a solo prototype, this architecture avoids operating a dedicated database, but repository hosting, backups, CI, access control, indexing, review, and merge resolution still require operational work.
Mechanical breakpoints trigger migration from this baseline, not arbitrary page counts:
- Concurrent writes: Overlapping edits to the same lines can create Git merge conflicts. Non-overlapping edits may merge cleanly even when they contradict semantically, so semantic review is still required before those changes enter the knowledge base.
- Untyped links: Convention-based wiki-links and frontmatter do not enforce governed, typed edges between entities.
- Entity duplication: Markdown and Git do not enforce canonical entity identity, so application conventions or validation must prevent and reconcile duplicate representations.
- Weak provenance: Git tracks file-level changes, but enforcing claim-level source attribution requires rigid manual formatting.
- Temporal ambiguity: Reverting to a previous commit reveals past file states. Answering queries about what was true during a specific historical window requires native valid-time and transaction-time modeling.
- Coarse access boundaries: Git does not natively provide claim- or row-level authorization. Tenant-aware, user-specific retrieval policies require repository partitioning or an application authorization layer.
Every additional infrastructure layer should directly address one or more of these specific mechanical breakpoints.
Evaluation criteria for LLM wiki tools and databases
Evaluating persistence tools requires mapping them to the specific layer of the context stack they address. Flattening distinct architectural components into a single competitive matrix obscures their actual operational roles.
The flow of context generally follows this path: sources → ingestion/frameworks → durable knowledge store → retrieval indexes → API/MCP tools → agent context → review/update loop
- Workspace tools function as primary human-centric sources of truth.
- Vector and search systems function primarily as ranked-retrieval infrastructure. Whether they also serve as an authoritative store or preserve claim provenance depends on the exact product, schema, and surrounding application.
- Frameworks orchestrate ingestion and retrieval, and many persist through configured stores. Production durability and scale depend on those stores, model calls, pipeline configuration, topology, and whether a managed edition operates the stack.
- The Model Context Protocol (MCP) acts as delivery plumbing that exposes selected stores and tools to agents. It does not dictate the underlying persistence model, domain schema, or update workflow.
| Tool / category | Concurrent writes | Typed relationships | Provenance + temporal state | Access scope | Ownership model |
|---|---|---|---|---|---|
| Markdown and Git | Partial (branch/merge workflows) | Partial (links/frontmatter) | Partial (commits help. Claim/as-of state is manual) | Partial (repo/file permissions) | Customer-owned |
| Obsidian | Partial (Sync merges same-file edits but does not provide live co-editing) | Partial (wiki-links) | Partial (manual notes, Sync history, or Git history) | Partial (vault/filesystem scope without fine-grained permissions within a shared Sync vault) | Customer-owned |
| Cognition DeepWiki | Service-managed. Database-level write semantics are not exposed | Partial (generated page hierarchy and source links, not a user-defined typed graph) | Partial (source-code links. Claim-level provenance and as-of state are not documented) | Public DeepWiki supports public GitHub repositories. Authenticated Devin supports public and private repositories | Service-owned |
| Notion | Supported (workspace collaboration) | Partial (database relations) | Partial (page history. Claim/as-of state must be modeled) | Supported (workspace layer. App enforces agent retrieval) | Workspace-owned |
| Confluence | Supported (enterprise collaboration) | Partial (hierarchy/Jira links) | Partial (document versions. Granular temporal state must be modeled) | Supported (workspace layer. App enforces agent retrieval) | Workspace-owned |
| Letta | Workflow-dependent (runtime-managed) | Partial (Git-backed MemFS files, not a typed graph model) | Partial (Git history. Source semantics are application-defined) | Deployment- and plan-dependent | Runtime-owned |
| Mem0 | Partial (service-managed) | Partial (extracted memories) | Partial (depends on retained source metadata and update policy) | Partial (tenant/app design dependent) | Service-owned |
| Zep | Service-managed. Database-level write semantics are not exposed | Supported (custom entity and edge types) | Supported (temporal facts and episode associations) | Project isolation, Enterprise ABAC and team RBAC | Service-owned |
| Graphiti | Backend- and application-dependent | Supported | Supported (bitemporal facts and episode provenance) | Namespace, backend, and application-dependent | Framework/customer-owned |
| Cognee | Deployment- and backend-dependent | Partial (knowledge-graph schema depends on extraction/configuration) | Edition- and configuration-dependent | OSS dataset controls. Cloud dataset isolation and RBAC | OSS customer-owned. Cloud service-owned. BYOC shared |
| Vector/Search DBs | Product- and topology-specific | Product-specific. Weaviate supports directional cross-references | Product- and schema-specific | Product- and plan-specific. Filters are not equivalent to authorization | Managed or customer-operated |
| HydraDB | Partial (writes serialize per graph scope/cell. Cells can progress independently) | Supported (in the open core) | Partial (managed responses expose source/chunk IDs and edge-level temporal facts. Lineage policy is application-owned) | Partial (open-core exact-scope authorization. Managed databases isolate customers/environments and collections provide logical scope) | Managed service or licensed self-hosting. Customer owns application semantics |
| Neo4j | Supported | Supported | Partial (provenance and temporal semantics are schema/app responsibilities) | Supported | Customer-owned |
Tools beyond the LLM wiki persistence layer
These products span orchestration, indexing, interaction, and persistence abstractions rather than one clean layer above storage.
LlamaIndex can persist through configured stores, LangGraph supports durable checkpoints and long-term stores, Google NotebookLM stores notebook sources and state, and Microsoft GraphRAG persists indexing outputs through configured storage providers. Claude Code and Cursor are coding interfaces. These products aren't interchangeable with a general-purpose transactional graph database. Each persistence contract requires separate evaluation.
File-based and local-first LLM wiki tools
Markdown and Git for file-based LLM wikis
Best for
Prototyping, controlled single-agent workflows, and workflows requiring transparent, inspectable files.
Why it fits
As the established baseline, keeping source content in plain text improves content portability and reduces early dependence on a proprietary knowledge-store format.
Watch out for
The mechanical breakpoints include textual merge conflicts, semantic contradictions that merge cleanly, and the manual enforcement required for entity canonicalization and claim-level citations.
Pricing model
Open-source tooling. Operational costs are limited to standard Git hosting and CI/CD infrastructure.
Obsidian for local-first LLM wikis
Best for
Personal knowledge management, local-first environments, and human-in-the-loop review of agent-generated Markdown files.
Why it fits
Obsidian provides a GUI over local Markdown files. Its visual graph navigation and bidirectional links support review of wiki structure while retaining Markdown as the underlying format, including for experiments with Karpathy's wiki pattern.
It fits workflows in which human reviewers actively curate, restructure, and validate agent-generated context.
Watch out for
Obsidian Headless Sync supports servers, CI, agents, and automated workflows in open beta. Shared vaults merge same-file edits but don't provide live co-editing or fine-grained collaborator permissions. Obsidian doesn't document database-style transactions or enforced typed edges.
Pricing model
As of September 5, 2026, Obsidian is free for personal and commercial use. An optional Commercial support license costs $50 per user per year. Sync and Publish are separate paid services.
AI-generated LLM wiki tools
Cognition DeepWiki for code-repository wikis
Best for
Engineering teams that need automatically generated, browsable documentation and Q&A for software repositories.
Why it fits
Cognition DeepWiki indexes repositories and generates documentation, architecture diagrams, source links, and codebase summaries. Ask Devin combines the generated wiki with code search to answer questions grounded in the repository.
The DeepWiki MCP server lets AI agents read wiki structures, retrieve wiki contents, and ask questions about public repositories.
Watch out for
DeepWiki is specialized for repository understanding. Its public service and MCP server cover public GitHub repositories. Private repository access and broader agent workflows use the authenticated Devin product surface.
DeepWiki supplies the wiki experience. It is not a general-purpose persistence database for custom agent knowledge systems.
Pricing model
Public DeepWiki is free for public GitHub repositories. Higher-effort wiki generation uses Devin ACUs, while private repository access requires a Devin account.
Workspace tools as LLM wiki sources.
Notion for collaborative LLM wiki sources
Best for
Organizations already relying on Notion as their primary operating system for internal documentation, project management, and lightweight relational databases.
Why it fits
Notion provides a polished collaborative environment for human operators while offering sufficient structure through block types and database relations for agents to navigate. Agents interact with Notion through official APIs or MCP servers, treating Notion as a governed, human-readable source of truth that balances unstructured prose with tabular data.
Watch out for
Notion's API documents an average limit of three requests per second per integration, plus payload limits. High-frequency integrations must choose between structured block traversal and the page-as-Markdown endpoint for supported reads. Page history is version-oriented, so claim-level valid-time semantics require separate modeling.
Hosted Notion MCP is limited by the connected user's permissions, while API integrations see only content explicitly shared with the integration. The application should enforce the effective access model for the credential it uses.
Pricing model
As of September 5, 2026, Notion offers Free, Plus, Business, and Enterprise plans. Paid plans are billed per member, with Enterprise pricing available through sales.
Confluence for enterprise LLM wiki sources
Best for
Enterprise engineering and product teams heavily invested in the Atlassian ecosystem, requiring strict IT governance, SSO, and compliance standards.
Why it fits
Confluence is an enterprise documentation platform with space-level permissions, detailed audit logs, and data residency options. It can serve as the canonical source for architecture decision records, security policies, and product requirements.
Native Jira integration can surface and link Jira data inside Confluence. The integration alone doesn't keep retrieved context semantically current.
Watch out for
The Confluence page-update API is page- and version-oriented. Applications that need claim-level writes must map those changes into page bodies and handle version conflicts, so teams should benchmark high-frequency agent writes against their page model.
High-frequency agent write loops are better routed through dedicated review workflows or separate databases rather than directly overwriting authoritative enterprise documentation.
Pricing model
As of September 5, 2026, Confluence offers Free, Standard, Premium, and Enterprise plans. Product audit logs and data residency begin at Standard. User-activity auditing is Enterprise, and SSO generally requires Atlassian Guard or Enterprise.
Stateful runtimes and memory services for AI agents
Letta for stateful agent memory
Best for
Engineering teams seeking a stateful-agent runtime that intrinsically manages long-term memory and context paging as part of the execution loop.
Why it fits
Letta gives each stateful agent a Git-backed MemFS repository. Files under system/ stay in the system prompt. Other files remain outside context until the agent reads them.
This approach fits systems in which the agent runtime owns memory lifecycle and orchestration behavior.
Watch out for
Adopting Letta requires committing to its specific runtime architecture. Letta doesn't fit architectures that separate orchestration logic from passive, durable storage.
Letta provides local, self-hosted, and Cloud deployments with different backup and access-control boundaries. Evaluate provenance, tenant isolation, and administrative controls against the selected deployment and plan.
Pricing model
Open-source core framework, supplemented by managed cloud services and usage-based billing options.
Mem0 for user memory and personalization
Best for
Applications primarily focused on capturing cross-session user personalization, conversational preferences, and recurring behavioral facts.
Why it fits
Mem0 is an opinionated service that automatically extracts, updates, and retrieves memories from conversational inputs. It reduces the engineering burden of designing custom extraction prompts and memory management policies.
Mem0 provides managed extraction and recall for assistants that need user profiles, preferences, and past instructions.
Watch out for
Mem0 Platform Graph Memory trades some modeling control for managed memory behavior. It links memories through co-occurring entities and does not expose typed, custom-labeled relationships or a separate graph payload. Mem0 Open Source instead lets teams configure and operate the self-hosted LLM, embedder, vector store, and reranker, so the control boundary differs by mode. Evaluate conflict resolution, decay, and forgetting behavior for the exact mode selected.
Pricing model
Open-source components alongside managed API consumption tiers and custom enterprise pricing.
Zep for assembled context memory
Best for
AI platforms where managed temporal context and retrieval across chats, documents, and business data are primary requirements.
Why it fits
Zep converts chats, business data, documents, and JSON into temporal Context Graphs, generates incremental thread summaries, and assembles context with semantic, full-text, and graph retrieval. Downstream conversational coherence and workload-specific latency still require application testing.
Watch out for
Zep supports custom entity and edge types, project isolation, Enterprise ABAC, and team RBAC, and episode-to-artifact provenance. It remains a managed agent-memory and context service rather than a general-purpose graph database, so evaluate its Context Graph APIs against database-level query, transaction, and deployment requirements.
Pricing model
Managed cloud service using credit-based consumption tiers. Graphiti is a related open-source temporal framework.
Graph and GraphRAG frameworks for LLM wikis
Graphiti for temporal graph memory
Best for
Engineering teams requiring a temporal knowledge-graph framework who are fully prepared to provision, manage, and scale the underlying backend database themselves.
Why it fits
Graphiti focuses on modeling time-aware entities and relationships. It handles the ingestion logic required to extract facts from unstructured episodes and merge them into a cohesive graph. The framework's temporal design ensures agents can differentiate between current active state and superseded historical facts.
Watch out for
Graphiti is an application framework. It currently supports Neo4j, FalkorDB, and Amazon Neptune. Storage durability, database concurrency, and availability depend on the selected backend and topology, while authorization and governance also depend on the surrounding application.
Graphiti links episodes to extracted nodes and relationships, providing episode-level provenance. Mapping those episode IDs to source-system citations and governance policies remains application work.
Pricing model
Open-source framework. Total cost of ownership is driven by backend database hosting, infrastructure operations, and LLM API consumption.
Cognee for graph-backed memory pipelines
Best for
Teams looking to implement configurable GraphRAG workflows without handwriting every individual ingestion, chunking, vectorization, and extraction pipeline.
Why it fits
Cognee orchestrates document parsing, embedding generation, entity extraction, graph construction, and retrieval. Its configuration model composes relational storage for documents, metadata, and system state, vector storage for embeddings and semantic search, and graph storage for entities and relationships. Its built-in pipelines can reduce how much ingestion, extraction, and retrieval orchestration the application must implement.
Watch out for
In self-hosted Cognee, retrieval quality and operating behavior depend on the configured models, pipelines, and relational, vector, and graph backends. Cognee Cloud separately manages compute, storage, pipeline execution, dataset isolation, and RBAC, so evaluate the exact Open Source, Cloud, or Enterprise/BYOC surface.
Pricing model
Cognee Open Source is Apache-2.0. As of September 5, 2026, Cognee Cloud includes a free tier and lists Standard processing at $2.50 per 1 million tokens plus $5 per month for each additional workspace. Enterprise/BYOC pricing is custom.
Retrieval and index tools for LLM wikis
Vector and search databases for LLM wiki retrieval
This category includes Pinecone, Qdrant, Weaviate, pgvector, Elasticsearch/OpenSearch, and Vespa.
Best for
Applications where the primary requirement is semantic, lexical, or hybrid retrieval across vast, relatively flat corpora of text chunks.
Why it fits
Vector databases excel at capturing semantic similarity, allowing agents to retrieve relevant information even when exact keywords are missing. BM25 ranks lexical matches for product names and policy terms. Exact identifiers should use term-level or ID queries when the selected product provides them.
Metadata filtering allows applications to constrain retrieval by tenant, document type, or source system.
Watch out for
These products center on ranked retrieval, but their data models vary. Weaviate supports directional cross-references, and pgvector retains PostgreSQL relations, joins, and ACID behavior. Evaluate relationship traversal, entity identity, and provenance product by product.
When relationships exist only as vector metadata, traversal and canonicalization move into application code and can become harder to maintain as the model grows.
Pricing model
Highly variable across the category, encompassing managed SaaS platforms, open-source self-hosted clusters, and standard PostgreSQL infrastructure costs.
Graph databases for LLM wikis
HydraDB for graph-native LLM wiki infrastructure
Best for
Engineering teams evaluating HydraDB as graph-database infrastructure when typed relationships and multi-hop traversal are central, with managed temporal and source-linked context available where those features are required.
Why it fits
HydraDB is an object-store-native graph database that maps pages to nodes and wiki-links to typed edges. S3-compatible object storage is the durable source of truth, while graph nodes and indexers keep disposable state in memory and on local SSD or NVMe. This design separates durable graph storage from compute and is intended to lower graph-storage cost. The architecture alone does not establish a universal scale, latency, or total-cost advantage.
HydraDB maintains a strict architectural boundary between layers:
- Open core: Manages durable graph storage, exact-scope authorization, and traversal execution via JSON, streaming HTTPS APIs, and an OpenCypher subset over Bolt 5.1 through 5.4.
- Managed platform: Handles asynchronous ingestion, hybrid retrieval that combines dense semantic and BM25 scores, exact metadata filtering before ranking, graph-context enrichment, separate databases for customer or environment isolation, and collections for logical scoping inside a database.
- Customer application: Retains control over domain ontologies, agent prompts, authorization policies, and workflow orchestration.
On the managed platform, optional temporal reasoning can return current, as-of, range, or upcoming edge-level facts, and responses can carry source, chunk, entity, and relationship identifiers. Those identifiers support attribution but do not by themselves constitute complete lineage or an immutable audit trail.
Watch out for
HydraDB provides database infrastructure for teams that build the application logic orchestrating the agent workflow.
While HydraDB supports a practical OpenCypher subset, it is not a guaranteed drop-in replacement for every legacy Neo4j workload. Migration feasibility depends on exact query requirements. HydraDB is over-engineered for simple RAG pipelines lacking relational complexity.
Pricing model
As of September 5, 2026, HydraDB lists Ship as free, Surge at $25/month with up to 2 GB of graph storage and $0.50/GB/month overage, Scale at $399/month with up to 10 GB and $0.25/GB/month overage plus an option to self-host under license, and Enterprise at custom pricing for BYOC or fully self-hosted deployment.
Neo4j for Neo4j-native Cypher and graph workloads
Best for
Teams that need full Neo4j Cypher behavior, its procedures or Graph Data Science tooling, managed AuraDB, clustering, or compatibility with established Neo4j workloads.
Why it fits
Neo4j documents native nodes and relationships, property indexes, Cypher, Bolt, APOC, Graph Data Science, clustering, self-managed editions, and AuraDB. Its transactions are ACID-compliant. Default isolation is read-committed, with explicit locking available when stricter serialization is needed.
Vector indexes are available for nodes and relationships. These capabilities are relevant when Neo4j-specific query, procedure, analytics, deployment, or ecosystem behavior is decisive.
Watch out for
In Neo4j, claim-level provenance and business-valid-time semantics remain schema and application responsibilities even though Cypher supports temporal value types. Deployment cost depends on edition, topology, workload, and service model. No workload-equivalent evidence supports a general cost conclusion.
Pricing model
As of September 5, 2026, Neo4j lists AuraDB Free at $0, Professional at $65/GB/month with a 1 GB minimum, Business Critical at $146/GB/month with a 2 GB minimum, and Virtual Dedicated Cloud by quote. Self-managed Community Edition is available under GPLv3. Enterprise and Infinigraph use commercial terms.
Testing LLM wiki infrastructure before purchase
Selecting infrastructure based on marketing pages or single-metric benchmarks invites production failure. Teams evaluating persistence layers for an LLM wiki must validate the architecture against four specific operational tests.
Read-path test for LLM wiki retrieval
The evaluation should run a realistic query that exercises the retrieval signals and controls the workload actually needs. Candidates don't need to implement the same retrieval stack.
Example query: "What changed about Acme Corp's renewal risk since the last quarterly business review?"
The test should determine whether the end-to-end system can:
- Resolve the string "Acme Corp" to a canonical entity ID.
- Filter the retrieval scope to authorized CRM records, support tickets, and specific account owner notes.
- Execute semantic search for "renewal risk" and lexical search for specific contract terms.
- Traverse the graph to locate related incidents and decision records.
- Apply a strict temporal filter to exclude data generated prior to the last review date.
- Return the synthesized answer alongside exact source citations, all within the LLM's token budget.
Write-path test for agent updates
The write-path test should simulate high-concurrency contention by forcing two independent agents to update the exact same entity or factual claim simultaneously.
The end-to-end write path, including application logic, review policy, and storage, must demonstrate that it supports:
- Submitting proposed state changes rather than unconditionally overwriting the canonical record.
- Enforcing entity canonicalization to prevent creating duplicate records for the same concept.
- Routing highly destructive or low-confidence changes to a human reviewer or deterministic policy engine.
- Retaining complete merge history, ensuring any incorrect agent update can be rolled back cleanly.
- Mapping strict claim-level provenance so the system explicitly records why it believes the new fact is true.
Access-scope test for secure agent retrieval
The end-to-end ingestion and retrieval path must preserve the intended source-system security boundaries. The connector, identity layer, application, query service, and store may enforce different parts of that policy.
Production systems must strictly handle:
- Mirroring source-level permissions from external systems like Notion, Jira, and Slack.
- Isolating customers or environments through documented top-level isolation boundaries, with namespaces or logical collections used only where their contract provides the required isolation.
- Recording the ingestion, retrieval, and agent-write events required by the threat model, and verifying whether any component provides tamper-evident or immutable audit storage.
- Redacting or isolating sensitive data, secrets, and regulated customer-confidential content.
- Neutralizing prompt-injection attacks by strictly treating retrieved text as passive evidence, never as executable instruction.
MCP test for agent tool delivery
Teams should define the architectural role of the Model Context Protocol in the stack.
MCP standardizes host, client, and server interactions for negotiated capabilities including resources, prompts, and tools. An MCP server can expose operations that search, traverse relationships, fetch citations, or propose writes.
MCP does not define the underlying data schema, persistence semantics, provenance model, or update workflow. It defines optional transport-level authorization, but not the application's domain-specific access policy or agent orchestration logic.
Passing data through MCP does not transform an unstructured tool endpoint into an audited, transactional database.
Selecting an LLM wiki architecture
Selecting the correct foundation for an LLM wiki requires matching the technology to the workload's most severe operational constraint.
Choose Cognition DeepWiki if... The goal is to generate and query documentation for software repositories. DeepWiki supplies the wiki application, while broader custom knowledge systems still require teams to evaluate their persistence and data-model requirements separately.
Choose Markdown and Git if... The workflow is a prototype or a strictly controlled single-agent system, and transparent, portable files are the priority. Markdown and Git remain the baseline until a concrete requirement for coordinated writes, typed relationships, provenance, temporal state, or access scope requires more infrastructure.
Choose Obsidian if... Obsidian fits workflows that require a local-first, human-centric interface layered over Markdown files. It supports subject matter experts who visually navigate, curate, and review the knowledge agents produce.
Choose Notion or Confluence if... The knowledge base must serve human operational workflows first, and agent retrieval second. Default to Notion for flexible, collaborative team workspaces. Default to Confluence for strict enterprise documentation, Atlassian ecosystem alignment, and rigid IT governance.
Choose Letta, Mem0, or Zep if... Letta fits when its stateful-agent harness and Git-backed MemFS should own the execution loop and long-term agent memory. Mem0 Platform fits applications that require managed extraction and recall for user or application memory. Zep fits applications that require managed temporal Context Graphs and assembled context from chats and business data.
Choose Graphiti or Cognee if... Graphiti fits teams that require an open-source temporal knowledge-graph framework and will operate a supported graph backend. Cognee fits when its graph-backed memory lifecycle and exact Open Source, Cloud, or Enterprise/BYOC operating model match the requirements.
Choose vector/search databases if... Vector and search databases fit workloads in which the primary bottleneck is semantic, lexical, or hybrid retrieval over relatively flat records and the selected product's relationship, provenance, access-control, and temporal capabilities match the workload.
Choose HydraDB if... HydraDB fits workloads that need an object-store-native graph database for multi-hop traversal and, on the managed platform, edge-level temporal facts and source-linked context, while the application retains domain semantics, end-user authorization, and orchestration.
Choose Neo4j if... Neo4j fits workloads that depend on Neo4j-specific Cypher behavior, procedures, Graph Data Science, clustering, AuraDB, or established Neo4j operational tooling.
Frequently asked questions
What is an LLM wiki?
An LLM wiki is a persistent knowledge base that agents can read, update, cite, and navigate across sessions. It stores durable information and source references and may represent entities and relationships in files, databases, or graphs.
Should I start an LLM wiki with Markdown and Git?
Yes, for prototypes, single-person projects, and controlled single-agent workflows. Markdown and Git are transparent, portable, and easy for agents to read and edit.
When should I move beyond Markdown and Git for an LLM wiki?
Teams should move beyond Markdown and Git when they encounter concurrent writes, duplicate entities, weak provenance, untyped links, temporal ambiguity, or tenant-level access control.
Is an LLM wiki the same as RAG?
Not necessarily. A simple RAG pipeline retrieves source material to ground a response, while an LLM wiki emphasizes durable, updateable knowledge organization. A production system can combine both patterns.
When does an LLM wiki need a graph database?
Use a graph database when typed relationships and multi-hop traversal are load-bearing and a graph query/storage model is preferable to application-managed joins. Provenance and historical-state requirements are separate capabilities that can be implemented in more than one storage model.
Does MCP replace the need for a database?
No. MCP standardizes how hosts, clients, and servers exchange context and invoke capabilities and defines optional transport-level authorization. It does not define the database, domain schema, application-specific access policy, temporal model, or data-governance workflow.
Should I use a memory service or a graph database for agent context?
A memory service fits when its exact managed behavior, such as preference extraction, conversation continuity, or assembled context, matches the application. A graph database fits when typed relationships and multi-hop traversal justify a graph storage and query model.
How should teams choose between HydraDB and Neo4j?
HydraDB fits when its object-store-native architecture and practical OpenCypher subset, plus optional managed source-linked and temporal context, match the workload. Neo4j fits when the workload requires Neo4j-specific Cypher, procedures, GDS, clustering, AuraDB, or ecosystem compatibility. Teams should test actual query, transaction, procedure, and driver requirements before treating either system as a replacement for the other.
Conclusion: choosing LLM wiki infrastructure
Start with the simplest architecture that works, and move up the stack only when a specific requirement forces the change.
Use a wiki tool such as DeepWiki for repository documentation and Q&A, Markdown and Git for controlled agent-maintained knowledge, memory services for managed memory behavior, vector or search systems for retrieval-heavy workloads, and graph databases when typed relationships and multi-hop traversal become load-bearing.
Before buying, test the architecture against a representative ontology and workload. Evaluate HydraDB when governed, durable relationships are the capability your current stack cannot provide.
Teams evaluating these workloads can book a demo with the HydraDB team.
Top comments (0)