Is Claude Code's On-Demand Loading of Skills/Tools a Form of RAG? Unpacking Agentic Retrieval

Ever noticed something about Claude Code? It brags about having dozens of skills and hundreds of tools — but if you peek at what's actually loaded into the model's context at the start, almost none of them are there. They show up only when they're needed. On demand. So today I want to pull apart how that mechanism works, and answer a question that genuinely tripped me up when I first ran into it: is this just RAG in disguise?

Here's the short version. In spirit? Absolutely, yes. But the thing doing the retrieving isn't a vector database — it's the language model itself. Let me walk you through why.

Start with the root problem, which is brutally simple: context is a scarce resource. Agent systems keep piling on tools and instructions, but the context window is both limited and expensive. Let's put numbers on it. Say a skill's full instructions run about 800 tokens, and a single tool's schema — its parameter definitions — runs about 300. Now imagine you preload everything: sixty skills, fifty tools. You're looking at roughly 63,000 tokens burned before the conversation has even started. Before the user has typed a single word.

Now compare that to lazy loading. You hand the model a lightweight index — about 2,000 tokens — plus whatever it actually ends up using, maybe another 2,500. Call it 4,500 tokens total. That's more than a ten-x difference. And there's a second, sneakier cost to preloading: it wrecks your prompt cache. The moment the set of skills in play changes, the leading content of your prompt shifts, and the cache invalidates.

So the smart move isn't "give the model everything." It's two tiers: hand over a lightweight index first, and only expand the heavyweight full definition when it's genuinely needed. That's lazy loading in a nutshell.

Now, Claude Code actually does this in two flavors, same strategy, slightly different plumbing. The first is what's called deferred tools — these are callable functions, things like WebFetch or a Notion API. The second is skills — bundles of workflow instructions, like a "turn this into a post" command. The difference is in what lives in the index and how you expand it. For deferred tools, the index holds literally just the name. To expand it, the model calls a tool-search function to pull down the full schema, and then it can actually call the thing. For skills, the index holds the name plus a one-line description, and to expand you invoke the skill, which injects its full prompt into the conversation.

Let me make the deferred tools flow concrete. At the start of a session, the model gets a list that's essentially just names — WebFetch, WebSearch, the Notion search tool, about fifty of them — with an explicit note: these schemas are NOT loaded, and if you try to call them directly, you'll get an error. So at that moment, "WebFetch" is just a string. The model has no idea what parameters it takes or what it returns. The flow goes: user makes a request, the model reasons "ah, I need WebFetch," it calls the search function to fetch WebFetch's full schema, now it knows the parameters, and only then does it actually call WebFetch and get its result. The beautiful part is step three. Those fifty schemas might add up to tens of thousands of tokens collectively — but the model only ever pays for the one it actually needs. The other forty-nine just sit there as names, costing essentially nothing.

The skills flow is the same idea. Each line in the skills index is just a name and a description — "post: convert a conversation or notes into a structured post," that kind of thing. Behind "post" there might be hundreds of lines of instructions: how to categorize, how to fill in the frontmatter, article templates, commit formats. But none of that is in context until the user actually says "turn this into an article," the model matches that intent against the description, and runs the skill. Only at that instant do the full instructions get injected. Before that moment, the model knows nothing about the details.

Okay — so back to the core question. Is this RAG?

A lot of people hear "RAG" and immediately think "embeddings plus a vector database." But that's just one implementation of retrieval. Strip RAG down to its bones and it's two moves: retrieval, then augmentation — meaning you inject the retrieved result into the context — and then generation. The real heart of it is this principle: don't stuff everything in; retrieve the relevant bits first, then inject. And by that definition, on-demand tool loading genuinely is RAG. Don't put all the schemas in context — retrieve what's needed, then inject it.

But here's where it gets interesting. Who is the retriever? Because there are two distinct modes, and the difference between them is the whole point.

Mode A is classic vector retrieval. Your query gets turned into an embedding, you compute cosine similarity against your stored chunks, you grab the top few matches. The decision-maker here is math. And critically, retrieval is automatic and it happens up front — before the model "speaks." The model just passively receives content that's already been fetched for it.

Mode B is what I'd call agentic retrieval, and here the LLM is the retriever. The query comes in, the model reads the index, reasons about it, and then actively goes and calls search to fetch what it decided it needs. The decision-maker is the model's own reasoning. Retrieval isn't a background pre-processing step the system runs for you — it's an action the model initiates in the middle of the conversation. It looks at the index, thinks "I need this one," and goes and gets it.

So let me put the two side by side. Vector RAG retrieves document chunks; tool loading retrieves tool schemas. In vector RAG, cosine similarity — math — decides what comes back; in tool loading, the model's reasoning decides. Vector RAG retrieves before generation; tool loading retrieves during the conversation, model-initiated. And the model's role flips completely: in vector RAG it's a passive recipient, in tool loading it's the active initiator.

So the most precise way to say it: on-demand tool loading is the concept of RAG, but with agentic retrieval swapped in for vector retrieval. It belongs to a bigger family you could call "retrieval-augmented anything." Retrieving documents is RAG. Retrieving tools — call it tool RAG. Retrieving examples to drop into your prompt — that's dynamic few-shot. Same parent philosophy across all of them: context is scarce, so retrieve before you inject.

And here's the detail that really made it click for me. That tool-search function actually supports both modes, and you can tell which one you're using just from the shape of your query. If you write something like "select WebFetch" — you already know exactly which tool you want — that's an exact fetch, basically like a SQL lookup by name. But if you write something fuzzy like "notion send message," because you're not sure of the tool's exact name, that triggers a keyword or semantic search against the tool descriptions. And that second path? That really is Mode A, honest-to-goodness vector retrieval — just with the target swapped from articles to tools.

Which means the two modes aren't mutually exclusive. They stack. The model uses reasoning to decide whether to retrieve at all and what keywords to use — that's the agentic layer on top — and underneath, vector similarity maps those fuzzy keywords onto concrete tools. Agentic on top, vector underneath, working together.

So let me leave you with the takeaways.

First, and this is the big one: RAG's value was never the vector database. It's the index-then-load structure. Hand over a lightweight index, expand the heavy definition only when needed. That same structure works for documents, for tools, and for examples — it's all the same shape.

Second: what agent systems genuinely add on top of classic RAG is letting the model participate in the retrieval decision itself. Not "the system fetches and the model receives," but "the model reasons about what it needs and goes and gets it."

And third, the practical takeaway: if your agent has so many tools they won't fit in context, don't sit there hand-categorizing them. Build the minimal mechanism instead — a registry that stores just name and description, plus a search function that returns the full schema on request. It's structurally identical to the document RAG you already know how to build. You're just pointing it at a different target.