Skills, MCP, RAG, Memory Are Not Alternatives — IBM's Agent Context Explainer, Extended

IBM Technology’s nine-minute explainer is the cleanest sorting of agent context we have seen, and it is built around one worked example: a checkout page returning a 500. The framing is worth arguing with, but the taxonomy underneath it is worth memorising.

The taxonomy

The video opens by dismissing the instinct most teams start with — collect everything, put it in the context window, hope:

“That can be quite an ineffective means to resolve an error like this, because there’s plenty of scope for this AI agent to kind of get lost or to go down dead ends or just act in a generalized way that doesn’t really represent how this specific checkout page actually works.”

Instead, four mechanisms, sorted by where the knowledge comes from. The closing rule of thumb is the sharpest thirty seconds in the video:

“If it’s knowledge that somebody has written down, that’s RAG. If it’s knowledge the agent’s picked up from experience, that’s memory. If it’s a procedure to follow, something repeatable, that is an agent skill. And if an agent needs to go and actually look something up in the world without using proprietary code, that can be MCP.”

Mechanism	Supplies	In the 500 example
Skill	A procedure, plus judgment on when to stop	The triage runbook: check error rate, then recent deploys, then escalate
MCP	Reach into live systems	Actually querying the logging stack to read that error rate
RAG	Curated documents, retrieved on demand	The dependency map for this service
Memory	What happened last time	The real cause the runbook never documented

The framing is wrong, and the video’s own example shows it

The video is titled as a versus and opens by promising to “define which methods are best in different situations.” But follow the worked example to the end and it needs every one of them. The skill knows to check the error rate but cannot reach the dashboard. MCP reaches the dashboard but has no idea what normal looks like for this service. RAG supplies the dependency map but does not know that the last occurrence had an undocumented cause. Memory supplies that, and nothing else does.

Four mechanisms, one incident, all required. Not a choice.

The axis the video leaves out: who owns staleness

Each mechanism fails differently, and the failure modes are what decide the architecture in practice.

Skills go stale silently. A runbook encodes a procedure that was correct when someone wrote it. When the deploy process changes, the skill keeps confidently instructing the agent to check a thing that no longer exists. Owner: whoever owns the process. Detection: none, unless you test skills the way you test code.

MCP fails loudly, which is the good case. Auth expires, a scope is missing, a rate limit hits. These surface as errors rather than as bad answers. The real MCP risk is not staleness but reach — a local server runs with your user’s permissions and can touch more than the one system you wired it up for. That is a security question rather than a knowledge question, and it is worth reading separately.

RAG retrieves confidently wrong chunks. Semantic search returns the nearest thing, not the right thing, and an empty corpus and a wrong corpus look identical from the agent’s side. Owner: whoever curates the document set. This is at least a human-owned artifact — someone put those documents there on purpose.

Memory has no owner, and that is the whole problem. The video is explicit that memory is self-written:

“When this pesky 500 error is finally fixed, then the memory can also write back what the fix actually was. So the agent has that for next time.”

Read that again with a failure in mind. If the fix was wrong, or coincidental — the error stopped because traffic dropped, not because the change worked — the agent has now durably recorded a false causal story and will apply it next time with more confidence than the first time. RAG is curated by a person. Memory is curated by the thing that might be mistaken.

That asymmetry is the single most important line in this taxonomy and the video does not draw it. Memory is the only one of the four where the writer, the reader, and the reviewer are the same entity.

What this means for how you build

Start from the knowledge, not the mechanism.

• Does it change when a human changes a process? Skill. Version it, review it in a pull request, and treat a stale skill as a bug.
• Does it live in a system with an API? MCP. Never copy it into a prompt — copied state is stale state.
• Was it written down deliberately by someone whose job that is? RAG.
• Did the agent conclude it on its own? Memory — and it needs a review path before it gets treated as fact. At minimum, record what the agent believes it learned separately from what a human has confirmed, and never let unconfirmed memory outrank a curated document.

The nine minutes are worth watching for the taxonomy alone. Just do not take the “versus” in the title literally: in any incident big enough to want an agent for, you will be running all four, and the interesting engineering is in deciding which one wins when they disagree.