Skills, MCP, RAG, and Memory: Four Ways to Give an AI Agent Knowledge — and How to Choose Between Them

A pragmatic architecture guide for Senior Architects designing production agentic systems.

The problem with stuffing the context window

Picture a familiar scenario. A checkout page in your web application is returning a 500. An on-call engineer wants an AI agent to help triage it. The instinctive move is to hand the agent everything it might need — runbooks, dashboard exports, recent deployment logs, a slice of customer history — and let it reason its way to a fix.

That instinct tends to produce poor outcomes, for reasons worth stating plainly. A bloated prompt is expensive, it degrades model performance through the well-documented “lost in the middle” effect, and it invites the agent to generalise across your systems rather than reason precisely about the one that is broken. The agent does not need everything. It needs the right thing, at the right layer, at the right time.

Four architectural patterns have emerged to solve this properly: Agent Skills, Model Context Protocol (MCP), Retrieval-Augmented Generation (RAG), and Agent Memory. They are frequently discussed as if they were competing choices. They are not. They address orthogonal concerns, and most serious production systems compose them.

This article breaks down what each one actually does, where it belongs in an architecture, and — more importantly — where teams routinely misapply them.

The four mechanisms at a glance

Each mechanism answers a different question about how an agent acquires knowledge outside its weights:

Mechanism	Answers the question	Knowledge source	Loaded when
Agent Skills	How should the agent perform a repeatable task?	Human-authored procedure files	On demand, progressively
MCP	What can the agent reach in the outside world?	Live external systems (APIs, DBs, files)	At tool invocation time
RAG	What does our documentation say about this?	Curated document corpus (vector store)	At query time, per request
Memory	What have we learned from prior interactions?	Agent’s own accumulated experience	On demand, per user/session/task

The rest of the article elaborates on that table and identifies where each pattern breaks down in practice.

Agent Skills: encoding procedure

An Agent Skill is a folder of instructions — at minimum a SKILL.md file with YAML frontmatter, and optionally supporting scripts, templates, or reference documents — that teaches the agent how to perform a specific class of task.

Anthropic released the format as an open standard in late 2025, and it was adopted shortly thereafter across other major agent platforms, including OpenAI, Google, GitHub, and Cursor. The reason for that convergence is not the file format itself (a markdown file with a metadata header is nothing new); it is the loading pattern the format enables, which Anthropic named progressive disclosure.

Progressive disclosure works in three tiers:

Tier	What loads	When
Discovery	Skill name + one-line description from YAML frontmatter	At session start
Activation	Full `SKILL.md` body	When the task matches the description
Execution	Referenced files, scripts, templates	Only when the instructions call them

The architectural point is that you can install a large library of skills without paying their full token cost upfront. The agent carries only a lightweight index until a task actually matches.

For the checkout error scenario, a checkout-triage skill might encode a runbook such as: “First check the error rate on the checkout service dashboard. If elevated, correlate with deployments in the last four hours. If a deployment matches, escalate to the owning team rather than attempting rollback.” Crucially, a good skill carries judgment as well as steps — including the boundary at which the agent should stop acting autonomously and hand off to a human.

Where skills fit — and where they don’t. A skill is the right answer when there is a repeatable procedure your team already knows how to do, and you keep re-explaining it to the agent. It is the wrong answer when the “procedure” is really just a knowledge lookup (that is RAG) or when the agent needs live data to make its next decision (that is MCP). A common failure mode is to jam factual reference material into a skill body; you pay for it in context every time the skill activates, and you cannot version or govern it the way you would a proper knowledge base.

MCP: connecting the agent to the world

A skill can tell the agent to check the error rate. It cannot tell the agent how to reach the observability stack that holds it. That is the job of the Model Context Protocol.

MCP is an open, JSON-RPC-based protocol that standardises how AI applications discover and invoke external tools, data sources, and prompts. The architecture has three participants, and the terminology is worth getting right:

Component	Role
Host	The AI application itself (a desktop chat app, an IDE, a bespoke agent runtime). Coordinates security, consent, and the LLM.
Client	A component inside the host that maintains one dedicated session with one server. A host runs one client per connected server.
Server	A program exposing capabilities to the model, via three primitives: Tools (functions the model can call), Resources (data the model can read), and Prompts (reusable templates).

