There is a reflex that says more context is better. It is wrong often enough to be worth a lesson: past a point, extra context makes the model choose worse, not better, and it costs money on every request.
The four kinds of context
**The task.** What you want, in one or two sentences. This should be first and unambiguous. Everything after it is subordinate.
**The material.** The files, the schema, the logs. Hand over what the task actually requires, not everything related to it.
**The tools.** What the agent can call. Every tool definition costs tokens on every request, whether or not it is used.
**The history.** What was said earlier. Re-sent each turn, and the main reason long conversations get expensive.
The ordering that works
Task first, then the smallest material that makes the task answerable, then constraints (what not to do), then examples if the format is unusual. Tools and history are ambient — they are there whether you order them or not, which is why they are the ones to audit.
A practical habit: put the constraint immediately after the task. Models weight early instructions more heavily, and a prohibition in paragraph nine is often ignored.
Withholding is a skill
Do not paste the whole repository. Do not paste the whole database schema. Do not attach the twelve documents "just in case". Each of those adds noise that the model must filter, and filtering is the part it does least reliably.
The test: if you removed this file, would the answer change? If not, leave it out.
Measuring instead of guessing
Use the context budget checker on a representative prompt. Under 30% of the window, you have room. Over 70% before the conversation starts, the material is the problem, not the model.
When you need live data — a real file, a real database, a real browser — the answer is a tool, not a bigger paste. That is what MCP servers are for.
Next: when not to use an agent.