# Real-time features, AI search, Agentic similarities

Varant Zanoyan & Nikhil Simha Raprolu, Zipline AI | MLOps Podcast | Episode 354 | 29:28
Hosted by Demetrios Brinkmann

Source: https://www.youtube.com/watch?v=kmcYPvLynKo
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/real-time-features-ai-search-agentic-similarities
Published: 2026-02-02
Tags: data-engineering, embeddings, feature-engineering, feature-stores

## TL;DR
- Chronon focuses on computing features correctly across streaming, batch, online inference, and offline training instead of treating a feature platform as storage around a key-value store.
- Real-time ML becomes difficult when teams must combine Spark, Flink, Airflow, indexing, and serving for every signal, so Chronon exposes the user's data transformation while managing those systems underneath.
- The same infrastructure can power agent context and embeddings, including customer-support policies, conversation intent, user activity sequences, and search workflows.

## Summary
Varant Zanoyan and Nikhil Simha Raprolu explain why Zipline AI is building around Chronon, an open-source system that grew from Airbnb's fraud and search problems and was later tested with Stripe. Their argument is that computing features correctly is the difficult part of a feature platform. Teams need point-in-time-correct training data, consistent online and offline results, streaming aggregations, orchestration, indexing, and low-latency serving. Chronon hides much of that complexity behind a simpler data-transformation interface. The conversation then moves upstream into ingestion, Iceberg, catalogs, and data governance. The guests also describe how the same approach supports AI agents. Airbnb used Chronon to assemble customer-support context and to support search agents. Embeddings add another type of transformation, with message history and user activity turned into vectors for retrieval, recommendations, and personalization. The guests are candid that making these systems easy to adopt requires years of experience with the underlying infrastructure.

