“Context engineering” became the phrase of the year because everyone needed a name for the part of agent work that wasn’t model selection or prompting. The phrase is doing real work — there is a discipline to deciding what to put in the model’s window — but it’s also doing some lying. It implies craft where most of what’s happening is a budget decision being made without a budget.
Every context window has a hard size. Every additional token costs latency, cost, and quality (the model attends worse to a longer prompt). So every context decision is a tradeoff: include this retrieved chunk and exclude that tool definition; keep the conversation history and lose the system prompt’s example block. Those are budget choices. They look like craft because nobody wrote the budget down.
What it looks like as a budget
Three numbers, on a postcard:
- The cap. Not the model’s max — your max. “We never exceed 8K input on this endpoint.” Budgets without caps are wishes.
- The fixed cost. System prompt, tools, examples — sum them. You’ll be surprised how often this alone is half the budget.
- The variable allowance. What’s left for retrieved context, user message, conversation history. Decide the allocation explicitly. Cap each piece.
Once these exist, “context engineering” becomes “did the retrieval respect its allowance?” — a question you can test, log, and alert on. Without them, it’s vibes.
The argument for the rename
Calling it engineering with a budget makes the failure mode visible. “Our retrieval is too long” is a metric. “Our context engineering needs improvement” is a slide. The budget framing also makes the cost-quality tradeoff legible to product people, who already think in budgets and never think in token windows.
The work is the same. The conversation about the work gets honest.