> [Maxim](https://wikilayer.org/smee-again) / [Wikilayer authoring guide](https://wikilayer.org/smee-again/wikilayer-howto) / Use cases

# Use cases

**Contents:**

- [Where it fits](#where-it-fits)
  - [Personal notes](#personal-notes)
  - [Team workspace](#team-workspace)
  - [Public reference](#public-reference)
  - [AI memory / RAG replacement](#ai-memory-rag-replacement)
- [Where it doesn't](#where-it-doesnt)
  - [vs Notion](#vs-notion)
  - [vs Google Docs](#vs-google-docs)
  - [vs Confluence and GitBook](#vs-confluence-and-gitbook)

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](page:4409)-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](page:4409)-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](page:4402) edited through [MCP](page:4409), 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](page:4409), 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.