Your BI semantic layer solved a hard problem: getting every team, dashboard, and report to agree on what shared metrics like "revenue," "active customer," or "customer acquisition cost" actually mean. Those governed definitions won't be enough to ground an AI agent. Dashboards and SQL queries run on standardized metric definitions, but agents also need runtime access to documents, conversation history, fresh operational data, tools, and permissions at every reasoning step.
Those runtime needs belong to a separate layer: the context layer. Semantic modeling and AI grounding solve different problems under different runtime constraints, and knowing where one ends and the other begins is the first step to building agents that work in production. This post covers what a semantic layer does well, where it stops short for AI, and what a context layer adds on top.
A semantic layer is the single source of truth for your business metrics. It sits between your raw data sources and the tools that consume them, like dashboards, APIs, and analytics platforms, and holds the definitions of your metrics, dimensions, hierarchies, and entity relationships in one place, so everyone queries the same governed numbers.
Without it, every BI tool defines metrics on its own, and "customer acquisition cost" means three different things across three dashboards. The semantic layer gives you one authoritative definition, served through a governed interface.
Under the hood, these tools turn metric definitions into optimized SQL. You define a metric once in YAML or a domain-specific language, and the layer compiles downstream queries into the right SQL against your warehouse, exposing models and APIs for governed access to structured data.
These same three properties are what make a semantic layer great for BI, and where it runs out of room for AI agents:
Those properties are exactly right for BI. They're also where the semantic layer stops. It nails business meaning, but something else has to decide what an agent actually sees at each step.
Redis Iris connects memory, live data, and retrieval in one place.
Governed SQL access is where the semantic layer ends, and it's right where agents need more. The same design that makes these tools great for dashboards leaves five gaps the moment you point an agent at them.
Agents search by meaning, not just exact matches, and SQL wasn't built for that. It's a set-based, relational language designed for structured, tabular data with exact-match or range predicates. Traditional SQL standards don't natively define embeddings, approximate nearest-neighbor search, or similarity scoring, though SQL-based systems can bolt those on. So semantic layers built on SQL generation usually lean on a separate retrieval system for anything unstructured.
The shortfall runs deeper than missing features. A GenAI app working over your business data also needs natural language synonyms, display rules, example queries, and domain-specific instructions that teach the model how to read that data. A metric definition alone doesn't carry that weight.
Agents need fresh data the moment they reason, not whatever last night's job loaded. Most BI semantic layers stay consistent by refreshing on a schedule, nightly or hourly, instead of pulling fresh data at runtime. Agents work differently: retrieval and context assembly happen live, during inference, and how you handle that directly shapes your end-to-end latency.
Agents reason across turns. Semantic layers don't remember a thing. They expose stateless APIs, so there's no conversation history, no working memory, no record of which tools the agent already called. When your agent needs to recall what the user asked three turns ago, a stateless layer has nothing to give it.
Consistent metrics help, but they won't stop a model from making things up. A semantic layer can hand an LLM well-defined numbers to query — it can't validate the output, constrain what gets generated, or catch a confident wrong answer. That's a job for other controls.
Most enterprise knowledge isn't in rows and columns. The semantic layer tools discussed here focus primarily on structured, tabular data, leaving text documents, images, audio, and other non-tabular content outside their scope. AI systems that reason across mixed structured and unstructured data need a layer the semantic model was never designed to provide.
Together, these limits point to a runtime context tier.
At runtime, a context layer manages what information an AI agent can access at each reasoning step during inference. It governs the population of the model's context window.
Context engineering fills the context window with the right information for the next step, including task descriptions, few-shot examples, retrieval-augmented generation (RAG), multimodal data, tools, state, history, and compaction. RAG is one component among several.
The context window has limited room, so something has to decide what goes in it at each step. That curation runs on every inference call, so it needs real infrastructure that handles retrieval, filtering, and state management in real time, not one-off glue code.
A context layer usually combines:
Together, these components turn context into a runtime system that goes beyond prompt assembly. Semantic definitions still matter here, but they sit inside a broader layer that manages what the model sees and when it sees it.
The two layers solve different problems under different constraints.
| Dimension | BI semantic layer | AI context layer |
|---|---|---|
| Primary consumer | Human analysts, BI tools | AI agents, LLMs, autonomous systems |
| Data scope | Structured data (SQL, warehouses) | Structured + unstructured (documents, PDFs, images) |
| Core function | Metric standardization, query translation | Governance, lineage, memory, permission filtering |
| Interaction model | Deterministic queries | Probabilistic reasoning, multi-step inference |
| State management | Stateless per request | Persistent session + long-term cross-session memory |
| Latency tolerance | Seconds to hours (warehouse refresh and analytics latency) | Real-time retrieval at every reasoning step, where retrieval overhead compounds across calls |
| Failure mode | Wrong numbers, visible and traceable | Confidently wrong autonomous actions, silent and consequential |
That last row matters because the failures look very different in practice. When a dashboard shows the wrong revenue number, someone notices. When an agent acts on stale or incomplete context, the failure can stay hidden and compound across later reasoning steps.
Redis Iris gives every agent fresh context and long-term memory.
When teams start wiring agents to real systems, the same failures show up fast. They usually come from treating context assembly as glue code instead of infrastructure.
Long-context performance often degrades as prompts grow, though the exact threshold varies by model and use case. In one production workload, tasks averaged around 50 tool calls, and every tool call appended new observations to message history, creating unbounded context growth. That growth forces teams to keep reworking how they shape, compact, and retrieve context.
Many teams assemble context from multiple systems that were never designed to work together: one store for vector embeddings, another for JSON, another for relationships, and another for transactions. This polyglot persistence approach can create separate security models, backup processes, scaling profiles, and more failure points across backing stores.
Pure vector retrieval often falls short in enterprise settings because users include exact product names, policy clauses, ticket IDs, and error codes. Semantic retrieval helps with meaning, while keyword retrieval helps with precision. A strong retrieval setup uses both, plus metadata filtering for tenant isolation, language, and recency constraints.
Context assembly needs a runtime layer that unifies those side systems.
Context infrastructure is a consolidation problem. Instead of stitching together separate stores for vectors, memory, caching, and features, teams are moving to a single runtime layer with one API surface.
Redis is a real-time data platform with sub-millisecond latency for core operations like caching and semantic cache hits, alongside the vector search that AI workloads depend on. The Redis context engine brings those capabilities together to serve fresh, relevant context for agent workflows at scale through five components:
Together, these components cover what a semantic layer doesn't: runtime retrieval, memory, freshness, and caching.
For production ML models, Redis Feature Form is a managed feature store for defining, versioning, orchestrating, and serving features across training and inference, keeping definitions consistent in both environments to reduce training-serving skew.
Redis Iris keeps agent data current so answers stay accurate.
A semantic layer gives you governed business meaning, but AI agents also need runtime context. Reliable agents need both layers working together.
The semantic layer solved a real problem by standardizing metrics across your organization, and that work still matters. Those governed definitions become one of the inputs your context layer uses to ground agents in business logic.
Agents also need vector search, multi-turn memory, real-time feature serving, and mixed structured and unstructured context. The Redis context engine brings vector search, semantic caching, agent memory, and data integration into one low-latency runtime, so AI agent infrastructure runs on a single platform rather than a patchwork of disconnected stores.
Try Redis free to see how the context layer works with your workload, or talk to our team about building context infrastructure for your AI agents.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。