The CDP evolution

A quick level set so we’re all on the same baseline. The CDP has moved through phases that most everyone recognizes and agrees on.

Packaged. The first generation of tools (Segment, Tealium, the early marketing clouds) shipped as self-contained applications that practitioners copied customer data into. They owned the profile store, the identity graph, the segmentation engine, and the connectors as one monolith. The downside, fundamentally, was duplication and yet another data silo: another place sensitive data had to live, be governed, and be reconciled.

Composable. As cloud warehouses took off, the reaction was to unbundle. Keep the data in the warehouse, the place that already had the most complete view of the customer, and run identity, segmentation, and activation as modular layers on top. Hightouch and others turned the warehouse into the system of record and reframed the CDP into a set of interchangeable functions. The warehouse became the center of gravity. And composability won so thoroughly that the packaged incumbents didn't die to it, they converged on it. Adobe, Salesforce Data Cloud, and Twilio Segment all added warehouse-federated audiences, zero-copy data sharing, and reverse-ETL-style activation, absorbing the composable playbook rather than holding the line against it. The packaged-versus-composable distinction blurred almost everywhere, which is the first clue that it is no longer the distinction that matters.

Now. I think there may be a tendency to initially brand this phase as "warehouse-native CDPs" and treat it as a tidy continuation of composability. I claim that this label misreads the new fork in the road.

I would argue that what is actually occurring is a re-bundling. Composability won the architecture argument (the data should stay put), but it left the application layer scattered across tools, and agents are now the mechanism for pulling that layer back together. The twist that was introduced this week is that the re-bundling is happening two different ways at once:

• Databricks re-bundles inward: pull the CDP application back inside the data platform, where the agents live next to the data. That's CustomerLake.
  
  
• The composable camp re-bundles outward: keep the CDP as a layer that spans platforms, and bring the agents to wherever the data and context already live. That's Hightouch's version of an "agentic CDP".
  
  

We are no longer evaluating packaged versus composable. It's closer to data-platform-native versus open-composable.

What is CustomerLake?

Let’s briefly level-set what CustomerLake is. This is a non-exhaustive summary based on what we know based on the product announcement. CustomerLake takes an agent-first approach to the core offerings of a CDP: identity resolution + enrichment, audience building, and then activation and measurement.

Identity runs through what Databricks calls Agentic Identity Resolution. Profile Agents conduct deterministic and probabilistic matching coupled with ‘agentic workflows’ for edge cases. There is support for bring-your-own rules and third-party enrichment via a handful of larger players in the enrichment space. On top of the unified profile sit Campaign Agents that build audiences, recommend next-best actions, activate across an open roster of destinations (The Trade Desk, Meta, Adobe, Braze, Snapchat, and more), and continuously optimize toward stated goals. Databricks has branded this as "infinity campaigns." Governance runs on Unity Catalog, and Lakehouse Federation lets CustomerLake reach customer data where it already lives, including in Snowflake and BigQuery. It is in Private Preview. It is not GA, and I would speculate that it is likely not as battle-tested at the scale its launch logos imply.

Importantly, CustomerLake is led by Tasso Argyros, the founder of ActionIQ. This is the vendor that Gartner once named the only composable CDP in its inaugural CDP Magic Quadrant. Databricks didn't improvise a martech product. It brought in the person who defined the composable-CDP category and gave him the resources to build the native one on Databricks. If it works as advertised, it is a genuinely impressive product.

What is the composable CDP alternative?

If you strip CustomerLake down to its core functions, there is nothing in it that can't be rebuilt on Snowflake from interoperable parts. Resolved identities can be assembled in logic you control. You can perform identity enrichment with a broad and open ecosystem of providers in the marketplace. The reasoning and activation layer can sit on top of that enriched C360 dataset, leverage agents plus semantic views for the reasoning, activation through a tool like Hightouch, and measurement via custom logic and/or native clean rooms.

The point isn't that this checks the same feature boxes, though it does. Both approaches can claim identity, enrichment, audiences, activation, and agents. The difference is where the logic lives and who can open and tune it. In the composable build, the logic is yours. Nothing in the path from raw event to activated audience has to be a vendor black box. Notably, the composable alternative’s increased customizability comes with the advantages of full ownership and personalized tuning: custom ID graph stitching, cross-DSP/SSP analytics, and more fine tuning in agentic creative content - to name a few.

