The Fundamentals of Context Engineering

About this paper

A new job title started showing up in my inbox this year: context engineer. Somebody figured out that the reason their agent kept calling the wrong endpoint and confidently hallucinating a pricing tier that does not exist was not the model — it was the context. So they put a person on it, and they were right to. But I want to say the thing the tooling vendors will not: context engineering is not prompt-tweaking, and if you treat it as prompt-tweaking you will fail at it.

Context engineering is the discipline of curating the optimal set of instructions, knowledge, and feedback that lets an agent reliably discover, understand, and use an API. That is a lifecycle practice with owners, standards, reviews, and metrics — the same maturity arc APIs already walked, compressed into the agent era and skipped by teams racing to ship. This paper walks the fundamentals: what the discipline is and is not, how context gets authored and refreshed across the lifecycle, who owns the orphaned README/AGENTS.md/llms.txt layer, why agents need predictable markdown structure, why you must author the questions a junior does not know to ask, how to embed question formation into MCP workflows, and the part almost nobody does — measuring whether the context actually changed what the agent did. The through-line is one sentence I have been saying about APIs the whole time: treat context as a first-class, governed, lifecycle artifact, the way we learned to treat the API contract.

What's inside

1. What context engineering is — and is not
2. Context across the API lifecycle
3. Who owns the context layer
4. Standardized, agent-consumable markdown
5. Teaching what to ask — author the questions, not just the answers
6. Question formation in MCP workflows
7. Evaluation and feedback — did the context actually work?
8. Anti-patterns I watch for
9. Self-assessment
10. Where this is going
11. Appendix — The context-engineering maturity model

What you get for $25.00