Why "just add more context" isn't a strategy — and what these four building blocks are really for
Every language model, on its own, only knows what was in its training data. It has no access to your company's HR system, no memory of yesterday's debugging session, and no idea how your team likes a 500 error triaged. Four mechanisms have emerged as the standard ways engineers close that gap — Retrieval-Augmented Generation, the Model Context Protocol, Agent Skills, and agent memory — and they're not interchangeable. Each answers a different question.
RAG: Retrieval-Augmented Generation — knowledge someone wrote down
RAG's job is to ground a model's answer in documents it wasn't trained on — a policy handbook, a manual, a knowledge base — by pulling in the relevant passage before the model generates a response, rather than hoping the fact is buried somewhere in its parameters.
The technique traces back to a 2020 paper out of Facebook AI Research, UCL, and NYU, which combined a pre-trained sequence-to-sequence model with a dense vector index of retrievable documents, treating retrieval as a differentiable step rather than a separate lookup bolted onto generation. The paper compared two formulations — one conditioning on the same retrieved passages across a whole generated sequence, the other using different passages per token — and found RAG models generated more specific, diverse, and factual language than a purely parametric baseline.
In practice, RAG runs a five-step loop: a user asks a question, the system converts it into a search query and retrieves matching passages (usually via semantic/vector search), those passages get returned, they're stitched into an augmented prompt alongside the original question, and the model generates a grounded answer — ideally with the source passage cited so the answer can be checked. This is the right tool when the knowledge in question is static and already written down somewhere: policy docs, runbooks, dependency maps, product manuals.
MCP: Model Context Protocol — knowledge (and action) that lives in a system
Where RAG is about knowing more, the Model Context Protocol is about doing more. MCP is a standardized client-server protocol that lets an agent connect to external systems — databases, SaaS tools, internal APIs — to read live data or actually take action, rather than searching through static documents.
Anthropic open-sourced MCP in November 2024, describing it as a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments, aimed at helping models produce better, more relevant responses. The workflow looks different from RAG's retrieval loop: the agent connects to an MCP server and discovers what tools are available, reads each tool's schema to understand its inputs and outputs, plans which tools to call and in what order, executes structured calls through the MCP runtime, and integrates the results back into its reasoning — potentially triggering more calls before finalizing an answer.
The distinction matters in practice: if you ask "how many vacation days do I have left," that's not sitting in a PDF anywhere — it's a live number in an HR system, and RAG can't fetch it. MCP can, because it's built to call tools and read (or write to) live systems, not just retrieve static text.
Agent Skills: procedural knowledge — knowing how to do a specific task
The newest of the four addresses something neither RAG nor MCP covers well: repeatable procedures and judgment calls. A skill is a folder containing a SKILL.md file with instructions, and optionally supporting scripts or reference files, that tells an agent how to carry out a specific kind of task — say, triaging a production error, or building a slide deck in a house style.
Anthropic introduced Agent Skills on October 16, 2025, and published it as an open standard for cross-platform portability on December 18, 2025, after which other coding tools began adopting the same SKILL.md format. The key design idea is progressive disclosure: at startup, an agent pre-loads only the name and description of every installed skill into its system prompt — enough to know when each skill is relevant without loading all of it into context — and only reads the full body of a skill's instructions once it decides that skill actually applies to the current task. This is why a skill can reference arbitrarily large supporting material (scripts, templates, longer docs) without bloating the context window by default — only the parts actually needed get pulled in, and only when needed.
Skills don't give an agent new reach, though. A skill can tell an agent "check the error rate, then check recent deployments," but the agent still needs some other mechanism — usually MCP — to actually read that error rate from a dashboard or logging system in the first place.
Memory: what the agent picks up on its own
Memory is the odd one out because, unlike the other three, it isn't knowledge someone deliberately curated for the agent — it's knowledge the agent accumulates itself, from its own past interactions. The most cited organizing framework for this comes from a Princeton research team, whose 2024 paper "Cognitive Architectures for Language Agents" (CoALA) organizes an agent's information storage into working memory and long-term memory, with the latter further divided into distinct categories, alongside a structured action space and a generalized decision-making loop. In applied form, that breaks into four types:
- Working memory — the live context window: the current conversation, loaded files, system instructions. Volatile; gone when the session ends.
-
Semantic memory — general facts, conventions, and documentation the agent should always have on hand, often implemented today as simple project-level markdown files (a
CLAUDE.mdat a repo root, for instance) rather than a vector database. - Procedural memory — how to do things; this is where Agent Skills technically lives, using the same progressive-disclosure pattern described above.
- Episodic memory — a distilled record of what happened in past sessions and what the agent learned from them, e.g., "last time this exact error occurred, the real cause wasn't in the runbook." This is the hardest to get right, because deciding what's worth keeping — and when it becomes stale — is a genuine engineering problem, not a solved one.
Not every agent needs all four. A simple reflex agent might only need working memory; a narrow support bot might add procedural memory for a specific skill; a general-purpose coding agent typically needs all four to actually improve over time rather than repeating the same mistakes every session.
Where the four overlap
A common source of confusion is that "semantic memory" and RAG can sound like the same thing — both are about facts written down somewhere. The practical difference is mechanism and scope: RAG is a retrieval pipeline pointed at a large, often external corpus, fetched on demand via search; the semantic-memory pattern in a coding agent is usually a small, fixed file loaded wholesale into every session, not searched. Similarly, "procedural memory" and "Agent Skills" aren't two different things — Skills is simply the concrete, shipped implementation of the procedural-memory concept CoALA described in the abstract two years earlier.
It's also worth being skeptical of any framing that treats these four as mutually exclusive choices. In real systems they compose: an MCP server can call out to a RAG pipeline as one of its tools when a user's question is better answered by document retrieval than by hitting a live system; a coding agent's skill can instruct it to use a specific MCP tool as one of its steps; and episodic memory can record which skill or MCP call actually solved a problem last time, so the agent doesn't have to rediscover it.
The takeaway
None of these four are competing paradigms — they're answers to four different questions an agent runs into constantly: what's written down, what's live, what's the procedure, and what have I learned. The real architecture question isn't "RAG or MCP" or "Skills or Memory" — it's recognizing which of the four a given task actually needs, and building the connective tissue (security, governance, context budgeting) to let them work together without drowning the model in irrelevant context.
Top comments (2)
The overlap between Skills and MCP is where things get messy in practice. If a skill defines the multi-step procedure while an MCP server exposes the low-level primitives, you avoid bloating the tool schema with specialized actions that are only needed for one workflow. Keeping the tools minimal and encoding the sequencing in markdown documentation usually scales much better than trying to make every capability a dedicated MCP endpoint.
Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support