RAG, Skills, and Tools: Three Ways to Get Information Into Context
Retrieval, packaged skills, and tool calls all solve the same problem — getting the right information in front of the model at the right moment — but they trade off very differently.
Ask three different teams how they get external information into an agent's context, and you'll get three different answers delivered with equal confidence: "we do RAG," "we built a skill library," "we exposed it as a tool." Frame it as a single architectural choice — pick one — and you'll end up over-committing to whichever mechanism your team happened to reach for first, then bolting the other two on later as patches instead of designing for all three from the start.
That framing is the mistake. Retrieval, skills, and tools aren't competing answers to the same question — they're three different mechanisms with different cost structures, and a well-built agent uses all three, deliberately, for different jobs. Understanding what each one is actually good at is a context-engineering decision, not an implementation detail.
Retrieval: pulling information in, per call
RAG's job is narrow and specific: given a query, find the most relevant chunks of a large corpus and insert them into context for this one call. It's the right mechanism when the universe of possible information is too large to ever load in full — a knowledge base, a document archive, a codebase — and what's relevant changes call to call.
The cost structure is retrieval quality plus context dilution. Get the query-to-chunk matching wrong and the model either doesn't get what it needs or gets it buried among irrelevant near-misses, which — per the same attention-budget mechanics that govern every other piece of context — actively degrades the model's ability to use the chunk that did land correctly. RAG systems that return ten chunks "for safety" are trading recall for precision in a way that often nets negative, because the model now has to disambiguate the useful chunk from nine distractors while the useful chunk was already there.
RAG's strength is scale: it's the only one of the three mechanisms that works when the underlying information source is too large to ever be resident in context. Its weakness is that it's probabilistic — a similarity search, not a lookup — so it will always occasionally return the wrong thing with high confidence.
Skills: packaged, structured expertise loaded on demand
A skill — in the SKILL.md sense that's become common across agent frameworks in 2025 and 2026 — is different from both retrieval and a tool call. It's a self-contained bundle of instructions, examples, and sometimes reference material that teaches the agent how to do a specific kind of task well, and it's loaded into context only when relevant, not by default.
This is the mechanism for expertise that's too structured for a similarity search and too complex for a single tool description. A skill can encode a multi-step process, house-style conventions, edge cases to watch for, and example outputs — the kind of tacit knowledge a senior practitioner would explain to a junior one, packaged so the agent can retrieve and apply it without that knowledge permanently occupying context on every call it doesn't need.
The key design property is progressive disclosure: the agent sees a one-line description of what the skill does at all times, and only loads the full instructions when the task actually calls for it. That's a direct application of the budget principle — the cost of having a hundred skills available is roughly one line each, not the full weight of all hundred, because only the relevant one gets expanded into context on any given call.
Skills are the right mechanism for "how to do this well," not "what is this fact." That distinction matters more than it sounds — teams that try to cram procedural knowledge into a RAG corpus end up retrieving fragments of a process out of order, and teams that try to cram factual lookups into a skill end up hardcoding data that goes stale.
Tools: acting on the world, and pulling live data
A tool call is the mechanism for anything that requires touching a live system — querying a database for the current state of something, calling an API, executing code, sending a message. Where RAG and skills are both, in different ways, about surfacing static or semi-static knowledge, a tool is how the agent gets current information or takes an action that has an effect outside the conversation.
Tools have the sharpest cost curve of the three, and it's not subtle: every tool registered with an agent is described in context on every call, whether or not it's used, and model accuracy at picking the correct tool degrades measurably as the toolset grows — noticeably past around ten tools, and OpenAI's own guidance caps recommended toolsets at fewer than twenty for exactly this reason. Unlike RAG chunks or skill summaries, tool schemas usually can't be made one-line-cheap; the model needs enough of the schema to construct a valid call, which means each tool's baseline cost is higher per addition than either of the other two mechanisms.
This is also where MCP — the Model Context Protocol Anthropic released in November 2024, now stewarded by the vendor-neutral Agentic AI Foundation under the Linux Foundation after being donated there in December 2025 — matters as infrastructure rather than as a buzzword. MCP standardizes how an agent discovers and calls tools across different servers, which means the tool-taxonomy problem doesn't have to be solved from scratch for every integration. It doesn't solve the tool-count problem — you can still expose forty tools over MCP and pay the same accuracy cost — but it removes the plumbing tax that used to make careful tool curation harder than it needed to be.
Where teams actually get the mapping wrong
The most common mistake isn't picking the wrong mechanism outright — it's defaulting to whichever one the team already has infrastructure for, regardless of fit. A team that built a strong RAG pipeline first tends to keep routing new context needs through retrieval even once those needs are really procedural knowledge that would be served better as a skill, because standing up a new mechanism feels like more work than extending the one that already exists. A team that started with tools tends to over-index on turning everything into a function call, including static reference material that never changes and didn't need a live lookup in the first place. Neither mistake is visible immediately — it shows up gradually, as retrieval quality degrades on procedural queries it was never well-suited for, or as the toolset creeps toward the point where tool-selection accuracy starts sliding.
The fix isn't picking a different default. It's asking, for each new piece of context a task needs, three questions in order: does this need to be current or does it change rarely (tool vs. the other two); is this a fact to surface or a process to follow (retrieval vs. skill); and does the volume of source material exceed what could reasonably live in a loaded skill file (retrieval vs. skill again, from the other direction). Answered honestly, most context needs sort themselves — the friction comes from skipping the questions and reaching for whatever's already built.
Choosing between them isn't really a choice
In practice these three mechanisms answer different questions, and a well-designed agent routes each kind of context need to the mechanism built for it: "what does our documentation say about X" goes to retrieval; "how do we structure a customer escalation email" goes to a skill; "what's this customer's current account balance" goes to a tool. Trying to force one mechanism to do all three jobs is where the failures cluster — a tool that returns a wall of static reference text instead of live data, a RAG corpus doing double duty as a procedure manual, a skill file trying to encode information that changes hourly.
The teams getting this right in 2026 aren't the ones who picked the "best" mechanism. They're the ones who mapped each category of information their agent needs against the mechanism actually built to deliver it — and who keep re-auditing that map as the agent's responsibilities grow, because it's easy to bolt a new capability onto whichever mechanism is closest at hand instead of the one that's actually right for it.
Part of the "Context Engineering" series on aiskill.market.