When to Use What
When to Use What
By now, you have learned many new terms. Context windows. RAG. Vector databases. Long-term memory. System prompts. Tools. At first, they may seem like independent technologies. They are not. They are different tools, each designed to solve a specific engineering problem. Let's put them together into one mental model. If the model needs general knowledge, you simply use the LLM. If the model needs company documents or external information, you use RAG. If those documents need semantic search across large collections, you introduce a vector database. If simple keyword search is sufficient, a vector-less RAG or full-text search may be the better choice. If the model needs to remember the user, their preferences or previous conversations, you use long-term memory. If the model needs to perform an action, such as sending an email, querying a database or calling an API, you connect it to tools. If the model needs a permanent identity, personality or organizational rules, you define a system prompt. And if all of these components need to work together in the correct sequence, you build an orchestration workflow. Now think about the platforms you will encounter in industry. Frameworks like LangChain, LangGraph, n8n, LlamaIndex and similar platforms are not competing ideas. They are engineering environments that help you assemble these building blocks into complete AI systems. Different frameworks expose different components, but they are all solving the same architectural problems. This is why experienced AI engineers rarely start by asking, "Which framework should I learn? " They begin with a business problem. Once the problem is clear, the required components become obvious. If the solution needs documents, they add RAG. If it needs memory, they add a memory layer. If it needs external actions, they connect tools. The architecture follows the problem—not the other way around. That is perhaps the most valuable lesson in this entire playlist. Don't memorize technologies. Memorize the problems they solve. Frameworks will evolve. New tools will appear. New libraries will become popular. But if you understand why each component exists, you will be able to work with any framework that the industry adopts next. That is the mindset of a Context Engineer.