## Key ideas
### Chronon computes and serves features across the full training and inference path
[00:51](https://www.youtube.com/watch?v=kmcYPvLynKo&t=51s)
Nikhil explains that Chronon differs from feature stores that leave computation to users and mainly provide storage. Chronon takes raw data, computes features, serves them online for inference, and serves them offline for training. It also aims to keep those two versions consistent. The user writes an accessible description of the desired transformation while the platform handles the underlying systems. The guests connect this design to the adoption of the open-source project. Their view is that computation was the part of feature engineering that caused the most trouble, especially for streaming features and aggregations.

### Airbnb's fraud problems exposed the cost of building every signal by hand
[02:09](https://www.youtube.com/watch?v=kmcYPvLynKo&t=129s)
Nikhil says the early Chronon work at Airbnb came from a fraud team's need to create and test signals quickly. Fraud changes as attackers find ways around existing systems, so the team needed to move quickly. A simple signal, such as how often a user used a credit card or an IP address over a recent period, required batch processing with Spark, stream processing, indexing, orchestration with Airflow, and a path into both the application and model training. Demetrios points out that teams may need hundreds or thousands of such signals. The guests describe this as a large amount of engineering for each small piece of information.

### Search and product metrics showed that the same real-time data problem exists outside ML
[06:20](https://www.youtube.com/watch?v=kmcYPvLynKo&t=380s)
Varant says search personalization became the next major Chronon use case at Airbnb because it depends on high-volume, real-time data. Other teams then adopted the system for product-facing metrics. The displayed average rating for an Airbnb listing, for example, could be computed with a windowed aggregation so older activity fell out of the calculation. That team replaced a complicated Flink job with a data source, a time window, and an average. Varant says the change reduced the time needed to get the workflow running from months to a couple of days. The guests saw this as the same data-engineering problem appearing in a different product.

### Chronon was open sourced after joint work with Stripe made the system easier to trust
[05:45](https://www.youtube.com/watch?v=kmcYPvLynKo&t=345s)
The guests clarify that Chronon's open-source release was done in collaboration with Stripe, after a close partnership lasting six to eight months. Stripe already had experience with Flink and Spark, yet setting up Chronon was still difficult. That experience showed the Zipline AI team that the product needed to hide more of the underlying infrastructure. Airbnb and Stripe gave the team environments where it could make mistakes, test the design at scale, and improve it before releasing it publicly. Varant says that this history helped them release something that worked in two different companies rather than only inside its original environment.

### Point-in-time-correct training data is one of the hardest parts of real-time ML
[13:33](https://www.youtube.com/watch?v=kmcYPvLynKo&t=813s)
Nikhil describes point-in-time correctness as a central technical problem. Companies have historical observations and labels, such as a card payment later identified as fraud. When a new feature is proposed, the system must calculate that feature using only the data available at each observation time. A straightforward SQL approach can repeat an aggregation for every historical observation and become too expensive quickly. Nikhil says this difficulty pushes teams toward batch features. The broader issue is that AI and ML workflows cross streaming, batch, online serving, inference, and training, while the underlying data tools were designed around separate reporting and pipeline tasks. Teams often end up connecting those systems themselves.

### Zipline AI is moving upstream into ingestion, Iceberg, and governance
[18:04](https://www.youtube.com/watch?v=kmcYPvLynKo&t=1084s)
Varant says customer work has drawn the company toward governance, data privacy, and confidence in systems that support important use cases. They are also working on earlier parts of the data path as teams move toward Iceberg and open-source infrastructure. Nikhil describes the practical difficulties: moving data from an event bus or online database into S3 or GCS, creating Iceberg files, choosing a catalog, making the data work with existing systems such as BigQuery, and using an engine that can take advantage of Iceberg optimizations. The guests want Zipline AI to make this process easier, first for existing Pub/Sub data and eventually through a library that can log data and create the warehouse underneath.

### Agent context at Airbnb was built from the same kind of data transformations as features
[23:55](https://www.youtube.com/watch?v=kmcYPvLynKo&t=1435s)
Nikhil says Airbnb used Chronon for customer support, where an agent needed the right context before an LLM could respond. The workflow gathered information from across the organization, including what a user had done recently and which policies applied. He describes this as feature engineering under the newer name of context engineering. A search agent was another use case, helping users decide where and how to travel. These workflows could use Chronon to drive the pipelines, indexes, and endpoints that supplied context. The guests' point is that agent systems still depend on reliable, timely data preparation even when the final consumer is an LLM.

### Embeddings extend the platform from structured features into retrieval and personalization
[26:24](https://www.youtube.com/watch?v=kmcYPvLynKo&t=1584s)
The guests describe two embeddings in an Airbnb support example. Policy documents are chunked, embedded, and stored in a vector store. A conversation's changing intent is also captured as an embedding. The system matches the conversation intent with policy content using a dot product, then supplies relevant information to the LLM. Chronon can treat a window of message history as a transformation and pass it to an embedding model. The same pattern applies to user activity sequences, where recent activities become a user embedding for recommendations or personalized experiences. Varant says native embedding support is being added to the open-source project so teams can combine features and embeddings in one workflow.

## Notable quotes
- Nikhil Simha Raprolu: "What we saw and the reason why we built Chronon is that compute was really the hard thing that people struggled with." (01:07)
- Nikhil Simha Raprolu: "It's like the actual workflows for AI and ML, they cross these boundaries of streaming and batch, of online serving, of inference and training." (15:16)
- Nikhil Simha Raprolu: "Context engineering is what they call it now, but it's basically features." (25:05)
- Nikhil Simha Raprolu: "What you're trying to do is essentially like take this intent side and match it with the policy side." (27:21)

## Tools & references mentioned
- Zipline AI
- Chronon
- Airbnb
- Stripe
- Spark
- Flink
- Airflow
- Feast
- Feather
- Iceberg
- S3
- GCS
- BigQuery
- Pub/Sub
- Kafka
- LangChain
- LLMs
- RAG

## Who should watch
- You are choosing between a feature store and a broader system that computes, orchestrates, and serves data for real-time ML.
- Your team has built separate batch, streaming, indexing, and serving pipelines and wants to understand why point-in-time correctness remains difficult.
- You are building agent or retrieval workflows and need to turn message history, policy documents, or user activity into timely context and embeddings.

## Related talks

- [Chronon: Airbnb's Open-Source Data Platform](https://mlopstalks.com/talks/chronon-airbnbs-open-source-data-platform) (, 12:35)
- [Scaling Real-time Machine Learning at Chime](https://mlopstalks.com/talks/scaling-real-time-machine-learning-at-chime) (Peeyush Agarwal, Chime, 24:22)
- ["Real-Time" ML: Features and Inference](https://mlopstalks.com/talks/real-time-ml-features-and-inference) (Sasha Ovsankin & Rupesh Gupta, LinkedIn, 51:55)
- [Data Engineering: The Missing Piece of Your Data Science Puzzle](https://mlopstalks.com/talks/data-engineering-the-missing-piece-of-your-data-science-puzzle) (, 12:10)
- [Context Engineering 2.0](https://mlopstalks.com/talks/context-engineering-2-0) (Simba Khadder, Redis, 45:34)