Proposal: Evolve Feast into a Context Engine for AI Agents (Post 1.0) #5761
Description
Recent industry moves — Databricks acquiring Tecton to power real-time data for AI agents, Redis acquiring Featureform to deliver structured data into agents, and Hopsworks driving content explicitly on context engineering — signal a shift: feature stores are becoming context engines for GenAI and agentic systems.
Feast already has the core primitives (historical dataset creation, point-in-time correctness, online retrieval) to be a Feature Store and a Context Engine.
I propose that Feast 2.0 explicitly targets this role: an open-source context engine for AI agents.
Why This Matters
Instead of letting proprietary platforms own this space, Feast can be the vendor-neutral foundation for context engineering — powering both ML and agentic AI workloads.
Proposed Direction
- Add agent-oriented retrieval semantics (prompts, context windows, entity history, temporal snapshots).
- Strengthen low-latency real-time serving paths.
- Preserve existing ML feature-store workflows while broadening the abstraction toward “context”, not just “features.”
- Enhance the labeling mechanism so that features and context are more tightly coupled with labels
Request for Feedback
- Is broadening Feast’s mission toward “context engine” aligned with community needs?
- Which capabilities matter most for agentic workloads (latency, retrieval patterns, metadata/lineage, etc.)?
Some references:
Activity
woop commentedon Dec 9, 2025
There's clearly a massive market for vendors to sell into. It's not totally surprising that feature stores are being massaged into systems that support AI agents. That doesn't mean it's the right product move.
Instead of starting with the solution, then asking for feedback, let's start with the problem then figure out the potential solutions. Can you describe a specific persona (an ML engineer for example) and a use case, that is currently underserved?
That way we can look at the current options that exist for this persona, and whether we'd be bringing something new to the table.
jonzarecki commentedon Dec 14, 2025
@woop Great question - let me have a shot:
Persona: Platform engineer supporting multiple AI/ML teams in a regulated enterprise (banking, healthcare, government)
Underserved use case: Multi-tenant context retrieval for production AI agents with governance requirements
Specific problem:
These teams are building RAG systems and AI agents that need to:
What exists today:
The gap is specifically around governed, multi-tenant context retrieval for production agents — not just vector search, but structured entity data compliance built in. Ofc it sounds similar to the governance problems solved today by data catalogs and feature stores, just with a different twist + different ecosystem (more emphasis on vectorDB vendors).
Does this help clarify the problem space?
franciscojavierarceo commentedon Dec 18, 2025
The persona I personally want to address is the AI/ML Engineer who wants to use their existing feature store to serve "Traditional ML" and GenAI use cases. As @jonzarecki notes, this requires entity-based retrieval as well as vector similarity retrieval, which Feast supports.
I should note that I don't think we need to really expand the scope beyond retrieval. As mentioned in the issue, that's where Feast shines and I think it's valuable for us to continue to support those use cases.
For what it's worth, this is basicaly identical to what Uber's Feature Store has evolved to and they shared this blog post about it here.
woop commentedon Dec 20, 2025
Thanks for the detailed proposal and discussion. A few thoughts:
On the Uber reference: The blog you cited actually argues against this proposal. Uber stores embeddings in Palette (their feature store) but does vector retrieval in Lucene Plus (a search engine). They explicitly maintain separation of concerns. Feature store for data management, purpose-built search engine for ANN retrieval.
On the governance argument: @jonzarecki mentions vector DBs lack governance, but I'd like specifics. What governance capability does Feast have that Weaviate/Qdrant + Feast integration doesn't provide? Versioning? Lineage? RBAC? Modern vector DBs have multi-tenancy and access control.
On point-in-time correctness for embeddings: This is the classic feature store value prop, but does it apply to embeddings? You typically want the current embedding of a document, not "what was this document's embedding on January 5th." If there's a real use case for temporal embedding retrieval, I'd like to hear it.
What I think might be valuable: Entity-centric retrieval is a real pattern—"get structured features AND embeddings for entity X." But this doesn't require Feast to become a context engine.
Before expanding scope, can we use take the persona above and talk through a concrete query/flow? Specifically a query that can't be served by Feast + external vector DB, and also clarity on what "context engine" actually means beyond marketing.
jonzarecki commentedon Dec 21, 2025
@woop You're right to push back harder here. Modern vector DBs already have multi-tenancy, RBAC, and the governance capabilities I mentioned.
Let me refocus on what @franciscojavierarceo originally proposed: "Add agent-oriented retrieval semantics (prompts, context windows, entity history, temporal snapshots)" and "Strengthen low-latency real-time serving paths."
The actual distinction:
It's less about capabilities and more about retrieval patterns optimized for different workflows:
Traditional ML (static):
get_features(entity_id)Agentic AI (dynamic):
What's missing from Feast today for efficient agent navigation:
Entity-centric unified retrieval:
get_context(entity_id)that returns BOTH embeddings AND structured features for that entity in one callEfficient context navigation paths: Feast has some of it already.
Temporal context windows:
Optimized latency: Optimization of what already exists
The value prop:
A vendor-neutral foundation that makes it easy to enable agents to navigate the possible context space in low-latency - wherever it comes from.
This is also very much a documentation effort to show the usefulness of Feast, but considering the VERY big market for agent context I'd say it's worth considering to help Feast capture this opportunity.
jfw-ppi commentedon Dec 29, 2025
@jonzarecki I strongly agree on both optimized latency and the
get_contextspec. When proposing Feast to agent users, the feedback has consistently been critical of online latency.In real-world AI agent setups, many teams deliberately choose lightweight stores (e.g., Qdrant over Milvus) due to latency constraints.
If the design primarily optimizes for large-scale systems, it risks excluding a large segment of agent users who care most about fast, predictable context fetches.
If Feast aims to be a strong foundation for AI agents, optimized online latency must be treated as a first-class design constraint.
woop commentedon Jan 3, 2026
Let me work through the specific technical arguments, then explain where I think this goes wrong.
On the Uber reference
The Uber blog supports separation of concerns: they store embeddings in their feature store (Palette), then use Lucene Plus for ANN retrieval. Feature store for data, search engine for search. If the proposal is "Feast should store embeddings keyed by entity ID," we already support that. If it's "Feast should do ANN search," that's a different system. Which is it?
On point-in-time correctness for embeddings
This keeps coming up, but I'd like someone to articulate the actual use case. Point-in-time correctness matters for time-series features because the semantics change. A user's spending pattern last Tuesday is meaningfully different from today's.
But embeddings? If you re-embed a document, you typically want the new embedding. The document hasn't changed, your model got better. When would you need "what was this product description's embedding on January 5th"? If there's a real scenario, I'd like to hear it. Otherwise this is a theoretical capability without demonstrated demand.
On "agent-oriented retrieval patterns"
@jonzarecki described patterns like "get context for entity X, then find similar entities, then retrieve their full context." This is application logic. You can build this today!, you call Feast for entity features, call your vector DB for similarity search, call Feast again for the similar entities.
The question isn't whether this pattern is real. Of course it is. The question is whether it requires a new system or is just application code. I'd argue the latter. If we're wrong, consistent patterns will emerge from people building these applications, and then we can extract them into platform capabilities. Building a platform for hypothetical patterns is how projects lose focus.
On latency
@jfw-ppi raised real user feedback about latency. Valid, and worth addressing, as a performance goal, not a mission change. What latency targets? Which retrieval paths? That's engineering work. It doesn't require pivoting the project.
On unified retrieval
If the ask is "single API call returning structured features AND embeddings for an entity," does that need to live in Feast? You can write a thin wrapper that calls Feast for structured features, calls your vector DB for embeddings, and merges the results. That's maybe 20 lines of code and keeps your concerns separated. You can parallelize the calls if latency matters.
If someone wants to propose this as a Feast feature anyway, then please write up the API and storage implications and we can assess it in isolation. But I'm not even convinced it belongs here rather than in application code.
On vendor acquisitions
Databricks acquired Tecton, Redis acquired Featureform. What are those teams actually building now? From what I can tell, the acquisitions were about real-time serving infrastructure and enterprise positioning, not "context engine" capabilities. Acquisitions tell us about corporate strategy, not user demand. I'd weight one GitHub issue from a user describing a problem they can't solve higher than three vendor press releases.
Where I land
I keep asking the same question: what specific problem can't be solved with Feast + existing tools today? The responses have been:
If I'm wrong, show me. A user with a workflow that fails today. I'll take that seriously. But "vendors are calling this context engines now" isn't a problem statement, it's marketing following marketing.
What I'll support: documentation showing how Feast serves agentic workloads today, latency improvements with specific targets, a unified retrieval API if someone specs it as a concrete feature, and any real user requests that demonstrate gaps.
What I won't support is butchering/pivoting the project to follow hype. If this is about serving users better, let's talk about specific features. If it's about positioning against vendor marketing, I'd rather compete on capability than terminology.
@franciscojavierarceo I'd love to hear from you next, since you opened this up.
franciscojavierarceo commentedon Jan 8, 2026
The Uber reference was more just outlining how these things are increasingly intersecting. I think it's fine for a Vector DB to be separate but it's also fine to be connected. Feast supports vector retrieval as @HaoXuAI and I added that functionality. More generally, databases are increasingly offering ANN search as another retrieval mechanism and I think it makes sense to exist in Feast.
Actually, I spent several conferences in 2025 talking about exactly that (including KubeCon, specifically for fine-tuning).
Agreed.
I'm not really advocating for changing our existing patterns but more expanding those we offer.
As mentioned, we actually do support this today (vector search is technically an alpha feature).
That's a reasonable point, I don't quite discount corporate strategy as heavily as I think it's a proxy for demand and where the market is moving.
I'm comfortable with this. I do think supporting Prompts and Search should be considered as well.
Agreed, I don't want to butcher the project or pivot away from its core focus. I think there's a key area where feature stores are critical for fine tuning. This is consistent with how I feel about RAG and Fine Tuning (you can see my talk on it here) but my goal was to extend this to fine tuning context more broadly.
I don't think Feast needs to be overly-involved in agent systems, but I do think it has a role to play in supporting fine training.
jonzarecki commentedon Jan 19, 2026
The way I see it we're treading the same path that created Feature Stores
Feature Stores emerged because Data Scientists needed governed, versioned, low-latency access to data for ML. Now we're seeing the SAME pattern for Agents — they need governed, versioned, low-latency access to context for inference.
This isn't a pivot. It's recognizing that the infrastructure requirements are nearly identical.
The Parallel:
Human Data Scientists:
AI Agents:
The difference is scale + latency:
Feast already solves the core problem: governed multi-source retrieval with versioning and real-time serving.
What We Need:
Bottom line:
I see this as "show how Feast serves the full AI lifecycle" - from training data (fine-tuning) to inference context (agents) to traditional ML (what we already do). Same infrastructure, different consumption patterns for the different emergent users.