I would claim that every agentic CDP that rolls out is going to perform two core actions: it will perform identity resolution and enrichment, and then it will execute agentic reasoning on top of the C360 data to decide and act. The real decision is how much of each process you own and can tune. Do you control how golden records get assembled - the match logic, the survivorship rules, the enrichment - or does the platform? And do you control the reasoning - the prompts, the skills, the business logic the agents apply - or is that the vendor's too? CustomerLake's answer is that both live inside Databricks, tunable within the bounds the platform chooses to expose. The composable answer is that both are yours.

How Snowflake may respond

Path 1: Lean into the open ecosystem

Snowflake's most likely response is also its most on-brand one. For years, Snowflake has focused a central part of their competitive identity against Databricks on the following contrast: Snowflake is the open ecosystem, and Databricks is the closed one.

In some ways, CustomerLake is a clean proof point of that narrative. A full, packaged CDP whose agents and decisioning run entirely inside Databricks. In some ways, the most natural Snowflake counter is not to build its own packaged CDP, but to make the open, composable, customer-owned CDP the headline answer.

The argument for this path almost writes itself: an agentic CDP assembled from best-of-breed, interoperable parts: tools like Hightouch for activation and decisioning; Cortex and/or custom agents and semantic views for reasoning; native clean rooms for measurement; the Marketplace for identity and enrichment - where the customer owns and can inspect every layer, and can optimize the whole infrastructure across platforms.

It’s worth calling out that CustomerLake appears to be genuinely open at the edges - open destinations, a few different enrichment partners, MCP and API integration, federated access to outside data. The distinction Snowflake could press is not at the edges but at the core: in a composable model, the intelligence itself - the identity rules, the audience logic, the agent skills and prompts, the measurement - is yours, expressed in code and configuration you can audit, version, and carry elsewhere. In a packaged platform CDP, that intelligence is the vendor's, and it lives in the vendor's platform. Open connectors, but closed brain. This happens to be the exact argument that some of the ecosystem is already making. For example, Hightouch's banner statement is: own your context, own your AI.

I personally think this path fits Snowflake's DNA and go-to-market. The cost is narrative tidiness. "We have an open ecosystem you assemble" is harder to put on a slide than "we have a CDP." And prospects will reach for a convenient out-of-the-box offering if it meets the promise of genuine and effective agentic marketing workflows.

Path 2: Build or buy a competing product

It would be a mistake to rule out this path entirely, and it’s always fun to speculate. Snowflake could ship its own agentic CDP, either by assembling one from the parts it already owns or by acquiring.

The build route. The fact of the matter is Snowflake innovates at a staggering pace. I’m very confident that they have the in-house talent to build a formidable CDP on their own. Whether they actually do it is dictated by internal product priority, overall strategic vision, and countless other factors.

The buy path. General acquisition logic points at one target: Hightouch, the composable-CDP leader running on its platform, in which Snowflake Ventures is already an investor, whose agentic AI Decisioning already runs natively on Cortex, and which it just named its 2026 Product Partner of the Year for marketing and advertising. That would be the near-perfect mirror of the ActionIQ move Databricks made.

But the buy path is less likely than it looks. Hightouch just raised a $150M Series D at roughly a $2.75B valuation, with ARR around $100M. That is the profile of a company on an independent trajectory, not one looking to sell. More decisively, Hightouch's brand-new positioning is built entirely on cross-platform neutrality: it works across Snowflake, Databricks, and the major model providers, and connects to all of them. A Snowflake acquisition would contrast with some of the value proposition Hightouch announced this week.

In general, my stance is a first-party Snowflake CDP, bought or built, would compete with the very partners who built the composable category on its platform, straining the open-ecosystem narrative that Snowflake leans into. So I would be surprised if this is the recognized path, but crazier things have certainly happened, and I would be one of the first people trying out the Snowflake-native CDP. Sounds interesting.

What does this mean for marketers?

There's a version of the agentic CDP story that quietly writes the human marketer out of the picture. The software builds the audiences, picks the next-best action, and optimizes the spend, so what's left for the human to do? DAS42 fundamentally disagrees with this rhetoric. Anyone who has run sophisticated marketing knows there is real craft in the work. There is a hard-earned institutional sense of what moves your particular base. That is secret sauce, and it isn't something an agent reverse-engineers from scratch on day one.

Our take is that the right way to think about agents is as an amplifier of that expertise, not a replacement for it. And, of course, that reframes the architecture question one more time. What determines whether your marketers' craft actually compounds is whether the platform lets them encode it and keep refining it - or whether it abstracts their judgment into the vendor's out-of-the-box defaults.

