On this page
- Key Takeaways
- Semantics Moves From the BI Team to the Agent's Critical Path
- Context Engineering Becomes a Data Engineering Job
- The Context Layer Sits Between Your Warehouse and Your Agents
- Definitions Get Portable Before Tools Consolidate
- Data Products Beat Big Migrations
- Governance Moves Into the Data Path
- Meaning Is the Moat, and Most of It Is Still Unwritten
- FAQ
Key Takeaways
- Semantics is moving onto the agent's critical path. Gartner predicts organizations that prioritize semantics in AI-ready data will raise agentic AI accuracy by up to 80% by 2027. Metric definitions used to be a BI concern. Now they decide whether an agent answers correctly.
- Context engineering is becoming a data engineering job. Deciding what an agent sees, in what order and with what permissions, looks a lot more like pipeline work than prompt writing.
- A context layer is forming between the warehouse and the agents. It sits on top of the semantic layer and assembles the right slice of data, metadata and rules for each task.
- Definitions are getting portable. Open efforts like the Open Semantic Interchange point to a world where your business logic lives in files you own, outside any one tool.
- Start small and specific. The teams that move fastest pick one agent, list the questions it must answer, and build the meaning layer for those questions first.
Ask an agent "what was revenue last quarter?" and it will give you a number. Fast, confident, formatted nicely. The question is which revenue. Booked or recognized? Gross or net of refunds? Including the entity you acquired in March or not? Your finance team knows the answer by heart. The agent is guessing from column names.
That gap is where most of the data engineering work for 2027 is heading. In May, Gartner predicted that by 2027, organizations that prioritize semantics in AI-ready data will increase agentic AI accuracy by up to 80% and reduce costs by up to 60%. The same release tells data leaders to build a context layer as a core part of their infrastructure, because schema-based data models on their own carry no business meaning.
I'd read the "up to" carefully. That is a ceiling on a forecast, and I'd plan for less. But the direction matches what we see when agents meet real company data. The model is rarely the weak link. The weak link is that nobody ever wrote down what the data means, because humans carried that knowledge in their heads and filled the gaps without thinking about it.
Agents don't have those heads. So the meaning has to live somewhere they can read it.
The shorthand I use for this: the last decade of data engineering moved data. The next few years will be about moving meaning. Below are the six shifts I expect to define that work, and what I'd do about each one.
Semantics Moves From the BI Team to the Agent's Critical Path
For years, a semantic layer was a nice-to-have owned by whoever ran the BI tool. It kept dashboards consistent. If it drifted, a human analyst caught the mismatch in a meeting and fixed it.
Agents remove that safety net. An agent asked a revenue question will pick a table, pick a column, write a query and return an answer with no hesitation. If "revenue" means three different things across three systems, the agent will pick one, and you will not know which.
There is early evidence on how much explicit semantics helps. In a 2026 benchmark by Rumiantsau and Fokeev, adding a semantic-layer document to the database schema raised accuracy by 17 to 23 percentage points across three frontier models. Cube, which sells a semantic layer, co-published it, so treat the exact numbers as directional. The direction is still hard to argue with: tell the model what the data means and it makes fewer things up.
Write down what your top ten metrics mean
Pick the ten numbers your leadership team argues about most. For each one, write the definition, the source tables, the filters, the owner and the edge cases. That document is the start of your semantic layer, whether or not you ever buy a tool for it. Most companies have never done this, and it shows the moment an agent starts answering questions.
Context Engineering Becomes a Data Engineering Job
Prompt engineering was mostly about wording. Context engineering asks a plainer question: what does the model get to see?
Anthropic describes context engineering as the set of strategies for curating and maintaining the best set of tokens during inference. The same piece makes a point I think data teams should take seriously: models get worse at recalling information as the context window fills, so context is a finite resource. The right slice beats the whole pile.
Read that again with a data engineer's eyes. Deciding which records to fetch, how fresh they need to be, which fields to include, which documents to chunk and how, and what a given user is allowed to see. That is pipeline design. It needs tests, lineage and monitoring, same as any other pipeline.
Gartner points the same way. Its April 2026 release on AI-first data and analytics calls for interconnected data, AI, software and context engineering practices, and warns that siloed practices will fail. I agree with the diagnosis. I'm less sure anyone has the org chart figured out yet (us included).
Treat the context window as a budget
For every agent you run, ask what it actually needs to see to do one task well. Then build retrieval that delivers that, and nothing extra. An agent that gets the whole customer record when it needed the last three invoices is slower, more expensive and more likely to get confused.
The Context Layer Sits Between Your Warehouse and Your Agents
Put the first two trends together and a new layer appears in the stack.
At the bottom, nothing much changes. Source systems, pipelines, modeled tables in a warehouse or lakehouse. That is the work data teams already know. Above it sits the semantic layer, where business meaning lives. Above that, a context layer assembles what each agent needs for each task: the relevant records, the definitions, the metadata, the lineage and the access rules.
Gartner's April release put a number on why this matters: organizations with the highest maturity of AI-ready data and analytics capabilities are achieving up to 65% greater business outcomes, and the release describes the context layer as the central brain for AI agents. Strong words. I'd only add that the layer does not need to be one product. In most companies it will be a mix of a semantic model, a retrieval pipeline, a catalog and an access policy that happen to agree with each other.
Here's how I'd summarize the six shifts in one place.
| Shift | What changes | What to do in 2027 | What to watch for |
|---|---|---|---|
| Semantics on the critical path | Metric definitions decide agent accuracy | Document your top metrics with owners and edge cases | Definitions that live only in a BI tool |
| Context engineering as data work | Retrieval becomes a pipeline | Give each agent a scoped, tested context feed | Stuffing the whole record "just in case" |
| A context layer forms | Meaning and access rules sit above the warehouse | Connect semantic model, catalog and retrieval | Buying a tool before the definitions exist |
| Portable definitions | Business logic moves into open specs | Keep semantics in version-controlled files | Logic locked inside one vendor's format |
| Data products over migrations | Work scoped to use cases | Start from one agent's questions | Multi-year platform projects with no user |
| Governance in the data path | Agents inherit access rules | Apply the same permissions to agents and people | Service accounts that see everything |
Build one layer, serve every consumer
The test of a good context layer is that a dashboard, an analyst and an agent asking the same question get the same answer. If your agents have their own copy of the logic, you have built a second source of truth, and it will drift.
Definitions Get Portable Before Tools Consolidate
One signal I'm watching closely: vendors are starting to agree on how to share meaning.
In September 2025, Snowflake, Salesforce, dbt Labs and others announced the Open Semantic Interchange, an open-source effort to create a common, vendor-neutral semantic model specification. The aim is that AI and BI tools read the same business logic instead of each keeping its own.
I don't know how fast this lands. Standards efforts are slow, and the companies behind them have their own reasons for wanting you on their platform. But the direction is useful for planning. Your metric definitions are an asset. They should outlive whichever BI tool, warehouse or agent framework you use this year.
Keep your semantics in files you own
Write definitions in plain, version-controlled files that sit next to your transformation code. Review changes like code. If a tool needs them in its own format, generate that format from your files. Never the other way around.
Data Products Beat Big Migrations
The old pattern for "getting our data ready" was a long platform project. Pick a warehouse, migrate everything, model everything, then start using it. Plenty of those projects finished with a beautiful platform and very few users.
Agents give data teams a better forcing function. An agent has a job. The job has questions. The questions need specific data with specific meaning. That is a scope you can deliver in weeks.
This is how we approach it on our own engagements. PressW's Data Engineering work starts by tracing each priority AI use case back to the sources, fields and refresh rates it needs, then builds pipelines, models and semantic layers for that use case before expanding. Each data product gets an owner, a contract and defined quality checks.
Start from one agent's questions
Pick the agent you most want working in six months. Write down the twenty questions it must answer correctly. Trace each one to its data and its definition. You now have a backlog, a test suite and a definition of done. That is more useful than any maturity model.
Governance Moves Into the Data Path
The last shift is the one most companies are least ready for. When a person queries the warehouse, access rules apply. When an agent queries it through a service account, those rules often don't.
Agents need context, and context includes sensitive data. Customer records, compensation, contracts, deal terms. If the agent can see it, anyone who can talk to the agent can potentially get at it. That makes access control, sensitivity tagging and lineage part of the context layer itself. Bolting them on later is how leaks happen.
Gartner's May release expects regulators to demand more semantic transparency and boards to treat semantic governance as a strategic risk. I think that's right, and I think most teams will feel it first as an internal problem: someone asks an agent a question and gets an answer they should not have seen.
Give agents the same access rules as people
An agent acting for a user should see what that user can see. No more. Build that into the context layer from day one. Retrofitting permissions after an agent is in production is painful and usually incomplete.
Meaning Is the Moat, and Most of It Is Still Unwritten
The idea underneath all six shifts is simple. Models are getting better and cheaper on their own. Your competitors can use the same models you do. What they can't copy is the meaning inside your business: what your numbers mean, how your entities relate, which rules apply to which data. That context is the moat, and right now most of it lives in people's heads.
There is a lot I don't know yet. How semantic standards shake out. Who owns the context layer inside a company: data, IT or the business teams. How to test an agent's understanding of a metric as rigorously as we test a pipeline. Those are open problems, and I'd be suspicious of anyone who says they've solved them.
What I'm sure of is the first step. Write down what your most important numbers mean, and build the pipes that put that meaning in front of your agents. If you want help scoping that for your own stack, our Data Engineering team does exactly this work, and an AI & Data Readiness Assessment is a good way to find where your gaps are. If you'd rather just compare notes, Book a Discovery Call.
FAQ
A semantic layer is a shared set of business definitions that sits on top of your modeled data. It defines metrics, entities, relationships and rules once, so dashboards, analysts and AI agents all use the same meaning. For agents, it is the difference between guessing from column names and knowing what a number represents.
Context engineering is the practice of deciding what information an AI model sees for each task: which records, documents, definitions and rules, in what form and with what permissions. Anthropic describes it as curating the best set of tokens during inference. In practice, much of it is data engineering work: retrieval pipelines, freshness, tests and access control.
The semantic layer defines what your data means. The context layer uses those definitions, plus retrieval, metadata, lineage and access rules, to assemble the right information for a specific agent and task. You need the semantic layer first, because the context layer depends on it.
It still starts with source systems, pipelines and modeled tables in a warehouse or lakehouse. On top of that sits a semantic layer for business meaning and a context layer that feeds agents. Governance, ownership and access rules run through every layer.
Not to start. The first step is writing down your key metric definitions, owners and edge cases in version-controlled files. A tool helps once definitions exist and several consumers need them. Buying one before the definitions are written usually just moves the confusion into new software.
Pick one agent use case and list the questions it must answer correctly. Trace each question to its data and definition, then build the semantic and context layers for that scope. Expand from there, one use case at a time.
