Simba Khadder argues that the main engineering problem in agents is giving language models the right context, rather than making the models themselves more capable.
2
Feature stores still have a strong business case in recommendation and fraud systems, especially when they operate at scale and affect revenue directly.
3
Redis Context Engine aims to give agents one interface for structured data, unstructured data, memory, APIs, and other MCP servers.
Summary
Simba Khadder explains why he does not see feature stores as obsolete after Featureform joined Redis. MLOps has worked best where model quality has a direct link to revenue, such as recommendations and fraud detection, and companies are now returning to feature stores after learning the cost of maintaining internal systems. He describes Redis as moving beyond its database and cache identity toward a data platform for ML and agents. His main focus is context engineering. RAG is a useful starting point, but agents increasingly need to retrieve structured records, documents, and memories through connected relationships. Khadder proposes a context engine that gives agents a controlled, navigable view of available data, with MCP as an access mechanism. He prefers a data-first design, where schemas and relationships define the tools, rather than hand-written tools that each expose isolated queries. Agents should retrieve information when they need it instead of receiving large prompt dumps.
MLOps has worked where model quality maps directly to revenue
Khadder says the original promise of MLOps was that applications would use very large numbers of models. Language models reached production more easily because pretrained transformer models could be called through an API without each company training its own system. He sees dedicated MLOps investment working most clearly at scale, especially for recommendation systems and fraud. Better recommendations can lead directly to more money, while better fraud detection prevents losses. These systems often run across every user or transaction, which makes the operational cost easier to justify.
Feature stores are gaining demand after teams felt the maintenance cost
Khadder says Redis is seeing some of its strongest demand for feature stores, including companies building new stores and replacing existing ones. He attributes this partly to maturity. Early teams often built their own systems because the concept was new, then later discovered the ongoing maintenance burden. Customers now understand that a feature store is more than a Postgres database. They are asking for one because they feel a concrete operational problem and can connect solving it to real return, rather than adopting the idea because it appeared in industry discussions.
The Featureform acquisition worked because the teams and product fit
Khadder describes the acquisition as more intensive than raising a funding round, although the exact experience depends on the deal. He says Featureform and Redis had a strong match in their focus on usability and developer experience. The Featureform team joined Redis together, and the product continues with more resources. He also says the relationship with the acquiring company's internal champion matters, much as the relationship with a venture investor matters during fundraising. In his view, Featureform can now continue its feature-store work while expanding toward a context engine.
Redis wants to offer a full feature-store solution while keeping integrations open
Redis has traditionally provided the online store used by feature-store systems, while Featureform could work with different compute and storage choices. Khadder says Redis now wants to meet customers who are already trying to build a feature store and offer a solution integrated with Redis. Featureform will still support other online stores, including Cassandra, because Redis wants to win through cost, speed, and product merit rather than by blocking alternatives. He describes this approach as making it easier for customers to compare systems without first paying a large migration cost.
Context is broader than the usual vector-search version of RAG
Khadder says RAG is often reduced to finding nearby chunks in a vector database, but the underlying problem is filling a limited context window with information that helps a model solve the task. Chunked text retrieval is a surprisingly effective baseline, yet agents also need memory and structured data. A support agent answering why an order is late may need to find an order in Postgres and combine it with related information from documents or other systems. He groups the needed sources into unstructured data, memory, and structured data, which are commonly handled by separate systems that do not understand each other.
A context engine should give agents a connected view of data
Khadder imagines a context layer that connects documents, memories, structured records, APIs, and MCP servers. A memory could be associated with a document, while a database row could point to relevant text. He compares the interface he wants to GraphQL for agents, because agents can use the available relationships and retrieve the information needed for a task. The developer defines the data model, descriptions, and relationships in Python. The agent then receives a controlled surface through which it can discover what data exists, understand how it relates, and request the required parts.
Agents should retrieve data through interfaces instead of receiving prompt dumps
Khadder argues that many systems send too much data to an agent because they do not know how to expose structured information. Dumping a whole CSV or a large JSON object into the prompt increases the context burden. For many tasks, the agent should have an interface that lets it find information when needed. This also applies to code generation. If an agent invents a function or uses the wrong coding style, Khadder sees the missing context as the likely issue. The system needs to provide the repository conventions, available APIs, and relevant information without placing the entire codebase in every prompt.
MCP separates agent logic from reusable context services
Khadder describes MCP as a standard way to move tools into remote servers, with discovery and other concepts that are absent from ordinary REST APIs. At enterprise scale, teams can maintain MCP servers for data and tools while multiple agents connect to them. This separates the agent framework, which controls behavior and orchestration, from the context layer, which provides access to data, APIs, and other MCP endpoints. A new data access capability can then be updated in one service instead of requiring changes across every agent. He compares this separation to separating storage from compute.
