Inside Bilt's Live Context Layer: Real-Time Data for Apps, Offers, and Agents

Bilt's live context layer in Materialize transforms siloed data across hundreds of microservices into continuously updated context in real time. A lean engineering team now ships product features in days instead of months, and their AI concierge runs on smaller, less-expensive models because it has instant access to fresh, trustworthy context that can be discovered and assembled in milliseconds.

Bilt is the membership for where you live and the neighborhood operating system powering the residential ecosystem around it. Bilt's AI concierge answers member questions, takes actions like booking restaurants or making appointments, and handles account issues — with the goal of making the agent the primary way members interact with the product. Behind it all, the engineering organization operates hundreds of microservices, with a central data warehouse supporting everything from internal reporting to customer-facing portals. As Bilt set out to deliver real-time experiences to merchants and scale its AI initiatives, that architecture hit a wall: the warehouse was an hour behind, and point-to-point integrations across hundreds of services couldn't scale.

Bilt's answer was to build a live data ecosystem consisting of canonical data models and standardized event streams, centered on a context layer powered by Materialize. A context layer is a shared library of composable, real-time data products — designed for consumption not just by applications and analysts, but by agents. Bilt models every member, merchant, and interaction. The data team uses SQL to define, compose, and query data products, which Materialize keeps continuously up to date as source data changes. End-to-end data freshness went from about an hour to ~1 second, while query latency dropped from up to two seconds to single-digit milliseconds.

The data team can query and combine existing data products just using SQL, and they build and deploy new ones through their existing SDLC process. That context layer is now the live data foundation that powers Bilt's AI concierge, their real-time audiences and offers orchestration engine, as well as a unified vector search index that is up-to-the-second fresh. Because this foundation provides fresh data that's already in the exact shape required — and because the Materialize object catalog and dbt's granular documentation provide implicit semantic links between these objects as well as business context — the AI concierge doesn't spend tokens reassembling records into a usable form, figuring out how data is related, or reasoning over stale context. As a result, Bilt can run most concierge queries through smaller, faster, and less expensive models and get the same quality that top-tier frontier models would produce.

Bilt is the membership for where you live — a neighborhood operating system serving more than 7 million members through a network of more than 50,000 merchant partners. The home is the anchor — members earn points on housing payments, their largest recurring expense, and on everyday spend at neighborhood merchants using the Bilt card or any card linked to their Bilt app. Those points flow back into dining, travel, fitness, pharmacy, and more, creating a flywheel between properties, merchants, and residents: more homes bring more resident spend to local merchants, and more merchants make the network more valuable to every property and member. Members interact with the platform through the main member app and a recently launched AI concierge that not only answers their questions but also takes actions on their behalf. Meanwhile, merchant partners can use Bilt's partner web portals and mobile apps to process payments, manage customer data, target customers with relevant and timely offers, and get real-time insights into their business performance.

Bilt's ambition has long been to provide real-time experiences across the platform. This included targeted offers that can fire on real-time member activities, such as arriving at a partner location, crossing a spending threshold or even ordering a certain item at a restaurant, plus live metrics for merchants on how those offers were performing. Merchants can send personally customized offers to the right members at precisely the right time, while members benefit from offers that better align with their interests, giving Bilt a differentiated real-time product that competitors can't match.

In parallel, Bilt continues to focus on AI across every part of the business. In addition to having launched an AI concierge in the consumer app, they've also been scaling the B2B version starting with dining partners and property managers. As the team scoped each new AI feature, though, they kept running into the same problem: pulling together live data about members, merchants, and their interactions across Bilt's many services was adding complexity and slowing the team down.

Both initiatives had the same core need: up-to-the-second data, joined and transformed into the exact shape that apps and agents needed.

"As members go about their day, we can identify the offers they're eligible for and trigger them instantly — nationwide, in real time."

— Kosta Krauth, CTO, Bilt

Bilt's initial stack consisted of a microservices architecture, backed by operational databases, and a central data warehouse. Their microservices exposed APIs that other services and applications could call directly for data, while the warehouse periodically integrated those data sources and served internal reporting, analytics, and the merchant-facing portals. For the real-time offers and merchant telemetry Bilt wanted to build next, though, neither of these existing paths could get the data where it needed to be in the right shape or at the right time.

