Context Engineering

context engineering treats the finite context window as a scarce resource to manage systematically — three pillars: (1) system prompts — fixed role, behavior rules, and format constraints stable across turns, versioned over time (e.g. "say so when unsure", output JSON structure); (2) memory tiers — layered by stability and recency: system rules > current user intent > conversation history > retrieved evidence and tool results, with long histories compressed (summarization-style context compaction) or truncated by relevance; (3) token budgets — explicit allocation of the window $W$: instruction, history, retrieval, and reserved output $W_{\text{out}}$ such that $\sum_i t_i + W_{\text{out}} \le W$, with cost approximated by $\text{cost} = c_{\text{in}} \cdot t_{\text{in}} + c_{\text{out}} \cdot t_{\text{out}}$ — over budget means truncation or summarization.

prompt architecture for long conversations, RAG Q&A, and agent systems; multi-turn memory pruning and compression; cost optimization under per-token pricing; a favorite interview question — design context management for a 200K-window agent.

unmanaged stuffing buries key instructions (echoing Lost-in-the-Middle), lets history bloat eat the budget, and scales cost linearly with context. Context engineering upgrades "how to write prompts" into "how to allocate the window", making the accuracy/cost/latency trade-off explicit.

What are the principles of system-prompt design, and how do you layer it against user input and retrieval to avoid override?

Typical memory tiers and their lifetimes; when and how does context compaction trigger?

For a 200K window, how do you budget instruction/history/retrieval/output, and why must output be reserved?

Under per-token pricing, when do you resend long history vs use summary/prompt caching?

Context engineering vs Lost-in-the-Middle: where in the window should critical info go to maximize usage?