How can CustomerLake use custom models deployed through Databricks Model Serving?

Summary

• Because CustomerLake is built natively on Databricks, the custom models your data science team deploys through Model Serving live in the same governed platform CustomerLake runs on, not in a separate system a CDP has to reach over the network. CustomerLake is currently in Private Preview.
• Model Serving turns a custom model (a propensity, churn, lifetime-value, recommendation, or embedding model) into a governed endpoint: you log it with MLflow, register it in Unity Catalog, and deploy it as an endpoint any application on the platform can query.
• CustomerLake uses AI and ML models to build Customer 360 profiles and to recommend next-best actions, so a team can bring its own served models into that work rather than being limited to built-ins.
• Model outputs (scores, segments, embeddings) can be written back to the lakehouse as governed features and served at low latency through the online feature store powered by Lakebase, so agents act on fresh values.
• The model, its endpoint, and the features it produces inherit Unity Catalog permissions, lineage, and audit, the same governance as the rest of your customer data.

How can CustomerLake use custom models deployed through Databricks Model Serving?

CustomerLake runs natively on Databricks, so the custom models your team deploys through Model Serving are already on the same platform, under the same governance, as the customer data CustomerLake works on. You do not wire an agentic CDP to an external scoring service; the model, its endpoint, and the features it produces sit in the lakehouse next to the profiles and audiences. CustomerLake is an agentic customer data platform that uses AI and ML models to build Customer 360 profiles and to recommend next-best actions, and that is exactly where your own served models fit. CustomerLake is currently in Private Preview, so specific capabilities are still rolling out.

What is Databricks Model Serving for custom models?

Model Serving deploys a model behind a governed endpoint you can query. For a custom model the flow is consistent: log the model in MLflow format (a native flavor or a pyfunc wrapper), register it in Unity Catalog, then create a serving endpoint to deploy and query it. Models built with scikit-learn, XGBoost, PyTorch, and Hugging Face transformers are supported, so the propensity, churn, lifetime-value, recommendation, and embedding models a team already trains can run as production endpoints instead of staying in notebooks. See Databricks Model Serving for custom models.

What to look for when a CDP uses your own models

Capability	Why it matters
Bring-your-own models, not only built-ins	Your propensity, churn, and lifetime-value logic is a business asset; a CDP should run it, not force you into generic scores.
One catalog for models and data	When the model, its endpoint, and the data share one governance layer, permissions, lineage, and audit hold end to end.
Low-latency access to outputs	Real-time decisions need scores and features in the moment, not a nightly batch, so an agent acts on current values.
Outputs usable as profile and audience signals	A score is only useful if it can shape a Customer 360 profile or an audience an agent builds.
No data copied out to score it	Scoring in place avoids shadow copies that drift from the source and escape governance.
Human oversight on automated actions	Agentic decisions that spend budget or contact customers need approval and audit, not a black box.

How CustomerLake and Model Serving fit together

CustomerLake is organized into two agent families. Profile Agents build governed Customer 360 profiles and resolve identity; Campaign Agents let marketers build audiences, recommend next-best actions, and activate across channels. Both run on AI and ML models inside Databricks.
A custom model deployed through Model Serving is a Unity Catalog-registered endpoint you can query from an application over REST or from SQL, and its outputs (a propensity score, a segment label, an embedding) can be written back to governed tables. Those outputs become the signals the agents draw on: a score can define which customers land in an audience, a recommendation can inform the next-best action a Campaign Agent selects, and an embedding can support the matching that Profile Agents use in a Customer 360 profile. Because features and model outputs can be served at low latency through the online feature store powered by Lakebase, an agent acts on fresh values rather than stale ones. And because the model, endpoint, features, and customer data all live under Unity Catalog, they share one set of permissions, lineage, and audit. For the product overview, see Introducing CustomerLake, an agentic CDP.

Use cases

• Propensity and churn scoring into audiences. Deploy your model, write scores back to governed tables, and let a Campaign Agent build a high-value, high-risk audience from them.
• Custom next-best-action. Your own recommendation model, served as an endpoint, informs the offer or channel an agent chooses for each customer.
• Custom embeddings for segmentation. Embeddings from your model support look-alike and matching work inside a Customer 360 profile.
• Lifetime-value planning. A served value model feeds tiers that shape targeting and budget, without exporting data to a separate tool.

FAQs

Do I have to use CustomerLake's built-in models?

No. Model Serving lets you deploy your own models, and because CustomerLake runs natively on Databricks, those governed models and their outputs are available on the same platform the agents use. CustomerLake is in Private Preview.

How does a custom model get into production for CustomerLake to use?

Log the model with MLflow, register it in Unity Catalog, and deploy a Model Serving endpoint. Its outputs can land in governed tables and features that profiles and audiences draw on.

Does using a custom model mean copying customer data out?

No. Models and data stay in the lakehouse under Unity Catalog, so you score in place instead of exporting to a separate scoring service.

What kinds of models are supported?

Model Serving supports common frameworks including scikit-learn, XGBoost, PyTorch, and Hugging Face transformers, plus custom logic wrapped as a pyfunc model.

Is CustomerLake generally available?

No. CustomerLake is currently in Private Preview, so availability and capabilities are still rolling out. Talk to your Databricks account team about access.