A semantic layer translates technical data structures into governed business terms tools and agents can query. Context engineering is the ongoing discipline of deciding what an LLM actually receives at inference time: instructions, retrieved data, semantic definitions, tools, memory, and rules. A semantic layer supplies one input to that discipline; context engineering decides when it enters the context window and what travels with it. Atlan, the Context Layer for AI, treats the semantic layer as one governed source among several, combined with metadata, lineage, and access policies for full task context.
- Semantic layer, governed data infrastructure that translates technical data into shared business definitions.
- Context engineering, the ongoing discipline that decides what an AI model receives for a given task.
| Semantic layer | Context engineering | |
|---|---|---|
| What it is | Governed data infrastructure | An engineering discipline |
| How it operates | Centrally maintains definitions for reuse | Continually curates the LLM’s context |
| Primary consumer | Tools and agents that use business data | LLMs and AI agents |
| Scope | Meaning and relationships in business data | Instructions, tools, data, memory, rules |
| Failure mode | Conflicting interpretations of data | Incomplete or poorly organized context |
Is context engineering the same as a semantic layer?
Context engineering and a semantic layer are not interchangeable. A semantic layer is governed data infrastructure that defines and serves shared business meaning; context engineering is a discipline that decides what an AI model sees every time it runs. Atlan, the Context Layer for AI, treats the semantic layer as one governed source of context, not the complete context an agent needs, combining it with metadata, lineage, ownership, and access policies before making that context available to agents.
Consider an AI analyst asked for last quarter’s revenue. The semantic layer supplies the certified definition, so the agent calculates revenue correctly. Context engineering supplies what else the request needs: who is asking, whether the figure has changed, and whether finance must approve it first.
Shared definitions alone do not make enterprise data ready for AI, the same bar Atlan’s AI-ready data checklist works through. According to Cloudera and Harvard Business Review Analytic Services (2026), only 7% of surveyed organizations say their data is completely ready for AI, and 73% call it challenging. Atlan’s what makes data AI-ready breakdown covers the same gap, and the context layer vs. semantic layer comparison examines both components directly.
What does a semantic layer do?
A semantic layer is a governed translation layer between an organization’s data sources and the tools that query them, mapping schemas and join paths to governed definitions like revenue or active customer, so BI tools and AI agents can query them instead of reimplementing the logic. dbt Labs describes its Semantic Layer, powered by MetricFlow, as a way to centralize metric definitions and avoid duplicate code, per its quickstart guide, one of several semantic layer tools teams weigh once duplication gets expensive.
A semantic layer typically brings together measures and metrics, dimensions and hierarchies, entities and relationships, query rules, and access controls, and the metrics row is often where teams first mix up the two ideas Atlan separates in semantic layer vs. metrics layer.
The primary benefit is consistent interpretation: if Tableau, Excel, and an AI analyst all request net revenue for the same period, the semantic layer applies the same governed definition, the same pattern Atlan’s guide to semantic layers for analytics walks through. That reach has limits: it owns metric logic and query-time rules but relies on adjacent systems for storage and lineage, a distinction from raw metadata Atlan’s semantic understanding vs. metadata management comparison covers. It tells an agent what revenue means, not who is asking or whether approval is needed, the decisions context engineering must account for.
What does context engineering actually mean?
Context engineering is the practice of deciding what an LLM sees at inference time, a definition Atlan’s what is context engineering explainer covers from first principles. Anthropic (2025) defines it as curating and maintaining the optimal set of tokens during inference, the natural progression of prompt engineering.
Prompt engineering focuses on how instructions are written; context engineering manages everything else in the window, the core of the context engineering vs. prompt engineering argument. Anthropic treats system instructions, tool definitions, few-shot examples, message history, and runtime data (including through MCP) as engineered context, and because the window is finite, the goal is the smallest high-signal set the agent’s next step needs, not as much as possible.
LangChain groups the operational work into four context engineering strategies, per its Context Engineering for Agents post (2025): Write (save information outside the window), Select (pull it in when needed), Compress (keep only the tokens the task requires), and Isolate (split context across sub-agents so each step sees only what it needs). These techniques apply throughout a task as instructions and tool results accumulate; teams doing this repeatedly codify it into a standing context engineering framework instead of reinventing the sequence per agent.
Datadog’s State of AI Engineering report (2026) found that system prompts accounted for 69% of input tokens in its customer traces, evidence that context engineering must manage the full set of inputs, not only the user’s question.
Why do people confuse context engineering with a semantic layer?
People confuse the two because both help AI systems understand business data: a semantic layer provides shared meaning, while context engineering determines when that meaning reaches the model. Some semantic-layer products now expose governed definitions through APIs or MCP, and as semantic layers expand from BI tools to AI agents, they can appear to provide all the context an agent needs, a conflation Atlan’s semantic layer vs. data catalog comparison untangles. Discussions of the context layer, data catalog, and semantic layer often mix infrastructure with context engineering too, though one is a technical layer and the other an engineering discipline.
Separating three related terms makes it clearer:
| Term | What it is | Primary role |
|---|---|---|
| Semantic layer | Governed data infrastructure | Defines and serves shared business meaning |
| Context layer | Governed infrastructure for AI | Combines semantic definitions with metadata, lineage, and policies for agents |
| Context engineering | An ongoing engineering discipline | Selects and maintains what a model receives for a task |
The simplest distinction: a semantic layer and a context layer are infrastructure teams build or adopt, while context engineering is the practice of deciding how that infrastructure gets used, the same infrastructure-vs-practice line Atlan’s guide to enterprise context layer for AI agents draws.
How do context engineering and a semantic layer work together?
At enterprise scale, a semantic layer supplies governed business meaning to a context engineering practice, which decides when those definitions enter the model’s context and how the agent’s use of them is tested as conditions change.
The context an agent needs falls into three categories, and a semantic layer contributes mainly to the first, the same split context engineering for AI agents comes down to: Knowledge (entities, metrics, and relationships, supplied by the semantic layer), Expertise (playbooks and edge cases, usually from documentation and agent instructions), and Norms (permissions and regulatory rules, which the semantic layer rarely captures in full).
For a restaurant franchise agent asked why drive-through time increased this week: the semantic layer defines drive-through time and how stores and orders relate (Knowledge); engineered context tells it which causes to check, such as staffing (Expertise); and it determines which stores the user may examine (Norms).
Even a semantic layer built for AI agents remains one governed source of context. Context engineering combines its definitions with operational data and rules, then tests whether the agent applies all of it correctly, rerunning evaluations through the context development lifecycle whenever a definition changes.
What breaks when you have only one of them?
Each approach leaves a different gap when used alone: governed definitions without task guidance, or task context without shared meaning.
A semantic layer without context engineering
A semantic layer solves the blank-page problem, but not whether an agent applies a definition in the right context: it may apply the global revenue definition where a regional exception applies, or limit which rows an agent sees without limiting whether it should run the task.
This is where semantic layers fall short for agents: governed definitions can improve SQL accuracy without telling the agent how to interpret the task, a distinction also visible in text-to-SQL vs. a semantic layer.
Context engineering without a semantic layer
Without a semantic layer, definitions duplicate across prompts and platform-specific views: each prompt carries its own version of a term like “active customer” and drifts as agents are added, two agents answer the same question with different numbers while each stays consistent with its own instructions, and definitions buried in long prompts become difficult to own or reuse.
Retrieving more documents does not create shared definitions, as RAG vs. context engineering explains, a gap context engineering for RAG agents runs into directly. Repeating logic across multi-agent systems and point solutions makes drift harder to control, the same fragmentation Atlan’s guide to data catalogs built for AI closes.
How does Atlan treat the semantic layer as a starting point, not a ceiling?
Atlan’s Context Engineering Studio starts with the business knowledge an organization already has: it reads existing metadata, lineage, and BI assets to draft a semantic foundation domain experts can refine, the same posture behind Atlan’s guide to AI-ready data. It carries that foundation through six stages, from drafting and testing to review, approval, deployment as a versioned Context Repo, and ongoing learning from production traces, complementing an existing semantic layer rather than replacing it.
| Context gap | Capability | How it helps |
|---|---|---|
| Context scattered across SQL, lineage, and docs | Context Agents | Draft descriptions, glossary terms, and metrics from existing signals |
| Teams cannot prove an agent applies definitions correctly | The Studio | Turns queries into evaluations that expose missing definitions |
| Teams use different versions of the same term | Context Repos | Package context as versioned, domain-scoped units |
| Each agent keeps its own copy of context | Context Lakehouse | Serves shared context through MCP Server, A2A, and APIs |
| Teams cannot trace a metric to its source | Data Lineage | Exposes column-level provenance for agents to inspect |
What does this look like in practice?
Organizations often begin with the same requirement: give AI agents access to shared business definitions instead of recreating that meaning for every agent. Two anonymized customer conversations show that pattern. At a nonprofit cancer research and treatment institute, its VP of Enterprise Data and Analytics described the organization as not looking for a data catalog platform, but for a semantic layer, and its decision to choose Atlan was shaped in part by its direction on context for AI. At a global customer-experience and BPO company, the data and AI architecture lead is building agents that retrieve information from two MCP servers, and described the server holding the semantic layer as the more consequential of the two, since that is where the organization’s semantic layer lives.
Which one do you need first?
Which one comes first depends on what your organization already has. The goal isn’t to choose one and stop, but to make them work together, supported by a context layer that delivers the required context to AI systems.
If you already have a semantic layer, keep it as the governed source of meaning and add context engineering to combine those definitions with the instructions and permissions each agent task needs. If definitions are scattered across systems, establish a semantic layer bootstrapped from existing SQL, BI models, and lineage, then assign owners to maintain it. If agents already rely on prompt-level definitions, move them out of prompts into the semantic layer and introduce versioned context and evaluations incrementally.
Whichever path you take, the semantic layer stays the governed source of meaning, a context layer makes it portable across tools, and context engineering determines what reaches the agent for each task. To identify your next priority, assess your context maturity or get the AI Context Stack.
Real stories from real customers: shared semantic definitions AI agents can trust
"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."
Joe DosSantos, VP Enterprise Data & Analytics, Workday
To understand how the semantic layer, context layer, and context engineering fit together
To understand how the semantic layer, context layer, and context engineering can work together in your company’s architecture, book a demo to talk with the Atlan team.
FAQs about context engineering vs. semantic layer
1. Is context engineering the same as a semantic layer?
No. A semantic layer translates technical data into governed business definitions; context engineering selects and maintains everything a model receives for a task, including those definitions.
2. Do I need a context layer if I already have a semantic layer?
Usually at enterprise scale, but not for every isolated use case. A context layer combines semantic definitions with lineage, ownership, and permissions, so teams don’t rebuild those connections per agent.
3. What’s the difference between RAG and context engineering?
RAG retrieves relevant documents and adds them to a model’s context. Context engineering decides everything the model receives; RAG is one selection technique within it.
4. How is Context Engineering Studio different from a semantic layer?
A semantic layer defines business concepts and query logic. The Studio assembles governed assets into a use-case-specific Context Repo and tests it, complementing a semantic layer rather than replacing it.
5. Does adopting context engineering mean replacing an existing semantic layer?
No. An existing semantic layer can remain the governed source of definitions; context engineering uses it as an input, then selects and maintains the complete context for each task.
6. What breaks when an AI agent only has a semantic layer and no broader context practice?
The definition may be correct while the answer is still wrong for the task: an agent may miss a regional exception, expose restricted information, or act without approval, and teams often discover it only after users do.
7. Who owns context engineering versus the semantic layer?
Ownership varies. Data and analytics teams commonly maintain the semantic layer; AI, data, security, and domain teams share context engineering.
8. How do you test whether an agent is using semantic-layer definitions correctly?
Build an evaluation set from real questions and expected results from verified dashboards and queries, then compare the agent’s answers against those results and fix the missing definition behind each failure.
Sources
- Effective context engineering for AI agents, Anthropic, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Context Engineering for Agents, LangChain, 2025. https://www.langchain.com/blog/context-engineering-for-agents
- Semantic Layer quickstart guide, dbt Labs Documentation. https://docs.getdbt.com/guides/sl-qs
- Only 7% of enterprises say their data is completely ready for AI, Cloudera and Harvard Business Review Analytic Services, 2026. https://www.cloudera.com/about/news-and-blogs/press-releases/2026-03-05-only-7-percent-of-enterprises-say-their-data-is-completely-ready-for-ai-according-to-new-report-from-cloudera-and-harvard-business-review-analytic-services-reveals.html
- State of AI Engineering, Datadog, 2026. https://www.datadoghq.com/state-of-ai-engineering/
