What it is for
Wikilayer fits where structured, growing knowledge needs to live somewhere that both humans and agents reach. What changes between one use and the next is the visibility tier and the balance of writing between the two; the mechanics do not.
Where it fits
A fit is a shape of work, not an industry: knowledge that keeps growing, has structure worth keeping, and is read by a person and an agent in turn.
Personal notes
A second brain that an MCP-native agent reads selectively (get_outline → get_node) instead of holding the whole vault in context. Adding to notes is a chat message away, no app switch; reading them back is a tool call away, not a search bar. Closer to Obsidian-as-knowledge-store than to a flat note app or a single ever-growing scratchpad.
Team workspace
Project context, decisions, meeting digests, written by the team and refactored by the agent. The team's chat and the wiki feed each other: the agent reads back, rewrites, and proposes structural moves the human approves. Replaces Notion- and Confluence-shaped tools when an MCP-native API matters more than rich-block UX.
Public reference
Encyclopedias, guide sites, fan wikis, travel handbooks. Content meant for readers who arrive from search and never touch the editing surface. SEO ships ready out of the box: Open Graph, JSON-LD, sitemap, slugged URLs that survive renames. Closer to MediaWiki in spirit than to a docs-builder like GitBook.
AI memory / RAG replacement
Long-running project memory the agent writes and the human audits. The tree gives memory structure the agent navigates by outline instead of grepping a 50KB single file, and hierarchy plus full-text search across titles and bodies turns out to be enough for most agentic memory workloads, with no separate vector store. Closer to a navigable second brain than to a flat CLAUDE.md or a bolt-on vector store.
Where it doesn't
Wikilayer overlaps with adjacent tools without trying to be any of them. A comparison here names what the adjacent tool does that Wikilayer deliberately doesn't, so a user migrating in can spot up front what they'll have to give up.
vs Notion
Notion's killer features are its rich block editor (drag-and-drop, slash menu, embeds) and databases-as-content (filtered views, kanban, calendar, formula columns). Wikilayer has neither. Bodies are plain markdown edited through MCP, not click-to-edit blocks; the tree is hierarchical markdown nodes, not a relational document store. If your wiki is more "structured data with views" than "growing prose with structure", Notion fits better.
vs Google Docs
Google Docs is real-time multiplayer prose: live cursors, character-level collaborative typing, inline comments and suggestion threads. Wikilayer is single-writer-per-edit: each update_node / patch_node lands atomically through MCP, conflicts resolve at write time rather than by merging character streams. Discussion of a block happens in a chat tool, with the agreed outcome written back as an edit. If your team needs simultaneous editing or threaded comments on prose, Docs fits better.
vs Confluence and GitBook
Confluence and GitBook layer enterprise process on top of pages: per-page permissions, approval / review workflows, scheduled publishing, branch-and-merge models for drafts. Wikilayer has wiki-wide membership and no review queue: a role carries the same rights on every page, and a single page leaves the wiki only as a read-only share link. Edits land directly on the live tree; the audit trail is nodes_history, a snapshot of each node as it stood before the change, not a separate workflow. Mixed-sensitivity content goes in separate wikis. If your team needs sign-off chains or per-page ACLs, those tools fit better.