The warehouse had all of Bilt's data joined and integrated in one place. But the data pipelines feeding the warehouse ran on batch schedules and so the data itself could be an hour or more stale. A second, compounding problem was that queries on this processed data were slow, taking up to two seconds in some cases; this was fast enough for reporting but not for customer-facing apps, portals, and ultimately agents. Both issues were already impacting other internal teams: Bilt's product marketers, for example, relied on the warehouse for segmentation data. Stale data meant offer notifications could go out to members already ineligible, or miss ones who had just qualified.

In this architecture, getting data — and ultimately context — that was both fresh and fast to query relied on the application calling every microservice API it needed and assembling the data at request time. But that would mean point-to-point API integrations across hundreds of microservices. Consider a single dining offer for a member who visited a partner restaurant last week: it needs member data, visit history, offer eligibility, and merchant data — each from a different service. Every feature meant a new set of integrations, and every team was rebuilding what another team had already built. Neither path could deliver the live, joined context that both the merchant tools and the AI features Bilt was scoping needed.

Bilt's AI concierge feature was already a hit, but bringing AI to other parts of the platform was another challenge. LLM costs were high because models had to reason through raw operational data to create their own context, and even significant cost optimizations weren't enough to make future AI features financially feasible. Providing agents with pre-transformed, real-time data would unlock the ability to scale their AI offerings.

"Getting all those attributes in one place meant point-to-point integrations across hundreds of services. That's slow, manual, throwaway work — every team rebuilding what another team already built."

— James Dorado, VP of Data, Bilt

Ultimately, the team needed to minimize the time between an event happening in the real world and when it was reflected throughout all of their context and data API surfaces. There were two ways to do this: reducing query response time, and improving underlying data freshness. End-to-end latency of about a second, the team felt, would make the entire platform feel interactive.

To improve data freshness, the team explored building a real-time data pipeline on a stream-processing framework that integrated directly with their microservices and source systems. This would give them the ability to emit events the moment source data changed, so real-time offers could fire the instant a member qualified. They committed to a thorough evaluation over a few months, designed to test building a pipeline, deploying it, and running it in production. However, they found the framework was slow to build with and cumbersome to change; the pipelines were hard to observe in production; and their existing dbt models would need to be duplicated in code. This wouldn't let Bilt move at the speed they wanted, and they knew they needed a different approach.

"After a few months we killed the streaming pipeline approach. The framework worked; our velocity didn't."

— Kosta Krauth, CTO, Bilt

Reducing query latency required serving transformed data to the merchant portal faster than the warehouse could. The team initially considered adding a real-time OLAP database in front of the warehouse as an ultra-fast query layer, populated on a batch schedule. In practice, though, the OLAP database couldn't reliably deliver query latency below the same 500 milliseconds the warehouse already offered and the batch export from the warehouse to the OLAP database added complexity and increased data freshness lag, negating the goal of the exercise.

These two unsuccessful explorations did, however, give Bilt a clear picture of exactly what they did need. First, they needed to pull operational data from their microservices and then join and transform it, in real time, into the shape their traditional and AI features needed. Second, they needed to be able to either query that data on demand or stream it out to downstream systems as events. Finally, they needed to be able to do all of this quickly and easily with their existing engineering and data teams, without hiring for more streaming specialists.

The team chose Materialize as the incremental compute engine at the center of that design. Bilt would subscribe to each microservice's underlying Postgres database via native CDC, define joins and transformations as dbt models — the same governed workflow the data team already ran — and let Materialize incrementally update results the moment source data changed. Applications and agents query those views like a standard Postgres database; downstream systems subscribe to changes over Kafka. And because everything is SQL — a lingua franca the entire engineering and data org already speaks — the team could build on the dbt models they already had.

Bilt runs Materialize self-managed, deployed and operated by its platform team entirely inside Bilt's own GCP VPC. For a platform handling payments and sensitive member data, that was a deliberate architectural choice: every byte of the context layer lives within Bilt's security perimeter, subject to the same network controls, IAM policies, and compliance posture as the rest of the stack — with no data ever leaving their cloud.

