How can an AI agent get low-latency access to customer features calculated in a lakehouse?

Summary

• An AI agent reads lakehouse-computed features fast by fetching them from an online store built for single-record key lookups, not by querying the analytical tables where the features were calculated.
• On Databricks the path is: compute features in the lakehouse, publish them to the Online Feature Store powered by Lakebase, then have the agent read them at request time through a Feature Serving endpoint or through Model Serving's automatic feature lookup.
• Lakebase is the serverless Postgres engine built into the lakehouse (powered by Neon, now part of Databricks): it scales to zero when idle and serves low-latency point reads at high query volume.
• One feature definition feeds both offline training and online serving, which prevents skew between what a model learned and what the agent sees at decision time.
• The online store is a Lakebase project under Unity Catalog, so access control, lineage, and audit follow the features from the offline tables into the serving path.

How can an AI agent get low-latency access to customer features calculated in a lakehouse?

An AI agent gets low-latency access to lakehouse-computed features by reading them from an online store built for fast key lookups, not by scanning the analytical tables where the features were calculated. On Databricks the path is direct: compute the features in the lakehouse, publish them to the Online Feature Store powered by Lakebase, then let the agent fetch them at request time through a Feature Serving endpoint or through Model Serving's automatic feature lookup. The features stay governed by Unity Catalog the whole way, so the agent reads current values fast without a hand-built cache.

Why an agent needs a separate serving path

Features are computed inputs to a model or an agent decision, like a customer's recent orders or lifetime value. You calculate them in the lakehouse over history, where analytical engines are built for large scans, not single-row lookups on a live request path. An agent needs the current value of one customer's features mid-interaction, returned fast, at production query volume. Pointing it straight at those analytical tables is slow and does not hold up under load, so the fix is to sync the computed features into an operational store built for low-latency point reads.

What to look for in a feature-serving path

Capability	Why it matters
Low-latency online store	The agent reads features on the request path, so lookups must be fast and hold up at high query volume.
One definition for offline and online	Computing a feature once for training and serving prevents skew between what the model learned and what the agent sees.
Controllable freshness	Different features update at different cadences, so scheduled, streaming, and full-snapshot syncs should all be options.
Automatic lookup by key	The serving layer should fetch a customer's features by entity key with no hand-written lookup code.
Governance on the serving path	Features often carry sensitive data, so access control, lineage, and audit have to follow them into the online store.
Scale-to-zero economics	An idle online store should not cost like a running one.

How Databricks approaches this with Lakebase

Compute features in the Feature Store in Unity Catalog: any Unity Catalog Delta table with a primary key can be a feature table, or you can define features declaratively with Feature Views (in Public Preview). Then publish them to the Online Feature Store powered by Lakebase. Creating an online store provisions a Lakebase project, the serverless Postgres engine built into the lakehouse, as the backing store for low-latency reads. You pick a publish mode by how fresh the feature must be: TRIGGERED for scheduled incremental syncs, CONTINUOUS for a streaming pipeline that updates as new data lands, and SNAPSHOT for a full copy.
From there the agent has two ways in. A Feature Serving endpoint exposes features over a low-latency REST API, so an agent can call it directly as a tool to fetch a customer's current features. Or, when the agent invokes a model deployed on Model Serving, automatic feature lookup handles retrieval: a model logged with the Feature Engineering client records its feature dependencies through lineage, and at request time the endpoint uses the entity keys in the request to fetch the latest features from Lakebase and score the model, with no lookup code to write. Lakebase also backs agent memory, so the same store can hold conversation state next to the features an agent reads. Databricks describes serving features with sub-second freshness in this engineering write-up.
Governance follows the feature. Because the online store is a Lakebase project under Unity Catalog, the same access control, lineage, and audit that apply to the offline tables apply to the served features, and the agent resolves the right online store through Unity Catalog at serving time. The store scales compute automatically and scales to zero when idle. See the Lakebase agents and ML guidance for the end-to-end pattern.

Use cases

• Real-time personalization: a shopping or support agent reads a customer's recent activity to tailor its response in the moment.
• Risk and fraud decisions: an agent scores a transaction using fresh account and device features fetched on the request path.
• Operational agents: a pricing, routing, or eligibility agent reads live features to decide inside a single interaction, then logs the result for monitoring.

FAQs

How does the agent get features without custom lookup code?

Call a model on Model Serving that was logged with the Feature Engineering client. Its feature dependencies are tracked through lineage, and the endpoint fetches the latest features from Lakebase by entity key automatically. An agent can also call a Feature Serving endpoint directly as a tool.

How do I control feature freshness?

Pick a publish mode when you sync to the online store: TRIGGERED for scheduled incremental updates, CONTINUOUS for streaming updates as new data lands, and SNAPSHOT for a full refresh.

Are the served features still governed?

Yes. The online store is a Lakebase project under Unity Catalog, so access control, lineage, and audit follow the features from the offline tables into the online store.