feast-dev
Proposal: Evolve Feast into a Context Engine for AI Agents (Post 1.0)
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:
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.
@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:
- Retrieve customer/entity-specific context at inference time (account history, patient records, citizen data)
- Support hundreds of concurrent agents serving different users/tenants
- Work in air-gapped or on-prem environments (data residency requirements)
- Enable RBAC and data governance
What exists today:
- Vector DBs (Pinecone, Weaviate) → solve semantic search but not structured entity context retrieval with point-in-time correctness
- Proprietary platforms (now Databricks+Tecton, Redis+Featureform) → vendor lock-in concerns for enterprises
- Ad-hoc caching layers → no lineage, no versioning, no governance
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?
