In June 2025, Shopify CEO Tobi Lütke articulated what a lot of practitioners had been feeling. “I really like the term ‘context engineering’ over prompt engineering,” he wrote. “It describes the core skill better: the art of providing all of the context for the task to be plausibly solvable by the LLM.”
Within a week, OpenAI co-founder Andrej Karpathy doubled down, calling context engineering “the delicate art and science of filling the context window with just the right information for the next step.”
The term exploded. By July, Gartner called it “one of the most critical skill sets for building enterprise AI applications.” And in February 2026 Martin Fowler published a piece on it, putting context engineering on the same shelf as refactoring, microservices, and continuous delivery — the kind of shelf where engineering disciplines go to become permanent.
This matters if you’re a data engineer, analytics engineer, or data steward. Context engineering is not a new universe. It’s the natural next layer on top of the work you’ve already been doing for a decade.
Here’s what it actually means, what it looks like in practice, and why your team is closer to this transition than you think.
What is context engineering?
Permalink to “What is context engineering?”One of our customers — a Fortune 500 retailer — has 47 different definitions of “customer” spread across their systems. When they deployed an AI analyst, it returned the wrong number every single time. Not because the model was bad, but because nobody had told it which definition of “customer” to use.
That’s the context gap. And closing it is context engineering.
Context engineering is the work of designing, governing, and continuously evolving the context that AI systems and humans use to understand your business.
It’s not writing clever prompts. It’s not hand-tuning a single agent. It’s building and maintaining the layer of organizational understanding that lets any model — today’s LLMs, tomorrow’s agents — reason the way your best people do.
Concretely, context engineering covers three tiers:
| Context Type | What It Is | Examples |
|---|---|---|
| Structural | Definitions, relationships, semantic models, entity relationships | Business glossaries, metric definitions, hierarchies |
| Operational | Rules, procedures, decision logic | Approval workflows, escalation thresholds, exception handling, SOPs |
| Behavioral | Patterns, preferences, historical lessons | Past decision precedents, playbooks that worked in production, domain-specific exceptions |
Prompt engineering tinkers at the surface of this. Context engineering owns it end to end: what context exists, where it lives, how it’s structured, and how AI retrieves and applies it.
Why this is happening now
Permalink to “Why this is happening now”Most enterprises aren’t struggling with AI because models are bad. They’re struggling because AI has no idea what their business means.
We see three manifestations of this across industries:
- The Connectivity Gap. Data lives across 80 to 150+ systems in a typical enterprise. No single AI agent sees the full picture.
- The Semantic Gap. Every domain has a different definition of “customer,” “revenue,” and “churn.” The model doesn’t know which one to use.
- The Experience Gap. Definitions, exceptions, and unwritten rules live in people’s heads, Slack threads, and one-off queries — but not in any form AI can read.
Gartner put a prediction on it: through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data. That tracks with what we see. Sixty-three percent of organizations either don’t have or aren’t sure they have the right data management practices for AI.
The root cause is the same every time. We spent the last decade perfecting data engineering, making sure data is available, tested, and correct. We never built the equivalent discipline for making sure AI is aligned with what the business actually means.
That discipline is context engineering.
See how Atlan closes the context gap for AI teams
See Atlan in ActionHow we got here
Permalink to “How we got here”If this feels abstract, think about where data teams were in 2015.
Data scientists were stuck. No reliable pipelines, no documentation, no one accountable for making raw data usable at scale. Data engineering emerged as the answer. It standardized ETL and ELT, production-grade orchestration, testing, monitoring, and ownership for data movement.
Today, AI teams are stuck in a mirror-image problem. They can call models and stitch together RAG pipelines. But they can’t trust the outputs, because the model is guessing at meaning.
| BI Era | AI Era | |
|---|---|---|
| Situation | Data was scarce | Models are abundant; context is scarce |
| Pain | Unreliable dashboards | Unreliable agents and AI analysts |
| Hero | Data engineer | Context engineer |
| Core Asset | Data pipelines | Context layer |
In the same way analytics engineering layered semantics on top of raw tables, context engineering layers organizational understanding on top of semantics — making it accessible to both humans and agents.
A smart critic would ask: isn’t this just governance with a new name? Fair question. And honestly, the overlap is real.
If you’re a data steward who maintains business glossaries, defines metric ownership, and documents what terms mean across the organization, you’re already doing structural context engineering. That work doesn’t suddenly become something new because we gave it a different label.
Here’s what is genuinely new:
The consumer changed. Governance was built for humans browsing a catalog. Context engineering is built for AI agents making thousands of micro-decisions per day at machine speed. The definitions need to be machine-readable, retrievable, and structured for inference — not just documented in a wiki.
The scope expanded. Traditional governance covers structural context: glossaries, schemas, lineage. Context engineering adds operational context (decision rules, approval logic, exception handling) and behavioral context (precedents, patterns, playbooks). Those two tiers are where most AI failures happen, and they’ve never been anyone’s formal responsibility.
The feedback loop is new. In governance, you define a term and revisit it quarterly. In context engineering, every wrong AI answer is a context bug that gets triaged, diagnosed, and fixed — like a broken test in a data pipeline. The pace is fundamentally different.
So yes, governance is a foundation. But context engineering extends it into territory governance never covered — and operates at a speed governance was never designed for.
Another objection worth engaging: won’t smarter models just solve this? This is the Karpathy question, and it deserves a real answer.
Models are getting dramatically better. Context windows are expanding. Reasoning capabilities are improving every quarter. You could logically argue that the “context gap” is a temporary limitation — a bridge problem that disappears as models get smarter.
Here’s why I think that’s wrong.
Smarter models make the context problem worse, not better. A model that’s 10x more capable but doesn’t know which definition of “revenue” your finance team uses will produce answers that are 10x more convincingly wrong. The hallucination problem isn’t about model quality. It’s about model context.
As Joe DosSantos at Workday put it: “All of the work that we did to get to a shared language amongst people at Workday can be leveraged by AI via context infrastructure. As part of AI Labs, we’re co-building the semantic layer that AI needs.”
The institutional knowledge problem doesn’t shrink with better models. It grows. Every new agent, every new use case, every new department deploying AI creates more demand for governed, trusted context. The model doesn’t generate that knowledge. Humans do. The question is whether it’s organized or scattered.
What context engineers actually do
Permalink to “What context engineers actually do”This is still emerging, but from what we’re seeing across AI-forward teams, context engineers are responsible for three core areas. (I expect this scope to grow.)
1. Build the context layer
Permalink to “1. Build the context layer”Most organizations already have pieces of context scattered across data catalogs, dbt models, semantic layers, policy engines, notebooks, and Slack threads. What they lack is coherence.
Context engineers turn that chaos into a governed layer between data and AI:
- Unify structural context: glossaries, metrics, schemas, lineage — the backbone
- Enrich with operational context: policies, approvals, decision traces — the rules
- Make it machine-readable: not for humans browsing a catalog, but for AI agents making decisions at runtime
Paul Reigel at Urban Outfitters described why this matters: “I’d rather build it inside of Atlan because you see all of it… it’s not just Snowflake, it’s BigQuery, Qlik, MicroStrategy.” The context layer has to span the full heterogeneous stack. No single platform vendor sees everything.
2. Operate the context supply chain
Permalink to “2. Operate the context supply chain”In the data world, we learned that data needed pipelines, tests, and monitoring. Context needs the same:
- Bootstrap: Connect existing metadata, SQL, semantic models, and docs to give AI a rough first understanding of your domains.
- Test: Evaluate whether agents can answer real business questions correctly — not just “does the SQL run,” but “is this how Finance actually defines revenue?”
- Observe: Instrument agents to see where they misinterpret intent or hallucinate around edge cases.
- Enrich: Treat every failure as a context bug, not a model bug. Find the wrong definition, the missing relationship, the undocumented exception.
- Version and scale: Propagate improvements across domains without forking meaning for each agent.
3. Connect data teams and AI teams around meaning
Permalink to “3. Connect data teams and AI teams around meaning”The context layer is where data engineering, analytics engineering, governance, and AI engineering finally meet. Context engineers sit at that intersection. They translate domain experts’ language into machine-readable structures. They work with AI teams to understand what context formats and retrieval patterns actually improve agent performance. And they give CDOs a single place to reason about how agents behave — because whoever owns the context layer effectively owns the blueprint for agent behavior.
A note on where we sit
Permalink to “A note on where we sit”Full transparency: Atlan builds context infrastructure. We have a stake in this category. But the discipline exists regardless of any single vendor. The people doing this work are data engineers and governance leads who’ve been solving context problems for years — they just didn’t have a name for it. The name is new. The work isn’t.
What’s changed is that AI made the cost of not doing this work visible overnight. When a dashboard showed the wrong number, one analyst noticed. When an AI agent gives the wrong answer to a thousand users simultaneously, the whole organization notices.
How to start (you’re closer than you think)
Permalink to “How to start (you’re closer than you think)”You don’t need a new title. The skills you’ve spent years building — modeling data to reflect business reality, documenting what terms mean, debugging why outputs don’t match expectations — are exactly what context engineering runs on. You just need to shift where you apply them.
Start with one AI project that’s already struggling. Don’t build something new. Find the agent that keeps hallucinating, the AI analyst returning wrong numbers, the chatbot nobody trusts. Walk into that project and ask: what context is missing? The problem is almost never the model.
Map what you already have before building anything new. Pull together every relevant table, dbt model, glossary entry, SOP, and piece of tribal knowledge for that domain. Interview the subject matter experts who’ve been answering questions about it for years. The gap between how humans answer questions and what exists in systems is your context backlog. In most organizations, it’s enormous.
Build a minimal context layer for that one domain. Pick the 10 to 20 definitions, metrics, rules, and relationships that matter most. Codify them so an AI agent can retrieve them. Don’t boil the ocean. Just make the three most common questions answerable. This is the same instinct that made you a good data modeler: minimal structure for maximum reliability, then iterate.
Treat every wrong answer as a context bug. This is the mindset shift. When an agent gives a wrong answer, the prompt engineer tweaks the prompt. The context engineer asks: what definition was missing? What relationship wasn’t captured? This is how you already think about data quality — a wrong number in a dashboard isn’t fixed by changing the visualization. Fix the context. The prompt is just the surface.
The decade ahead
Permalink to “The decade ahead”The last decade belonged to teams that took data engineering seriously. The next decade will belong to teams that take context engineering seriously.
These are the teams turning tribal knowledge into machine-readable meaning. Giving AI the same shared understanding their best people have. Making context a living, governed layer — not a mess of prompts and one-off workarounds.
Just as “analytics engineer” became a badge of honor for people who bridged data and business, “context engineer” will become the badge for people who bridge data, AI, and meaning.
You’ve spent years making data trustworthy. Now it’s time to make AI understand.
Share this article