Most AI systems don't fail because the model is wrong.
They fail because the context is.
But here's the uncomfortable part: context engineering isn't a new activity. We've been doing it for decades under different names:
- Configuration management gave us baselines and change control. Systems engineering gave us decision gates and requirements traceability.
- Domain-driven design gave us the ubiquitous language and bounded contexts. The systems-thinking tradition gave us a method for building explanations rather than narratives.
- Then LLMs arrived, and a lot of that discipline was set aside. Context became "the prompt" — something to tweak, not something to version, validate and govern.
That's the argument in my book, Context Engineering: Designing AI That Understands, Remembers, Acts, and Learns.
It isn't a new invention. It's an old discipline applied to a new kind of system — one where the "software" is partly prompts, partly knowledge, partly retrieval, partly policy, and partly the model's emergent behaviour.
Inside, 25 chapters cover:
- why AI software fails differently — context drift, not crashes
- knowledge graphs as context infrastructure, and when deterministic search beats vector embeddings
- token budgets, compression and skill architecture
- judge harnesses, typed decision models and evidence lineage — how to make an AI's decisions inspectable
- validation gates, multi-agent context and enterprise governance
- building a context engineering practice
It's written for senior developers, engineering managers and architects who need AI to be dependable in production, not just impressive in a demo.
The book is out now on Kindle: amazon.com and amazon.co.uk.
Which older discipline do you think AI teams have forgotten most?
Top comments (0)