Context engineering is not a single technique — it's a family of methodologies that differ in how they acquire, store, select, and deliver context to an LLM. Choosing the right methodology depends on your application's requirements: the size of your knowledge base, the specificity of your queries, your latency budget, and the domain you're operating in.
Document-first methodology
The document-first approach treats structured documents as the primary context artifact. Before any model call, you prepare a curated set of documents — planning specs, architecture decisions, reference material — and include the relevant subset directly in the context window. No retrieval infrastructure is required; the engineering investment is in writing and maintaining the documents.
This methodology works best for projects where the full context fits within a few windows, the documents change slowly relative to the query rate, and the cost of retrieval infrastructure isn't justified. Software development projects, where a complete planning stack can fit comfortably in a large context window, are the canonical use case. The tradeoff is manual curation: someone must decide which documents to include for each session.
Retrieval-augmented methodology
Retrieval-Augmented Generation (RAG) dynamically selects relevant content from a large indexed corpus at query time. The corpus can be orders of magnitude larger than any context window; retrieval makes the effective knowledge base unbounded. This is the standard approach for customer support bots, knowledge base Q&A, and any application where the user's query determines what information is needed.
The engineering complexity is higher: you need indexing infrastructure, an embedding model, a vector store, retrieval logic, and evaluation tooling. Retrieval quality becomes a critical engineering variable — poor retrieval produces worse outputs than no retrieval. The payoff is scalability: a RAG system can handle knowledge bases of any size with consistent latency.
Hybrid approaches
Most production systems combine both methodologies. A coding assistant might use static document inclusion for project-level context (PRD, architecture) and retrieval for code-level context (relevant functions, tests, existing implementations). A customer support agent might use static inclusion for product policies and retrieval for specific product documentation.
Hybrid systems require careful orchestration: deciding which context comes from static documents and which from retrieval, how to merge them without exceeding the context budget, and how to handle conflicts between the two sources. The general principle is: use static inclusion for stable, high-level context and retrieval for dynamic, query-specific context.
Agentic context methodology
In agentic workflows, the model itself participates in context management. It decides what to retrieve, what tools to call, what to store in external memory, and what to summarize and discard. This is the most flexible methodology and the most complex to build reliably. The model's context decisions can be incorrect or suboptimal, introducing a new failure mode.
Agentic context management works best when the task is open-ended, the relevant context isn't known in advance, and the agent has well-designed tools for reading and writing external state. Software development agents — those that navigate codebases, read documentation, and track their own progress — are increasingly using this pattern.
Applications by domain
Software development: document-first for planning context, retrieval for codebase navigation, agentic for long-horizon implementation tasks.
Customer support: RAG over product documentation and ticket history; static inclusion for policies and response guidelines.
Enterprise knowledge management: RAG over internal knowledge bases, hybrid with department-specific static context for role-specific assistants.
Financial services: strict document-first for regulatory context (where retrieval errors have compliance consequences), RAG for market data and research.
Choosing the right methodology
Start with the simplest methodology that solves the problem. For a new project with a small planning stack, document-first is almost always the right starting point. Add retrieval when the knowledge base grows beyond a few windows or when queries are specific enough that full document inclusion is wasteful. Add agentic context management only when the task genuinely requires the model to navigate context dynamically.
The cost of prematurely adopting a complex methodology is high: more infrastructure, more failure modes, and slower iteration. The cost of sticking with a simple methodology too long is more manageable — a document-first system that's hitting its limits can usually be incrementally upgraded to hybrid or RAG without a full rebuild.