The value proposition is the collapse of the N×M integration problem into N+M. Concretely: without MCP, connecting four AI applications to five backend systems is twenty bespoke integrations, each written on both sides. With MCP, it is four client implementations plus five server implementations — nine components, each written once.

For our checkout error, MCP is what turns the skill’s instruction “check the error rate” into an actual call:

An MCP server in front of your logging stack exposes a query_logs tool.
An MCP server in front of your metrics platform exposes a get_metric tool and a service_health resource.
An MCP server in front of your deployment system exposes a list_recent_deployments tool.

The agent, guided by the skill, invokes these through its MCP clients. It never needs to know that your metrics live in Prometheus and your logs in an Elastic cluster — the servers hide that.

Where MCP fits — and where it doesn’t. MCP is the right answer when the agent needs to act on live systems or read live state. It is the wrong answer when what you actually need is grounded retrieval over a static corpus (RAG) or a set of instructions on how to reason about a task (a skill). It is also, in practice, a quality problem: the ecosystem is young, and individual server implementations vary widely in quality. Treat every MCP server as untrusted code with production access, because that is what it is. In concrete terms: pin versions, review the exposed tool surface, scope credentials narrowly to the operations the agent actually needs, and log every call for later audit.

RAG: retrieving curated knowledge

Retrieval-Augmented Generation is the pattern for grounding an agent’s answers in a curated document corpus that a human has deliberately maintained.

The mechanics are well-understood: documents are chunked, embedded, and stored in a vector index. At query time, the user’s question (or a rewritten form of it) is embedded and used to retrieve the top-K semantically similar chunks. Those chunks are then injected into the agent’s context alongside the query, so the model can generate an answer grounded in real content.

For the checkout error, RAG might be pointed at your internal engineering wiki — service ownership maps, dependency diagrams, architectural decision records, past post-mortems. When the agent has narrowed the problem to a specific service and needs to understand its dependencies, it queries the RAG store and pulls in the relevant sections.

The key architectural properties of RAG:

Stateless retrieval. Every query is independent. The store does not know who is asking, or that the same user asked something related two turns ago.
Human-curated corpus. Content is put in deliberately, by a person or a documented ingestion pipeline, and its provenance is traceable.
Read-only by design. The agent does not typically write back into the RAG store — that is a separate governance workflow.

Where RAG fits — and where it doesn’t. RAG is the right answer for “what does our documentation say about X?” questions where the corpus is stable enough to be indexed and the answer is essentially a lookup with reasoning on top. It is the wrong answer when the information changes second-by-second (use MCP against the live system instead), when the “knowledge” is really user- or session-specific state (use memory), or when the question is procedural rather than factual (use a skill).

A common architectural mistake is to reach for RAG by default and then bolt everything else on. Teams end up with reranker chains, hybrid keyword-plus-vector pipelines, and query rewriters trying to compensate for the fact that half of what they stored is user context, not reference material. The fix is upstream: sort the knowledge by where it belongs.

Memory: accumulating experience

Agent Memory superficially resembles RAG — the agent looks up relevant knowledge on demand — but the source is fundamentally different. RAG retrieves from documents a human wrote. Memory retrieves from experience the agent itself accumulated.

The lifecycle of a memory system typically involves:

Observe the interaction (conversation, task, outcome).
Extract structured facts or summaries from it.
Consolidate those facts into typed, deduplicated entries with provenance and confidence.
Retrieve the relevant entries at the next relevant task.
Age out entries that are stale, superseded, or no longer relevant.

For the checkout error, memory is where the agent recalls that last month, the same 500 was ultimately caused by a stale certificate in the payment provider integration, not by anything in the runbook. When the fix is confirmed, the agent writes back the resolution so that next time the same symptom appears, the fix is a memory lookup away.

The distinction from RAG matters at the architectural level:

Dimension	RAG	Memory
Origin of content	Written by a human, ingested deliberately	Written by the agent from lived experience
Write path	Rare, out-of-band ingestion pipeline	Continuous, part of the agent’s runtime loop
Scope	Global corpus, same for all users	Often scoped by user, project, or agent
Governance	Document lifecycle, ACLs on the corpus	Fact-level provenance, right to erasure, decay
Failure mode	Retrieves outdated documents	Reinforces its own past mistakes

