Last night, I gave a talk at a LangChain hosted event, along with Lance Martin. I used the opportunity to argue why the term “context engineering” is not only here to stay, but signals the emergence of a new field, culture, and community.

I was a bit nervous with one day to assemble the talk (I figured no one needs to hear me recap context fails and fixes), but was so happy with how it turned out. Harrison, Lance, and the rest of the LangChain crew put on a great event. After 30 minutes of presentations, Lance and I answered questions for another 2 hours before the building kicked us out.

I hope this talk resonates with you. And please, shoot me a note with any feedback, thoughts, or questions.

When the term “context engineering” arrived, after Karpathy knighted it, there was a fair amount of push back. “Another marketing term,” some people said. One HN commenter called it, “A month long skill, after which it won’t be a thing anymore.”

I don’t think this is the case. In this presentation I’ll argue not only is “context engineering” here to stay, but the terms arrival will accelerate the development of the field, culture, and community.

This might be my favorite quote. Every time I cite it, I’m reminded of that scene in the Simpsons: “Don’t make me tap the sign.”

But this quote comes up a lot in AI.

The languages we speak are frameworks we use to understand the world. Language does not just describe reality, it defines reality. At the very least, it puts hard limits on the conversations you can have with others. The words you know and the words we have, establish the boundaries of what we can understand.

Successful buzzwords are not invented out of thin air. They instead identify common experiences which we all have and can relate to. Giving these experiences a name crystallizes these idea and experiences and makes them communal. That’s the power of a buzzword. And when these things snap into focus, they create community, change culture, and influence our work.

Context engineering is a textbook example of this pattern.

Context engineering is a successful buzzword because everyone in this room has been experiencing a drift away from what we began talking about when we first started talking about prompt engineering.

Our initial experiences working in contexts was conversational, it was honing one or two-turn LLM interactions. But as we’ve built agents and applications that are more robust, and developed new best practices, we’ve drifted away from marketers, executives, or other non-technical users who’ve developed strategies for how to use chatbots.

And I say that with love for marketers (we in tech too often undervalue marketing!). “Prompt Engineering” and “Context Engineering” are just different. One is not inherently better.

This drift away from where we started with prompt engineering happened for a couple reasons.

First off, while the big model builders spent most of 2024 in a context window arms race, the builders using these models discovered that giant context windows didn’t solve our problems. Large contexts are not a free lunch. So we worked to deliver the applications we or our bosses promised, developing tactics and techniques to make things work.

As we did so, we learned and matured. We learned how to work with and design tools. We evolved chatbots from direct interfaces with models to sizable applications, and agent building design patterns emerged.

The thread through all of this was all of us, separately but at the same time, were figuring out how to systematically engineer contexts in pursuit of an outcome.

I put this slide up at Databricks’ Data+AI Summit and saw a room full of nodding heads. Prompting in natural language is one of the most exciting innovations today, but no one will argue it’s easy, maintainable, or robust. We all know this pain – and it snapped into focus once the term “context engineering” arrived.

“Context engineering” grew fast. In a month, it’s over a quarter of the search volume for “prompt engineering.” And I expect it to grow further. That sustained, upward trajectory is a sign that there was latent understanding here. A marketing buzzword would spike and fall. But here, the term is organizing the work that’s already being done.

And that’s the important bit: we’ve all been working in this field, it just didn’t have a name. My posts about context fails and context fixes merely organized the ideas and approaches that were already in the ocean of research papers.

But what’s been fun to watch (and another reason I find context engineering to be more substantive than most other buzzwords) is that people immediately picked up these terms to describe what they were experiencing. Including, Lance, who will be talking about this in a bit.

With agreed upon language, everything accelerates. We don’t always have to establish a baseline for what we’re talking about before we talk about it.

So does the arrival of the term “context engineering” change anything? Does it actually matter?

I think it does. It allows us to self-identify with each other, to have a common terrain, and start building forward. And this will accelerate and change things.

Now, predictions are a fools game. Take the next slides with a giant grain of salt, but here are some of the ways I think a focus on context engineering will change things in the coming months.

(See slide)

(See slide)

(See slide)

I hope I’ve convinced you why context engineering isn’t just a buzzword, but the emergence of a new field, community, and culture. And one that will grow dramatically over the coming years. Even if models double in capability or if we’re able to utilize every token of the context window, I fully expect the people here to be systematically engineer contexts in pursuit of an outcome. That’s not going to go away.

And I hope you’re excited. Collective realizations like these are rare in your careers. And you get to help shape this one, together.