In an open, composable model, that expertise gets materialized in artifacts the team owns: the segmentation logic, the audience definitions, the agent skills and prompts, the measurement criteria. The agent executes and scales that judgment across millions of customers. The marketer stays in the driver's seat, and the agent becomes the engine.

In a closed, packaged CDP, the convenient path is to let the vendor's agents apply the vendor's notion of best practice. That works, and it's certainly easier, but it quietly trades your marketers' differentiating instincts for someone else's median. If your team's expertise shows up only as goals handed to a black box, you've commoditized the one input your competitors can't copy.

The platforms that win in this space are the ones that let your best people work their magic and provide them with agents to do it at a scale they never could alone.

If your marketing team is already on Snowflake, don't re-platform based on a press release

A launch this loud creates pressure to act. For the large population of enterprises whose data, governance, and analytics gravity already live in Snowflake, the case for keeping your marketing analytics and activation hub there is strong - and it has nothing to do with brand loyalty.

First, CustomerLake is in Private Preview, and nobody should re-architect a customer data stack around the first release of anything. Importantly, the choice isn't agentic marketing OR Snowflake. Agentic marketing techniques can be realized on the platform today, it’s just not a precanned tool that you select from the Snowsite UI.

And then the deeper points that are top of mind for DAS42, which are really the platform-native versus composable argument applied to your own internal roadmap:

• A capability everyone can buy is not a competitive advantage. The entire premise of first-party data strategy is doing something your competitors can't. If your rival runs the same out-of-the-box agents over the same enrichment, your marketing intelligence converges toward theirs. Durable advantage lives in proprietary logic built on your unique data - which the composable approach lets you build, own, and inspect without a vendor's complexity ceiling.
  
  
• It is simply not realistic to get everything into one cloud data warehouse. Customer context, content generation, and activation endpoints are spread across systems of record that won't all consolidate, and many never will or should. Both approaches have to reach beyond their own four walls to deal with that reality. A composable architecture treats a heterogeneous, multi-system world as the permanent design assumption A platform-native CDP pulls the gravity toward its own platform, and the further a system sits from that platform, the more friction and cost the integration carries.
  
  
• Agent-first is a cost-control question, not a cost-savings guarantee. Always-on agentic reasoning is continuous inference. The composable advantage is governing when and where agents run: reserve them for genuinely ambiguous, high-judgment decisions and let deterministic SQL handle the large share of work it already does cheaply. You don't pay an agent to do what a WHERE clause does.
  
  
• You can explain a SQL rule to a regulator; a model trace is harder. In financial services, healthcare, and anything with consent and suppression obligations, you want audience and identity logic in version-controlled code your team owns. You want a glass box you can hand to an auditor, not opaque agentic behavior you have to reverse-engineer after the fact.
  
  
• Re-bundling reintroduces the lock-in that composability escaped. One could make the argument that moving your CDP into one platform concentrates your dependence on one vendor's roadmap, pricing, and agents. That’s the same trap the packaged era taught us to avoid, wearing a new logo. Open formats and a composable hub keep your activation layer portable and your data yours.
  
  

None of this means CustomerLake is wrong. Candidly, we simply do not know enough about it yet to speculate either way. For organizations whose data already lives in Databricks, it may be the obvious choice, and it raises the bar for everyone. But "Databricks built an impressive CDP" and "you should move your customer hub to Databricks" are different statements, and for a Snowflake shop, the space between them is where the real decision lives.

The data foundation is the work

Whatever happens next, one thought to keep in mind: agents amplify whatever foundation they're given. Point one at clean identity, a real semantic layer, sane governance, and honest measurement, and it's transformative. Point it at a half-resolved identity graph and ambiguous business logic, and it will make bad decisions faster and more confidently than any human could. That foundation is the work, and no packaged agentic CDP ships with it, because it only exists once someone has modeled it against your business. It is also, not coincidentally, the most portable asset you own. This foundation is equally valuable whether it ends up serving Snowflake's primitives, a partner's agents, or someone else's entirely.

The ecosystem will fight over the UI, and the loudest demos will win the early attention. But platform-native versus composable won't be settled by which agent is slickest. It'll be settled by whether you were willing to own your data foundation - or whether you handed it to a vendor and hoped. That choice has always been the real one. Agents just raised the stakes on getting it right.