RAG, memory, and structured data should be exposed through one context layer that agents can navigate.
2
Direct Text-to-SQL access and automatic API-to-MCP wrapping create security, performance, and tool-use problems.
3
A semantic schema gives agents a controlled model of business entities, relationships, and data access paths.
Summary
Simba Khadder argues that agents need one unified context surface instead of separate systems for RAG, memory, and structured data. RAG works well for documents, PDFs, and knowledge bases, while memory stores short-term conversation state and longer-term preferences. Structured data is harder to expose safely. Khadder criticizes direct Text-to-SQL access because generated queries can be wrong, expose sensitive data, hurt performance, or be manipulated through prompt injection. He also questions wrapping every REST endpoint as an MCP tool because this creates too many tools, consumes tokens, and forces agents to reason about low-level parameters. His proposed approach starts with a semantic schema for business entities such as customers, orders, and items. The schema becomes navigable through MCP, allowing agents to explore relationships and retrieve controlled materialized views. Khadder presents Redis Context Engine as a unified access layer for structured data, unstructured data, and memory, while acknowledging that the product is still at a design-partner stage.
RAG handles documents, but agents also need other kinds of context
Khadder describes unstructured data as the documents, PDFs, help centers, and knowledge bases that companies need to make available to agents. RAG usually chunks these documents, stores them in a search or vector database, creates embeddings, and performs a nearest-neighbor lookup. He says vector databases remain useful, while noting that production retrieval often combines several search methods to find relevant context. RAG addresses textual corpora well, but it does not provide a complete way to access structured data or agent memory.
Memory keeps both conversation state and longer-term preferences
Khadder separates memory into short-term and long-term forms. Short-term memory keeps recent conversation context so the model does not have to reread every previous message. Long-term memory stores information that may matter across conversations or tools, such as a user's preference not to use em dashes. He connects Redis's memory capabilities to the same need for fast, usable context that drives retrieval systems.
Direct Text-to-SQL access gives agents too much responsibility
Khadder calls direct Text-to-SQL access to databases a dangerous approach. Generated SQL can be syntactically wrong, but he considers that the least serious problem. Internal databases contain similarly named tables and columns whose meaning depends on company-specific knowledge. Agents also face access-control and security risks when they query production data, and prompt injection could push them toward expensive or recursive queries that consume database resources. His conclusion is that agents should not receive unrestricted database access.
Wrapping every API endpoint as an MCP tool creates tool bloat
Khadder criticizes the pattern where every API endpoint becomes an MCP tool and every parameter becomes a tool parameter. Enterprise APIs often have many endpoints and parameters designed for human developers who understand their nuances. An agent has to read and reason about those tools within its context, which wastes tokens and often leads to loops, failed calls, and difficult API chaining. Authentication mapping from OpenAPI or REST APIs to MCP also adds work. He says these APIs are too low-level for how agents need to reason about data.
A semantic schema gives agents a business-level model to explore
Khadder proposes defining entities such as customers, orders, and items, along with their attributes and relationships. This schema becomes an MCP server, but the protocol is less important than the data-first model behind it. Instead of exposing separate tools such as get customer and list customer, the system describes what a customer is and how it relates to other entities. Agents can then understand the data model, explore it, and retrieve information through relationships rather than selecting from a large collection of low-level operations.
Agents can retrieve structured data by exploring relationships
Khadder shows an example in which an agent looks for fraudulent transactions. The agent first explores the available data model, then lists orders and follows relationships to items and users. This gives it a path through the data instead of requiring a single large query or a manually chained set of API calls. He describes this as making the semantic catalog navigable and retrievable through MCP.
Context engineering joins structured data, documents, and memory
Khadder says the main problem for agents is getting the right data in front of a model that already knows a great deal in general. Companies have unstructured data, structured data, and user-related memory, but these surfaces usually remain separate. A unified context engine could connect APIs, data warehouses, user inputs, documents, and memory, then let an agent retrieve and navigate the information needed for a task. Redis's proposed layer combines RAG, long-term memory, short-term memory, and structured-data retrieval.
Materialized views provide control over access and observability
In the questions, Khadder compares the proposed context layer with materialized views. The system can control which data appears in a view, instead of allowing an agent to discover arbitrary tables. This limits accidental exposure and reduces the chance that an agent finds a way around an internal restriction. A single access layer also makes observability easier because context retrieval passes through one place. Khadder says Redis is adding OpenTelemetry hooks to Enrich MCP and describes Context Engine as being in a design-partner stage.
Feature stores and context systems will continue to coexist
Khadder gives a theoretical and practical answer about feature stores. In theory, feature engineering and context engineering both create useful signals for models. Classical ML models expect inputs in a particular form, while language models ultimately receive text or tokens. In practice, he sees different platform needs. Context engineering emphasizes the semantic layer, while feature stores often emphasize the ETL layer. Recommender systems and fraud detection will continue to use classical models and feature stores, even as companies adopt context systems for agent workflows.
"The problem that we actually have now is how do we get the right data in front of it to enable it to actually do the right thing and do something useful."14:14
Who should watch
You are building an agent that needs access to internal databases, APIs, documents, and user history without exposing raw production systems.
Your current MCP integration mirrors an existing API and has produced too many tools, parameters, or chained calls for agents to use reliably.
You run feature stores and classical ML systems and want to understand where a semantic context layer might fit alongside them.
