Everyone is Talking About Context Engineering

Even if you’ve just casually been roaming around Medium, LinkedIn, or x.com the past couple of weeks you can’t miss the avalanche of articles or posts trying to define “context engineering”. A couple of weeks ago, Tobi Lutke and Andrej Karpathy kicked off this wave of content, but I think most are settling on something close to Simon Willison’s definition: “carefully and skillfully construct the right context to get great results from LLMs.”

I believe this definition is far too narrow.

Context Engineering Actually is a Discipline

Context engineering is the discipline of building stable frames of reference that give language and text their actionable meaning. It exists wherever someone needs to extract meaning from information that crosses boundaries, time periods, cultures, systems, and domains.

Interestingly, the term “context engineering” isn’t new. In 2004, researchers Roque, Almeida, and Figueiredo defined it as a socio-technical framework for information systems development, emphasizing how context emerges from “an autopoietic flux of social interaction.” While their focus was academic, they identified the same core challenge: how to maintain meaning as information moves between different domains and people.

A historian practices context engineering when interpreting primary sources. A lawyer does it when applying precedent to modern cases. A translator bridges contexts between languages and cultures. Each builds frameworks that preserve meaning as information moves from one domain to the next.

The boundaries of context engineering are set by language and text, wherever meaning needs to be preserved, interpreted, or translated, you’ll find some form of this discipline. The specific methods vary wildly by domain, but the core challenge remains constant: how do you maintain meaning when information leaves its original context?

Why I’m Focusing on Customer-Based Context Engineering

From this universal principle, we can choose where to apply it. Practically and purposefully, since so many AI applications are within a business context, it makes sense to start with the operational core of every business: their customers.

A customer only exists within the context of a business relationship, making them the natural organizing principle that can align disconnected systems and teams. When you anchor context engineering around customers, you create a shared view for the entire business.

I’ll use customer-based context engineering as an example to understand the broader context engineering framework and show how powerful just one aspect of context engineering can be.

The Three Layers That Make Context Engineering Work

Every form of context engineering (whether practiced by historians, lawyers, or businesses) relies on three fundamental layers. To illustrate how these universal layers function, I’ll demonstrate each through customer-based context engineering.

Semantic Layer: Getting Everyone to Speak the Same Language

In any context engineering discipline, semantic alignment forms the foundation. For historians, this means understanding how the meaning of words shifts across time periods. For translators, it’s navigating cultural connotations that change between languages.

The irony is that even “context engineering” itself suffers from semantic confusion. The AI community defines it narrowly as “the practice of designing and building context-aware systems.” They focus on RAG pipelines, prompt strategies, and retrieval systems. This technical definition captures important implementation work, but it addresses only part of the broader discipline.

In customer-based context engineering, semantic alignment means getting your entire organization to agree on fundamental definitions. What constitutes an “active customer”? When is an account considered “at risk”? The technical scaffolding only works when there’s a stable semantic foundation underneath it.

According to Namrata Ram, Head of Revenue Operations at Notion, their RevOps team surfaces product usage data to help go-to-market teams identify expansion opportunities. The key is that everyone understands what those signals mean. Product tracks feature adoption, sales sees expansion potential, support identifies teams that might need guidance. Same data, consistent interpretation, role-specific actions.

System Layer: Making Data Flow Without Losing Meaning

Once semantic alignment exists, context engineering requires systems that preserve meaning as information moves. For historians, this might involve citation standards and archival systems. For legal professionals, it’s the infrastructure of case law databases and referencing protocols.

In customer-based context engineering, the system layer involves building infrastructure that maintains context as data flows between tools and teams. Notion’s RevOps team connects product telemetry to business systems. As Ram explains, they surface usage data to their go-to-market teams, allowing reps to see how customers are actually using the product. This context-rich data flows from product systems into sales workflows, maintaining its meaning across the handoff.

Interface Layer: Where Context Becomes Action

The interface layer makes semantic alignment and system integration actionable. For historians, this includes indices, footnotes, and cross-references that let readers verify and explore sources. For legal professionals, it’s the search interfaces and citation tools that make precedents accessible.

In customer-based context engineering, this layer determines how teams actually use unified context. At Notion, the RevOps team owns goals across the entire customer lifecycle. This means creating visibility into the customer journey for every team that touches it. While she doesn’t detail specific dashboards, Ram’s description suggests teams get the context they need to act at the right moments.

Why Context Engineering Matters

Context engineering transforms how we extract meaning from information that crosses boundaries. The discipline creates interpretive frameworks that make every decision more informed and every action more effective.

In customer-based context engineering, this transformation becomes immediately tangible. Sales reps stop asking customers for information the company already has. Support agents resolve issues on first contact because they see the complete picture. Product teams can trace features directly to revenue impact. The friction that everyone accepts as “just how things work” starts to disappear.

This illustrates the broader power of context engineering. When properly implemented, it enables historians to trace ideas across centuries without losing nuance. It allows legal teams to apply precedents with confidence in their relevance. In each domain, the discipline solves the fundamental challenge of maintaining meaning in complex systems.

That’s what makes context engineering essential for the AI era. AI works best when it has solid contextual foundations to build on. Without that foundation, you’re asking AI to make sense of information that doesn’t make sense to your own organization.

Making AI Context Methods Actually Work

The current focus on building context into AI represents important progress. New techniques for RAG pipelines, prompt engineering, and retrieval systems are creating real value. But these methods work best when built on the broader foundation of context engineering.

Before you optimize how AI accesses information, you need to ensure that information is worth accessing. Before you engineer prompts, you need to engineer meaning. This is where treating context engineering as a comprehensive discipline becomes essential.

Companies like Notion demonstrate this approach. They go beyond technical implementations to do the deeper work of context engineering first. They build semantic alignment across teams. They create systems that preserve meaning as data flows. They design interfaces that make context actionable for both humans and machines.

That’s the conversation we should be having about context engineering. Not just how to feed AI better prompts, but how to create organizational contexts where AI, and everyone else, can actually understand what’s going on. The technical methods matter, but they deliver their full potential only when built on this broader foundation.