Context Engineering 2.0
Simba Khadder explains the evolution of feature stores and MLOps, detailing why they remain crucial in the age of LLMs for high-scale use cases. He discusses the acquisition of his company, Featureform, by Redis and outlines their new vision: building a "Context Engine" for AI. This engine aims to unify structured data, unstructured data, and memory into a single pane of glass, moving beyond simple RAG to a more sophisticated "Context Engineering 2.0" that empowers agents with rich, queryable context.
The State of MLOps and Feature Stores
The original MLOps vision of having models everywhere was ultimately realized not by complex MLOps frameworks, but by the accessibility of large language models (LLMs) through simple APIs. LLMs significantly lowered the barrier to production, making it feasible to deploy AI without extensive training or infrastructure. As a result, the return on investment for a full, dedicated MLOps team is now most clearly justified in specific, high-scale use cases like recommender systems and fraud detection, where incremental improvements in model performance directly translate to revenue.
Feature stores are far from dead; in fact, they are seeing a resurgence. After an initial hype-driven phase, companies are now confronting the real-world pain of managing features at scale. The high maintenance cost and complexity of homegrown solutions are driving a new wave of adoption for mature, off-the-shelf feature store products.
Featureform Joins Redis: A Strategic Alignment
The acquisition of Featureform by Redis is presented as a natural “DNA match.” Both companies share a deep-rooted focus on developer experience, usability, and creating tools that developers love. The Featureform product and team will continue their mission, now with the backing and resources of Redis, as part of a broader strategy to evolve Redis into a comprehensive AI and ML data platform.
Redis’s strategy is not to create vendor lock-in but to compete on merit. Featureform will continue to support various online stores (like Cassandra), enabling a fair comparison. The goal is to make it easy for users to try Redis and see for themselves that it offers the best performance and capabilities as an online store. This is described as a good-faith “Trojan horse” strategy.
Context Engineering 2.0: Beyond RAG
The biggest engineering challenge in building powerful AI agents isn’t the model’s intelligence, but the quality, relevance, and accessibility of its context. This is the core idea behind “Context Engineering 2.0.” This vision extends far beyond the common definition of Retrieval-Augmented Generation (RAG), which is often narrowly viewed as simple vector search over text chunks. The real problem is optimally filling an agent’s limited context window with the most insightful information from all available data sources.
Effective context engineering requires unifying three key data types:
- Unstructured Data: The traditional domain of RAG (e.g., documents, text corpuses).
- Memory: State and history, such as a user’s previous interactions.
- Structured Data: Information from relational databases and other tabular sources.
The goal is to create a unified semantic layer—what Simba Khadder calls a “GraphQL for agents”—that connects these disparate sources. This would allow an agent to intelligently navigate and query for the precise data it needs, rather than relying on a one-shot dump of potentially irrelevant information into its prompt.
The Redis Context Engine
To realize this vision, Redis is developing a “Context Engine” to serve as a single pane of glass for all agent context. This engine is an evolution of Featureform’s open-source enrich-mcp project, now supercharged by the full Redis ecosystem, including its vector database, caching, and flexible data structures. The approach is “data-first”: developers define their data schemas, entities (e.g., users, products, orders), and the relationships between them in Python. This process creates a navigable knowledge graph that the agent can access via tool calls. This is a more sophisticated pattern that empowers the agent to pull the data it needs when it needs it, fully leveraging its reasoning capabilities.
Demystifying MCP and Agentic Architecture
MCP (Model-Callable Procedures) is demystified as, fundamentally, a standard for moving tools to a remote server. Its real power lies in the industry-wide standardization, which enables interoperability between models from different providers like OpenAI and Anthropic. This standard facilitates a clean architectural separation between three core components of an agentic system:
- The Agent Workflow: The orchestration layer that defines the agent’s logic and reasoning process (e.g., using a framework like LangGraph).
- The Context Workflow: The data and tools the agent can access, served via MCP endpoints provided by the Context Engine.
- The LLM Workflow: The underlying language model itself.
This separation allows teams to build and maintain context sources independently of the agents that consume them, a scalable pattern analogous to microservices or the separation of storage and compute.
The Redis AI Platform in Action
Redis is leveraging its core assets—unmatched speed and developer-friendly abstractions—to build a platform for the AI era. Key components include:
- Vector Database: Redis’s vector search capabilities power modern RAG pipelines and are also critical for traditional ML use cases like recommender systems (e.g., candidate generation in two-tower models), which remains a major revenue driver.
- LangCache: A smart caching layer designed to reduce LLM token costs. It uses vector search to identify and serve cached responses for semantically equivalent queries, while being sophisticated enough to handle negations and differing entities (e.g., distinguishing “weather in San Francisco” from “weather in San Diego”).