The first five chapters gave a thorough account of RAG, but a reminder is in order: RAG is just one of many ways to use an LLM, specifically designed for "knowledge" problems. In the real world, there are several other ways to put LLMs to work, each addressing a different kind of need. This chapter surveys these forms and situates RAG within the broader picture, along with its boundaries of applicability.

To distinguish these forms, start from a concrete scenario: when you have a task and are about to hand it to the model, ask one question first — to complete it, what is the model missing? Is it missing knowledge, or autonomous judgment, or a certain capability? Following this question downward, the five forms below each correspond to a specific situation.

The task doesn't require external knowledge → Use the prompt directly

Translation, rewriting, summarizing text you've pasted in, generating a passage to spec — these tasks either draw on what the model already knows or don't involve "knowledge" at all; they're pure language processing. In these cases, no additional mechanism is needed — just write clear instructions and hand them to the model. This is also the highest-volume category in everyday use.

The material is at hand and modest in size → Long context

If the answer lives in a few documents and those documents, taken together, fit inside the model's context window, then the simplest approach is to drop them all into the prompt and let the model read them directly. By 2026, frontier models have context windows in the million-token range; a manual of several hundred pages can be loaded in its entirety, with no need for chunking or retrieval. The cost is that every question requires rereading all the material from scratch — once the volume grows, this gets both slow and expensive, and the longer the material, the more likely the model is to overlook key details.

Too much material to fit → RAG

When the knowledge base is too large to fit in the context (thousands upon thousands of documents, continuously updated), you have no choice but to first "search" for the relevant passages and then feed those to the model — this is exactly the RAG covered in the preceding five chapters. Its essence: use retrieval to winnow "too much" down to "just right." RAG and long context are thus two solutions to the same knowledge problem; the dividing line is simply whether the material fits.

What's missing isn't material, but the judgment of "what to do next" → Agent

Some tasks stall not because of missing knowledge, but because they can't be completed in one shot — you need to look up this first, then based on what you find decide to look up that, and perhaps even take real actions in external systems. What's needed here is for the model to plan, invoke tools, and drive the process forward in a loop — in other words, the agents from Chapter Four. According to a Gartner prediction¹, by the end of 2026 40% of enterprise applications will feature task-specific agents, up from less than 5% a year earlier.

What's missing is a capability or behavior itself → Fine-tuning

The preceding forms all leave the model unchanged. But if the problem is that the model's behavior is wrong — inconsistent output formats, a tone that doesn't match requirements, poor performance on a specialized task type (e.g., ticket classification, SQL generation for a specific schema) — then you need the fine-tuning from Chapter Two to press stable behavior into the model's weights. Remember the dividing line: fine-tuning governs form; RAG governs facts — use retrieval for knowledge that changes, fine-tuning for behavior that should be stable.

The art of feeding material: context engineering

Once you've chosen the route of feeding material to the model (long context, RAG, or agent-embedded retrieval), a new question arises: context window space is limited, and retrieved material, conversation history, tool return values, and long-term memory all compete for room — which pieces to include, how to arrange them, when to compress or discard — these directly determine the model's performance. Managing this is called context engineering — it's the evolution of "prompt engineering," concerned no longer with "how to write a good instruction" but with "how to organize all the information the model sees at once." As systems grow more complex, this layer is shifting from an afterthought optimization to a core decision that must be addressed at the architecture design stage.

Summary: which form to choose depends on what you're missing

Given a task, run through the checklist and the approach becomes clear: missing knowledge means supply material (modest volume → long context; large volume → RAG); needs multi-step autonomy → agent; unstable behavior → fine-tuning. Missing one thing, supply one thing; missing several, stack several — real systems are mostly assembled on-demand from combinations like these, rather than being a single form.

The RAG covered throughout this guide is the most commonly used and most accessible-to-understand section of this map, but it's ultimately just one piece — and more often than not, it's used in combination with the other forms.