What is an AI-native wiki?

Why classic wikis fail agents

A classic wiki — MediaWiki, Confluence, a static site, even a well-maintained Notion space — is optimized for the human reading experience: clean HTML, navigation, search that returns a list of links. When an AI agent needs to retrieve information from one of these systems, it faces a pile of obstacles.

• No structured query interface. Agents have to scrape rendered HTML, fight pagination, and parse navigation markup. There is no endpoint that returns a page as structured data.
• Keyword-only search. Classic wiki search is Lucene BM25 at best. An agent asking "what is our retry policy for the payments service?" will get nothing useful if the relevant page uses different words.
• No knowledge graph. A classic wiki has pages and links, but not entities, typed relationships, or embeddings. An agent cannot follow a semantic relationship — it can only follow a hyperlink.
• No token-budgeted projections. Every page is rendered at full length. An agent retrieving ten pages to answer a question blows its context window before it can synthesize an answer.
• No change feed. External vector stores cannot stay in sync without a change feed. A classic wiki has no incremental export; you batch-crawl or you go stale.

The practical result is that teams either build bespoke infrastructure on top of their wiki (custom connectors, scrapers, ETL pipelines), or their agents simply do not use the team's knowledge base. Both outcomes are worse than they should be.

The five things that make a wiki AI-native

1. A native protocol for agent queries (MCP)

The most direct way for an AI agent to query a knowledge base is via a purpose-built protocol — not HTTP scraping, not a search API that returns HTML links. The Model Context Protocol (MCP) is an open standard that lets agents discover and call tools exposed by a server over a standardized interface. An AI-native wiki exposes its retrieval capabilities — page lookup, semantic search, knowledge-graph traversal, structural navigation — as native MCP tools. The agent calls a tool, gets structured data back, cites it, and moves on. No connector to build. No middleware to maintain.

2. Hybrid retrieval — keyword + dense + knowledge-graph rerank

Keyword search (BM25) finds pages that contain the right words. Dense embedding search finds pages that are semantically similar to the question. Neither is sufficient alone. An AI-native wiki combines both with weighted Reciprocal Rank Fusion and adds an optional knowledge-graph rerank that boosts pages whose entities are related to the query. The result is retrieval that works when an agent asks in plain language, uses domain-specific terminology, or asks about a concept that is described differently across pages.

Reliability matters too: an AI-native wiki's retrieval does not silently degrade when one component fails. If the dense backend is unavailable, the system fails closed to BM25 — agents still get results, not an error.

3. A knowledge graph derived from your content

A link graph (who links to whom) is useful but shallow. A knowledge graph extracts the entities mentioned in your pages — technologies, people, concepts, systems — and the relationships between them: co-mentions, typed predicates ("Service X depends on Service Y"), hub memberships. Agents can traverse this graph to find related pages, discover concepts, and understand the semantic structure of your content — not just follow the hyperlinks an author happened to write.

4. Agent-grade page projections

Agents work within token budgets. A 10,000-word runbook is not useful to an agent that needs a 500-token summary of the most operationally relevant facts. An AI-native wiki serves a token-budgeted projection of each page — the most retrieval-relevant content, structured for machine consumption — alongside the full human-readable version. Pages can carry metadata that marks them as runbooks, specifies their verification status, and surfaces derived agent hints. The source of truth is one page; the rendering is adapted per consumer.

5. A change feed for sync pipelines

External RAG pipelines and vector stores need to know what changed since they last synced. An AI-native wiki exposes an incremental change feed — a time-ordered log of page additions, modifications, and deletions — so sync pipelines can update their indexes without crawling the entire site on every run. This is the difference between a knowledge base that stays current and one that silently drifts stale.

How Wikantik implements each of these

Wikantik is built around these five properties. On protocol: it ships two native MCP servers — /knowledge-mcp with 18 read-only tools (hybrid retrieval, knowledge-graph traversal, structural navigation, agent projections, batched page reads, ontology/SPARQL access) and /wikantik-admin-mcp with 25 write and analytics tools — plus an OpenAPI 3.1 tool server at /tools/* for non-MCP clients. On retrieval: BM25 + dense embeddings (pluggable backend: in-memory, pgvector, or Lucene HNSW) fused with weighted RRF, with knowledge-graph rerank and fail-closed BM25 fallback. On knowledge graph: LLM-extracted entities and typed-relation edges stored in pgvector, with hub discovery and a curated inclusion policy. On projections: /api/pages/for-agent/{id} returns a token-budgeted projection with derived agent hints; pages carry type: runbook and verification metadata. On change feed: /api/changes?since=… exposes an incremental feed for sync pipelines; /wiki/{slug}?format=md|json provides raw content for direct RAG ingestion.

Frequently asked questions

Does an AI-native wiki replace RAG pipelines?

Not exactly — it makes them better and simpler. An AI-native wiki provides the structured retrieval layer (hybrid search, knowledge graph, MCP tools) that a RAG pipeline needs to function well, so you are not building that infrastructure from scratch. The wiki becomes the authoritative source; the RAG pipeline queries it. A change-feed endpoint lets sync pipelines keep external vector stores up to date incrementally.

What is the Model Context Protocol (MCP)?

MCP is an open protocol for connecting AI agents to external tools and data sources over a standardized interface. An MCP-compatible AI client — Claude, a custom LLM assistant, or any agent that speaks MCP — can discover and call tools exposed by an MCP server, including tools that query a knowledge base. An AI-native wiki exposes its retrieval capabilities as native MCP tools so agents can use them directly.

Can a classic wiki be retrofitted to be AI-native?

Partially. You can add a vector store and a search API on top of a classic wiki's HTML export, but you cannot easily retrofit a knowledge graph derived from the wiki's actual structure, canonical page identifiers that survive renames, agent-grade projections that summarize content to a token budget, or a native MCP server. These capabilities require the wiki engine itself to be designed with machine consumers in mind from the start.