"We can control the world in SQL, using familiar technologies like dbt. We can have sub-second freshness rather than an hour. And we can have query latencies in single-digit milliseconds."

— James Dorado, VP of Data, Bilt

Bilt set out to build a live context layer: a shared set of composable, real-time data products accessible to the whole organization, with the ability to add semantic links between them. Each data product would represent a core business entity, like a member, a merchant, an offer, or a reward, that together formed Bilt's 'canonical data model', or CDM. Every application, service, or AI agent could then use these same definitions, rather than individual teams needing to re-implement or duplicate them.

These data products would be built up using a real-time, three-tier medallion architecture: a Bronze layer for initial cleaning and transformation, a Silver layer for shared intermediate views, and a Gold layer for the final entities made available for consumption. The entire structure is also internally consistent: a change is reflected across all layers at any point in time, so a query joining two views mid-update gets one coherent answer — never a torn read where a transaction shows up in one view but not another. That correctness becomes an important primitive for building high-trust AI applications: agents can act on what they read without second-guessing whether the world shifted underneath them.

The data team would own the CDM. They'd write and manage the data product definitions in SQL and dbt, keeping the governed, version-controlled workflow they already had in place for their existing data warehouse. Materialize would plug into that workflow as a dbt adapter, letting Bilt deploy real-time data products with blue-green rollouts for zero-downtime updates.

Under the hood, the team wired Materialize into the Postgres databases powering Bilt's microservices via native change data capture, with each data product incrementally updated as source data changes. From there, every application and service queries data products on demand or subscribes to change events streamed out to Kafka, with those same streams also powering Bilt's internal reporting and operational dashboards in Sigma.

"We were able to build both a transactional and an event-based system in one go."

— Kosta Krauth, CTO, Bilt

Instead of going directly to a context layer powering agents, though, the Bilt team took a crawl-walk-run approach, unlocking value along the way while building out the canonical data model at the core of their data platform.

The audiences and offers engine was the first capability powered by the new live context layer. Bilt wanted to give merchants an "audience builder": a way to define groups of members and send them real-time, targeted offers the moment they qualified. For example, a restaurant partner can create an audience of members who have visited three or more times this month, and target them with exclusive perks like 20 percent off their next visit, a free martini, or a comped Lyft ride home.

Each audience is a real-time materialized view in Materialize, defined simply in SQL. As source data changes, members move in and out of the view as they match its criteria, with Materialize emitting a change event for each transition. Bilt's audience builder microservice subscribes to those events on Kafka and fires an offer when a member qualifies.

This audience builder was fast to create because it could be composed from data products the data team has already published to the CDM. That library started small, with core data products including member activity, spend, and transactions, but quickly expanded as the context layer began powering more services and applications.

"We build real-time audiences, emit change events, and use those events to trigger a chain reaction of offers — all in SQL."

— James Dorado, VP of Data, Bilt

That pattern is already repeating outward. Dining audiences make up the large majority of what's live today, but property audiences are already running in production on the same infrastructure, months after dining — the same data products, the same dbt workflow, the same crawl-walk-run path. Travel and financial services are next in line to draw from the identical foundation.

The same architecture also gives merchants a live telemetry feed showing how their audiences and offers are performing. Merchants can see visits, spend, trending members, and offer acceptance all in real time, which lets them run experiments easily and adjust offers quickly. All of this is powered by the same real-time data products in the CDM: the audience builder engine subscribes to changes as events on Kafka to fire offers, while the merchant portal queries them directly for live dashboards.

Bilt's vision is for AI to become the primary way all users interact with the platform, and the context layer gives them a foundation agents can trust. One of the main projects supporting that vision is the AI concierge, an interactive assistant embedded in Bilt's apps that members and merchant partners can talk to in plain language. For example, a restaurant partner can describe an audience like "members who like red wine" and have the concierge build it, or a member can ask for a summary of their rent points for the month and get a real-time answer. Actions taken by consumers, merchants, or agents should be reflected within the context layer immediately, unlocking interactive experiences and, ultimately, long-running loops.

In the backend, the concierge is an agent equipped with tools to query the context layer as well as tools to take actions. When a user asks a question or delegates a task to the agent, it composes SQL against the real-time data products in the CDM, combining and filtering those ready-made building blocks on the fly to get exactly what it needs.

