Context Engineering
- title
- Context Engineering
- type
- concept
- summary
- Assembling the right prior state into an LLM's context before asking it to do anything
- tags
- llm, pkm, prompting
- created
- 2026-04-09
- updated
- 2026-07-21
Context engineering is the discipline of assembling the right information for an LLM before asking it to do anything. The term reframes "prompting" around what goes into the context window rather than how the instruction is phrased. The phrasing matters, but the content matters more.
The observation behind the term: a cold LLM has no idea who you are, which decisions have already been made, what the codebase looks like, or what constraints apply. Most bad LLM output comes from the model guessing at context it doesn't have, not from the model being dumb. Giving it the relevant slice of your prior decisions, meeting notes, design docs, and code usually produces materially better output than rewording the prompt.
This is the main argument in filesystem-is-graph-database. Rumproarious describes a ~52k-file markdown vault not as a knowledge base to retrieve from, but as a "context engineering system" — the value is that every new conversation can be seeded with the relevant prior state. The graph exists so the next conversation is better, not so the current one is. A PKM system evaluated by what it retrieves misses the point; evaluated by how much better it makes the next LLM interaction, the value is obvious.
Context engineering overlaps with but isn't the same as:
- RAG: retrieval picks chunks automatically from a vector index. Context engineering is closer to hand-curated retrieval, with a human or an LLM agent choosing which files to load. See rag-limitations for where automatic retrieval falls down.
- Prompt engineering: framing, role-play, few-shot examples. Context engineering is the "load the right files" half; prompt engineering is the "ask the right question" half.
- Agent memory: long-running agents maintaining state across sessions. Context engineering is the human-facing version of the same problem — see agent-memory-decay.
Leonie Monigatti pushes the definition further in agentic-search-context-engineering: for an agent, context engineering is mostly not a static "load these files" step but a search problem — her hot take is that it's about 80% agentic-search. The single "context curation" arrow hides a set of search tools the agent decides when and how to call, across many sources (files, databases, web, memory), each with its own native search tool. On that view the interesting question stops being how to phrase the prompt and becomes which search tools belong in your stack given your latency and quality needs.
The practical implication for this Second Brain is that the wiki's job is to make it cheap to assemble good context. Summaries that compress a source into one readable page, entity pages that collect everything known about a topic, and cross-references that surface related material are all in service of this. The wiki is optimized for "paste this into a new conversation," not for reading cover to cover.
Fresh context as a feature
ai-assisted-workflow applies context engineering at the task level: each implementation task runs in a fresh AI session rather than continuing a long conversation. The rationale is that accumulated context causes drift — the model starts making decisions based on what it already did rather than what the task requires. Starting clean with a well-scoped task (which includes the parent issue for broader context) consistently produces better output. This is context engineering in the negative sense: knowing what not to include is as important as knowing what to include.