Wikilayer fits where structured, growing knowledge needs to live somewhere that both humans and agents reach. The same engine carries personal notes, team workspaces, public references, and AI memory; visibility tier and writing balance differ, the mechanics don't.
Where it fits
Wikilayer fits four shapes of structured, growing knowledge that humans and agents both touch. Each below names what it replaces and what makes Wikilayer a fit.
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. Replaces flat CLAUDE.md files that grow into unreadable piles; the tree gives memory structure the agent navigates by outline instead of grepping a 50KB single file. No separate vector store needed: hierarchy plus full-text search across titles and bodies turns out to be enough for most agentic memory workloads.
Where it doesn't
Wikilayer overlaps with three families of adjacent tools without trying to be any of them. Each comparison below 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-level visibility only and no review queue. Edits land directly on the live tree; the audit trail is nodes_history (one before-snapshot per 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.