Letting a language model write SQL against production data of course calls for guardrails. Each concierge runs in its own isolated cluster, with read-only access scoped to just the specific data products it needs. If the agent writes a bad query, any impact is contained within that cluster and never spills over to other agents or workloads.

"The agent doesn't reassemble the world anymore. It knows what's being asked, the context is already there, and it just goes and gets the answer."

— James Dorado, VP of Data, Bilt

The concierge can also take actions on behalf of users, not just answer their questions. If a member asks to book a restaurant or open a dispute about missing points, the agent triggers the relevant API calls on Bilt's microservices to take that action. Those microservices in turn write the change to their own databases, and the context layer picks up the change in about a second. This closes a tight feedback loop: the agent can observe the world, act, see the result of that action, and decide the next step, always working from current state rather than a stale snapshot.

On the merchant side — where the concierge runs entirely on the context layer — AI now handles the vast majority of live conversations end to end, from answering a dining partner's question to picking up a property manager's SMS thread. Human staff step in only as the rare exception, not the default path.

Search is another major part of Bilt's stack, letting members find nearby experiences that match their preferences. For example, consider a member trying to find popular restaurants with availability tonight, within a couple of miles, that match their preferences. Computing distance and availability is relatively straightforward. But figuring out whether a restaurant matches a particular member's dining preferences is harder, requiring machine learning and a vector database.

Bilt already had such a search stack for these queries. It used machine learning to predict what kind of restaurants each member would prefer, and what kind of members typically visited each restaurant; both types of predictions were captured as embeddings. The search pipeline then matched results based on these embeddings, and further filtered and ranked by distance, availability, and popularity. However, this pipeline didn't always return optimal results. Because it ran as a sequence of three distinct steps with a final merge, a candidate that scored low at any one step could be dropped, even when it would have been the best combined answer. So Bilt set out to build Omnisearch, a new unified search that combines everything into one ranked pass.

Omnisearch is built on the same context layer. Each search document is modeled in SQL as a complete, denormalized record with all embeddings and attributes required for the vector database. Embeddings are sourced from the warehouse and refreshed on a batch schedule, while attributes are computed in real time by joining and transforming upstream operational data. As source data changes, Materialize pushes the deltas over Kafka to the vector database, so the search index stays continuously fresh without the cost of reprocessing anything that hasn't changed.

"Recommendation quality is a data quality problem. Omnisearch works because the index is never stale — every attribute is up to the second."

— James Dorado, VP of Data, Bilt

Bilt's new live context layer delivered a shared set of real-time data products that the entire organization could use, with freshness and latency neither of the old paths could reach. Across hundreds of microservices and thousands of real-time data products in production — including merchant-defined audiences — data is now up-to-the-second fresh where it used to be about an hour behind. Joined queries return in single-digit milliseconds where they used to take up to two seconds.

That freshness and latency turn into merchant-facing capabilities Bilt could not offer before. The audiences and offers engine gives dining, travel, and property partners a real-time way to segment members, target them with offers, and see these perform in a live dashboard without waiting on a report. The AI concierge lets those same merchants delegate tasks such as booking a member's reservation or adjusting an active offer, and have agents respond and take action on fresh, trustworthy context. And real-time customer intelligence lets a merchant query live data across that customer base to see who is visiting, what is trending, and where offers are converting.

That foundation already reaches across the business, not just one vertical. More than 70,000 locations across hundreds of merchant groups — spanning dining and property — run on the same audience engine today, covering millions of customers from those merchants.

"The audience builder doesn't sound like much, but it powers essentially our entire restaurant loyalty platform and business."

— Kosta Krauth, CTO, Bilt

Bilt now ships new use cases in a fraction of the time these previously required. The first real-time audience builder was in customers' hands about a month after starting with Materialize, and each new use case since has taken less engineering time than the one before. Because every data product is defined in SQL, engineers can discover and query the ones that already exist without cross-team coordination. And, as the library of real-time data products grows, more of what a new feature needs is already there. When the data team does need to build a new data product, this is fast and easy because it is defined and deployed through the same dbt workflow they already use.