That last row is the one architects most often underestimate. A memory system with no consolidation, decay, or contradiction handling will happily learn the wrong thing and confidently repeat it. Worse, once “the thing that knows about the user” is a derived artefact rather than a raw log, GDPR Article 17 obligations (right to erasure) and audit requirements become materially harder to satisfy. Where regulated use cases apply, memory is where much of the compliance surface will live — design the governance in from day one rather than retrofitting it later.

Where memory fits — and where it doesn’t. Memory is the right answer when the agent’s value depends on continuity — recognising a returning user, remembering how you like your reports formatted, learning that a particular error has a non-obvious root cause. It is the wrong answer for shared reference knowledge (that belongs in RAG) or for one-shot lookups against live systems (MCP).

Composing the four: the checkout error, end to end

None of these patterns is sufficient on its own for a production agent. Here is how they compose for the running example:

The agent’s context contains the name and description of a checkout-triage skill at the Discovery tier.
When the on-call user says “the checkout page is 500ing,” the description matches, and the full skill activates. The agent now has the runbook and the judgment rules.
The skill instructs the agent to check the error rate. It invokes an MCP tool against the metrics server; the response comes back showing a spike beginning eleven minutes ago.
Correlating deployments: another MCP call to the deployment platform lists two changes in the window.
The agent queries the RAG store for the service dependency map to understand blast radius, and to see whether any of the changed services are on the critical path.
The agent queries memory to check whether this exact symptom-plus-service combination has been seen before. It has: a stale JWT signing key was the culprit two months ago.
The agent proposes a hypothesis, hands off to the human per the skill’s escalation rule, and — once the fix is confirmed — writes back the new resolution into memory.

Every mechanism did its job. None did another’s.

A realistic version of this walkthrough would also include at least one layer returning the wrong thing: a stale memory, an outdated RAG chunk, an MCP server that times out. Composition does not eliminate those failures; it localises them. The skill’s judgment rules are what keep a single bad retrieval from derailing the whole triage, which is another argument for building the skill layer deliberately rather than treating it as optional glue.

A pragmatic decision framework

For architects choosing between (or, more commonly, sequencing) these four, the following rules of thumb hold up in practice:

The question in front of you	The right primary mechanism
“Is there a repeatable procedure I keep re-explaining to the agent?”	Skill
“Does the agent need to do something, or read live state, in another system?”	MCP
“Is the answer already written down somewhere a human maintains?”	RAG
“Does the value come from remembering something the agent learned itself?”	Memory
“Is my prompt getting long and I don’t know why?”	You have probably conflated two of the above. Split them.

It is also worth naming what these four are not competing with. Fine-tuning bakes knowledge into weights and is the right answer when behaviour must be consistent, latency-sensitive, and does not change often. A long context window can carry a surprising amount of state without any of these mechanisms, and for a one-shot task against a self-contained document, that is often the simplest architecture. A classical rules engine still beats an agent for decisions that are deterministic, auditable, and well-specified. The four mechanisms in this article are the right tools when the problem genuinely calls for an agent; they are not the right tools when it does not.

And a few honest cautions that get less airtime than they deserve:

Agentic pipelines are more expensive than single-shot RAG. Each reasoning step is a separate model call; a multi-step triage can easily cost several times a direct lookup, and latency goes up accordingly. If the task is really “answer a question from documents,” an agent architecture is often the wrong shape.
MCP quality is variable. The protocol is sound; individual server implementations are not. Vet them the way you would vet any third-party dependency with production credentials.
Progressive disclosure has a discovery tax. With a large installed skill set, the aggregate Discovery-tier footprint is no longer trivial, and skill descriptions start competing for the model’s attention. Curate the installed set the way you curate a plugin ecosystem, not the way you curate a documentation portal.
Memory is a governance surface, not a feature. Design in decay, contradiction handling, provenance, and erasure from day one, or plan to rewrite it under compliance pressure later.

Closing thought

The temptation to solve “the agent needs more context” by stuffing more into the prompt is architecturally the same mistake as solving “the microservice needs more data” by widening its API. In both cases, the right response is the same: separate the information by where it belongs and let each layer do its job. A wider API hides a missing boundary; a bloated prompt hides a missing architecture.

Skills carry procedure. MCP carries reach. RAG carries curated knowledge. Memory carries experience.

Get those boundaries right, and the agent stops feeling like a stochastic oracle and starts feeling like a well-designed system.

MaheshNotes