People keep asking me what the difference is between PKM, RAG, wikis, and AI memory systems. I think they ask because everyone online talks about them like they're interchangeable. Like they all just mean "thing that stores information, I guess?"
I used to think this too. I built a RAG system on top of my personal Obsidian vault and wondered why it kept surfacing half-baked half-thoughts I had at 2 AM as if they were established facts. Spoiler: my sleeping brain's hot take about distributed systems is not documentation. The RAG pipeline had no way to know that.
So I spent a bunch of time untangling this mess. Here's what I wish someone had told me sooner.
The Short Answer
| System | Who It's For | What It Does | Best At | | --- | --- | --- | --- | | PKM | You alone | Helps you think better | Learning, connecting ideas, synthesis | | Wiki | A team or the public | Preserves shared knowledge | Docs, policies, reference material | | RAG | An AI system | Retrieves context at query time | Answering questions over your data | | AI Memory | An AI agent | Persists context across sessions | Long running tasks, personalization |
The mental model I keep coming back to: PKM and wikis structure knowledge. RAG retrieves knowledge. Memory systems evolve agent context.
Each one optimizes a different layer.
Why Everyone Gets Confused
It's easy to blur these lines because at a glance they all look like they do the same thing. Every one of them can store notes, retrieve information, answer questions, organize references, and connect ideas. The difference isn't in the feature list. It's in the intent.
I've seen wikis full of personal scratch notes. RAG systems pulling from a random pile of PDFs with no source of truth. Memory layers trying to act like databases. PKM tools drowning under automation plugins that turn them into a productivity tax instead of a thinking tool.
The problem is treating "knowledge" like one thing. It's not. Knowledge has layers: capture, structure, retrieval, interpretation, reuse, evolution. Each system optimizes a different slice of that stack. When you force one tool to handle every layer, you get a mess that performs no role well.
The Four Flavors of Knowledge System
1. PKM: Your Brain's Messy Desk
Personal Knowledge Management is the practice of capturing, connecting, and making sense of information for your own purposes. Tools like Obsidian, Logseq, Notion, or a folder full of Markdown files. Zettelkasten and second brain systems live here.
PKM is human driven. The goal is better thinking, not storage. A good PKM system is messy in a useful way. It supports unfinished thoughts, half-baked ideas, private context, and concepts that are still cooking.
It's the place where you write something dumb so you can later realize it's dumb and write something smarter.
PKM shines when you're learning a new domain from scratch, developing original ideas over weeks or months, connecting notes across time, writing articles or books, tracking personal research, or building what people call a "second brain."
Where it falls apart: when it becomes a dumping ground, a folder taxonomy project, a productivity aesthetic, or a tool optimization hobby that you spend more time configuring than using. The main risk is collection without synthesis. If you only save information, you don't have a knowledge system. You have a landfill that you curate.
Here's what I think: PKM should optimize for reuse, not capture. Capturing everything feels productive. It creates debt. The real value appears when notes get rewritten, compressed, connected, and turned into something you actually use.
2. Wiki: The Office Library That Someone Dusts Occasionally
A wiki is a structured knowledge base designed for shared reference. Think DokuWiki, MediaWiki, Confluence, BookStack, or a git based documentation site. It's more formal than PKM. It answers the question: "What do we know, and where's the current version?"
A wiki is a social contract. It says: "This page is the place where this knowledge lives." That makes ownership and maintenance critical. When that contract breaks, the wiki dies.
Wikis work well for team documentation, operational runbooks, product knowledge, policy documents, technical reference, onboarding material, and stable domain knowledge. Basically, anything that multiple people need to rely on without wondering if it's current.
But wikis go bad when they get stale. Common failure modes: no page owners, outdated screenshots, duplicate pages, unclear canonical versions, too much hierarchy, no maintenance rhythm. A wiki with old information is worse than no wiki at all, because it creates false confidence. People trust it, act on it, and break things.
I think a good wiki should be boring. That's a compliment. Ideas aren't born here. A wiki is where stable knowledge gets preserved after it has proven useful to other people.
3. RAG: The Librarian That Never Sleeps But Sometimes Hallucinates
Retrieval Augmented Generation is an AI architecture: retrieve relevant information from a set of documents, then give it to a language model so it can answer with actual context instead of guessing. The pipeline usually goes: documents, chunking, embeddings or search index, retrieval, optional reranking, prompt assembly, generation.
RAG is machine driven. The goal is to give a model relevant context at query time so it stops inventing things, not to create knowledge of its own.
Good for: question answering over documents, internal search assistants, support bots, technical documentation assistants, compliance lookup, and research over large collections. Especially when the model shouldn't or can't memorize the data.
It breaks when teams treat it as magic search. Common problems: bad chunking, weak retrieval, noisy context, missing metadata, no source of truth, stale documents, weak evaluation, no human feedback loop. RAG doesn't fix bad knowledge management. If the underlying content is fragmented, outdated, or contradictory, the RAG system will surface that mess with total confidence. It'll politely tell you something wrong and cite a source that's also wrong, and you'll have no idea.
The way I see it: RAG is a retrieval strategy, not a knowledge strategy. It helps machines access knowledge, but it doesn't decide what knowledge is valid, maintained, canonical, or useful. That's still a human problem.
4. AI Memory: The Elephant That Does Not Forget (And That's a Problem)
AI memory systems give agents persistent context beyond a single prompt or conversation. They store user preferences, past decisions, long term facts, task history, summaries, reflections, extracted entities. Think MemGPT style memory tiers, episodic memory, semantic memory, vector memory, profile memory.
AI memory is agent driven. The goal is continuity. Memory matters when the system has to behave like it remembers you.
Useful for: personal assistants, long running coding agents, research agents that work across sessions, customer support agents, tutoring systems, workflow automation, persistent companions, multi-session task execution.
Memory gets dangerous when it grows unchecked. Common problems: remembering wrong facts, storing too much irrelevant noise, privacy risk, stale preferences, poor memory ranking, memory poisoning, no forgetting mechanism, confusing memory with truth. A system that remembers everything isn't smart. It's a hoarder.
A memory system needs governance. What should be remembered? Who approved it? How long should it live? When should it be forgotten? How is it corrected? These questions matter more than the retrieval mechanism.
Here's what I've come to believe: AI memory is more than long context. Long context lets a model see more at once. Memory decides what survives across time. Those are different problems, and they require different solutions.
The Big Picture: Structure vs. Retrieval vs. Evolution
The simplest way to understand how these differ is to compare what they optimize for.
PKM optimizes personal evolution. It's about how your understanding changes over time. You collect material, rewrite it, connect it, turn it into something useful. The output is a better mental model, an article, a decision, a reusable insight. PKM is about long term sensemaking, not fast lookup.
Wikis optimize shared structure. They're about stable knowledge that multiple people can rely on. They ask: what's the current answer? Who owns it? Where should people go? What needs updating? A wiki works when people trust it.
RAG optimizes machine retrieval. It's about pulling the right context at the right time. What documents are relevant? Which chunks should the model see? How much context fits in the window? What should the model cite? RAG works when retrieval quality is high and the source corpus is trustworthy.
AI memory optimizes continuity. It's about persistence across sessions. What should the agent remember? What should it forget? Which memory matters right now? How should memory change behavior? Memory works when it improves future behavior without polluting the agent with stale or incorrect context.
When to Use What (A Decision Guide)
If the knowledge is private and evolving: PKM. This is for things you're still figuring out. It should be rough, messy, and yours.
If the knowledge is shared and stable: A wiki. Once you know the answer and other people need it, write it down somewhere they can find it.
If an AI needs to answer from external documents: RAG. When the model needs facts it doesn't have in its weights, give it a retrieval pipeline.
If an agent needs continuity over time: Memory. When the system has to act like it remembers past conversations, use persistent context.
If you need all four: Build a layered system. Don't force one tool to do every job. That path leads to tears.
How These Systems Actually Combine
The most useful setups are hybrids. A mature knowledge architecture has each layer doing its job and handing off to the next.
Pattern 1: PKM to Wiki (the human knowledge pipeline)
Capture notes privately. Connect ideas. Distill insights. Publish the stable version. Maintain as shared reference. This is how personal research becomes organizational knowledge. I research distributed systems in my notes, figure out what works, and then write the deployment guide in the team wiki. PKM created the insight. The wiki preserves the result.
Pattern 2: Wiki to RAG (the machine access pipeline)
Maintain canonical wiki pages. Index them. Retrieve relevant sections. Generate grounded answers. Link back to sources. This is one of the cleanest RAG patterns. The wiki stays the source of truth. RAG becomes the access layer. A support bot answers questions from the product wiki. It should cite and route users back to the canonical page, not replace it.
Pattern 3: RAG plus Memory (the agent continuity pipeline)
RAG retrieves external facts. Memory stores user or task context. The agent combines both. Future behavior improves. RAG answers: what does the knowledge base say? Memory answers: what matters about this user or project? A coding agent uses RAG to retrieve framework docs and memory to remember that your project avoids ORMs and prefers raw SQL. Those are different knowledge types and both matter.
Pattern 4: PKM plus AI Assistant (the hybrid thinking pipeline)
Human captures notes. AI summarizes and suggests links. Human edits and validates. Knowledge becomes more structured. Some pages graduate to wiki or publication. The AI augments the system but doesn't own the truth. It can suggest connections between ideas about RAG, memory, and LLM systems. But I decide which connections are meaningful.
Mistakes I've Made (So You Don't Have To)
Treating RAG as a wiki. RAG isn't a knowledge base. It doesn't automatically create canonical structure. It retrieves from whatever exists. If the source documents are bad, RAG becomes a confident interface to bad knowledge. I learned this the hard way by pointing a RAG pipeline at two years of blog drafts and getting very confident, very wrong answers about my own opinions.
Treating memory as a database. AI memory is selective context, not general storage. A database stores records. Memory changes behavior. If you need exact facts, use a database or knowledge base. If you need continuity, use memory. Don't put your tax records in an agent memory system.
Treating PKM as documentation. Private notes should be messy. Documentation shouldn't. If every early thought has to become a polished page, you stop writing. I've killed my own note taking habit twice by over-organizing too early. Use PKM for rough thinking. Use wikis for durable knowledge.
Treating long context as memory. Long context helps while the context is present. Memory persists, selects, updates, and sometimes forgets. They solve different problems. Giving a model a 200K token window isn't the same as building it a memory system.
The Layered Architecture You Actually Want
If you step back, these four systems form a natural spectrum from human thinking to AI continuity:
| Layer | System | Role | | --- | --- | --- | | Human thought | PKM | Explore and synthesize | | Shared structure | Wiki | Preserve and maintain | | Machine access | RAG | Retrieve and generate | | Agent continuity | Memory | Persist and adapt |
The direction matters. Knowledge starts as personal thought, becomes shared structure, gets indexed for machine retrieval, and eventually feeds into persistent agent behavior. That's the modern knowledge stack.
Don't skip layers. Don't merge them. A RAG system without a maintained wiki is answering questions from noise. A PKM system trying to function as an agent memory store is a note taking app with delusions of grandeur. A wiki trying to do PKM is a documentation site full of half-finished thoughts.
Each layer has a job. Let it do that job.
Security and Governance Notes
Knowledge systems get risky when they store sensitive or stale information without oversight.
For PKM: know what should stay private, what should get published, and what should be deleted. Not everything belongs in a shared system.
For wikis: assign owners, review dates, and canonical paths. An unowned page is an abandoned page.
For RAG: track which sources are indexed, verify answers are cited, evaluate retrieval quality, and exclude content that shouldn't be surfaced.
For memory: this needs the strictest governance because it silently influences future behavior. Users should be able to inspect, delete, and correct what the system remembers about them. A memory system without a forgetting mechanism is surveillance, not assistance.
What I Keep Coming Back To
PKM, RAG, wikis, and AI memory systems each answer a different question.
PKM asks: how do I think better over time?
A wiki asks: what do we know, and where's the trusted version?
RAG asks: what external context should the model use right now?
AI memory asks: what should this agent remember for the future?
Once you separate those questions, the architecture choices become obvious. Use PKM for thinking. Use wikis for shared truth. Use RAG for retrieval. Use memory for continuity.
The future isn't one knowledge system that replaces all others. It's a layered stack where each layer handles the job it was built for. And the human stays in the loop, deciding what matters.