Launching new microservices is also faster, because integrating them is faster too. Instead of implementing point-to-point API integrations, connectors, failure handling, and schema sync between services, a new microservice's database is captured via CDC once, and the service reads whatever it needs directly from the context layer. Integration work that used to be repeated by every team, and thrown away when a schema changed, is now done centrally in the CDM and shared.

Agentic coding accelerates developer velocity even further. Every data product is a SQL view with a clear schema, so an engineer can point an AI coding assistant at the existing views, describe what a new service needs to consume or emit, and have it draft most of the SQL front to back.

"New microservice? Here's the playbook. It truly has gotten faster, and it will continue to get faster."

— James Dorado, VP of Data, Bilt

Bilt's engineering org is organized into pods — cross-functional teams that each own a business domain end to end, from payments and dining to resident loyalty — with the data team sitting in the platform pod that serves all of them. Bilt centralized its data infrastructure while accelerating its internal pods and keeping them autonomous. Teams move faster because they have a growing library of ready-to-go data products to pull from, just a SQL connection or Kafka topic away from integration with whatever they're building. And they no longer spend cycles on repeating integration work that another team has already done.

When a pod does need something new, they can contribute it to the CDM themselves. They define the data product in SQL and propose it as a git PR to the shared dbt project, which the data team reviews and merges like any other engineering change. Once merged, the new data product is immediately available to every other pod, so a solution built by one team becomes a resource for everyone.

"Our data team organized data from every pod without creating work for those pods. Doing it any other way would have been orders of magnitude more effort."

— Kosta Krauth, CTO, Bilt

Bilt can now use more of the faster, smaller, and cheaper models in its AI strategy. Before the CDM, agents had to reason their way through raw operational data and join it together on the fly, which cost time and tokens and often needed a frontier model to reach an acceptable result. Prompt engineering and prompt caching helped, but the per-query cost remained high.

Now, the concierge and other agents receive up-to-the-second context that is already joined and standardized. Because the data is already in the right shape to support rapid context assembly, they spend fewer tokens preparing it and more on taking actions and answering questions. This gives Bilt a choice: use frontier models to do more with the same tokens, or use smaller, cheaper models for the more routine work.

As a result, Bilt is spending materially less on tokens than it otherwise would. This shifts the frontier between token cost and agent performance: the same budget now buys more agent output, whether that's more agents in production, more work per agent, or reserving the most capable models for the queries that truly benefit from deeper reasoning. It also helps them scale their concierge and other AI services cost-effectively, a priority for the CFO as AI costs continue to rise across the industry.

"We serve most concierge traffic on fast, efficient models and get frontier-quality answers — because the context does the heavy lifting, not the model."

— James Dorado, VP of Data, Bilt

Bilt has ambitious plans to make agents the primary way members and merchants interact with the product. They also want to expand into new verticals beyond dining and property, from travel to financial services. Materialize will underpin both.

On the AI side, the concierge is also an area of active investment. The merchant-facing version is already entirely powered by the context layer, whereas the member-facing version still queries a handful of microservices directly for parts of its workload. Those direct calls are being migrated onto the CDM one by one, so both concierges will eventually pull from the same foundation.

Beyond the concierge, Bilt is also working on bringing the same search experience to merchants. Omnisearch lets members find dining, travel, and other experiences that match their preferences. The plan is to give merchants an equivalent capability over their own data, so a property manager can search across their residents or a dining partner across their customers, all through the same unified, live-ranked architecture that powers the consumer version.

The team is also rolling Materialize out to more of Bilt's business, one vertical at a time. Dining is the most built-out today, property is newer, and travel and financial services come next. Because each new vertical draws from the same live foundation, launching a new one takes a fraction of the engineering time initially required to build dining from scratch.

Finally, one of the most ambitious projects on Bilt's roadmap is formalizing the semantic links within the context layer into an explicit context graph or ontology. Today, agents infer relationships between entities from Bilt's dbt DAG, the Materialize system catalog, and internal documentation. Making those links explicit would let agents discover and reason about how entities connect more easily, and act more autonomously as a result. As with everything else Bilt builds, it stays grounded in the same consistent view of the world.