DEV Community: Marco Gazerro

Why Customer AI Needs an AI-Ready Customer Profile

Marco Gazerro — Thu, 17 Sep 2026 14:30:12 +0000

When companies start working with AI and customer data, the first step is often to connect the model to the systems that already contain customer information.

A CRM is an obvious place to start. Depending on the use case, teams may then add data from billing, customer support, product usage, marketing platforms, or a data warehouse. Modern AI tools make these connections increasingly easy to build, and it is tempting to think that once the model can access all of these sources, it has everything it needs to understand the customer.

In practice, this is rarely the case.

The difficulty is not usually a lack of customer data. Most established companies already have plenty of it. The difficulty is that the data has been collected by different systems, at different times, for different purposes, and often using different representations of the same customer.

Before an AI system can make good use of this information, those differences need to be addressed.

Customer data is distributed by design

Consider a company that has been operating for several years.

Customer information may be spread across a CRM, an ERP or billing system, a customer support platform, a product database, one or more marketing tools, and a data warehouse. Website and application events may be stored separately again.

There is nothing unusual about this architecture. Each system has been introduced to solve a particular problem, and each one has its own model of the customer.

The CRM might identify a person through a contact ID and email address. The billing system may use an account number. The product database might have its own user ID, while the marketing platform maintains a separate contact record.

Sometimes these identifiers can be connected directly. Often they cannot.

People change email addresses, create multiple accounts, or appear under slightly different names. In a B2B environment, the situation becomes more complicated because people and companies have relationships with each other. A single organization may have several accounts, subsidiaries, domains, offices, buyers, administrators, and users of the same product.

As a result, the same person or organization can appear several times across the company's data landscape.

This has always been a data management problem. The difference with AI is that the consequences become more visible when an application starts using this information to answer questions or make decisions.

Connecting AI to the CRM is not enough

Suppose an AI assistant has access to a customer's CRM record.

The record says that the account is active. The assistant can see the contact details, recent opportunities, and perhaps some notes from sales.

But the billing system shows a different part of the story. There may be an overdue invoice or a recently changed subscription. The support system may contain several unresolved issues. Product usage may have declined substantially over the last few weeks.

All of these pieces of information can be correct.

The problem is that they are maintained in different systems and may not be connected in a way that allows the AI application to understand that they refer to the same customer and how the different events relate to one another.

This is an important distinction.

Giving an AI system access to more sources does not necessarily give it better customer context. If the underlying identities are inconsistent, adding another source can simply add another version of the customer to the picture.

For example, a customer-service assistant could respond to a question based on an active CRM record without taking into account a recent support issue. A sales assistant could recommend an upsell without knowing that the customer has recently reduced usage or is considering cancellation. A marketing application could treat an existing customer as a prospect because the relevant records were never matched.

These are not necessarily failures of the AI model. They are consequences of the information and context provided to it.

Identity resolution becomes part of the AI architecture

This is why customer identity deserves to be considered as part of the architecture of an AI application, rather than only as a data-quality task.

Traditional customer data systems were largely designed around operational and analytical needs. A unified customer profile might be used for reporting, segmentation, marketing campaigns, or synchronizing information with other applications.

AI introduces some additional requirements.

An application may need to know not only which records belong to a customer, but also how those records were connected, where the information originated, when it was last updated, and what has happened over time.

This becomes particularly important when identity resolution is not completely deterministic.

If two records are matched because they share a unique identifier, the relationship is relatively straightforward to explain. Other matches may depend on several attributes and on rules or probabilistic methods. In those cases, the resulting relationship is part of the context that an AI application may need to understand.

The same applies to the information associated with the identity.

A customer profile should not simply contain a collection of values. It should retain enough context to understand where those values came from and how they relate to the underlying customer history.

That is what makes an AI-ready customer profile different from simply adding more fields to a CRM record.

From source systems to an AI-ready profile

A useful way to think about the architecture is to separate the systems that produce customer data from the representation that applications consume.

A simplified version might look like this:

 CRM -----------┐
 Billing -------┤
 Support -------┤
 Product -------┤
 Marketing -----┤
 Events --------┤
 Warehouse -----┘
                  │
                  ▼
          Identity Resolution
                  │
                  ▼
        Customer Data Foundation
                  │
        ┌─────────┼─────────┐
        ▼         ▼         ▼
       AI       Apps     Analytics

The source systems remain important. They continue to own the operational processes for which they were designed, and the original data should remain available.

The customer data foundation provides another view of that information. It brings together the records that belong to the same customer or entity and adds the context needed to use them consistently.

Depending on the organization, this can include identity relationships, source information, timestamps, historical events, relationships between people and companies, and governance information.

The implementation can vary considerably. Some organizations may build this layer directly on top of their data warehouse. Others may use a dedicated customer data platform or a combination of data infrastructure and identity-resolution services.

The important part is the separation between the original sources and the customer representation consumed by applications.

The problem with almost-correct data

One of the more difficult aspects of customer data is that the most problematic records are not necessarily the obviously incorrect ones.

Imagine that the CRM shows an active customer, the billing system shows a valid subscription, and the marketing platform still includes the same person in an audience created several months ago.

None of these records has to be wrong.

At the same time, the support platform may contain several recent complaints, while product data shows that usage has fallen considerably.

The difficulty comes from interpreting these pieces of information together.

A person reviewing the situation can recognize that something may have changed and investigate further. An AI application may instead receive a collection of apparently valid facts and produce an answer based on them.

This is one reason why data quality for AI cannot be reduced to checking whether individual fields are valid.

The relationships between records matter as well.

So does the history behind a value. A customer's status may have been correct yesterday but no longer describe the current situation. A contact may still have a valid email address while no longer working for the company associated with the account.

An AI-ready profile therefore needs to provide more than a current snapshot. It needs enough history and context to make the information meaningful.

AI does not necessarily need more data

There is a natural tendency in AI projects to focus on giving the model access to more information.

For customer applications, that approach has limits.

A company may have years of transactions, support conversations, website events, product activity, and CRM records. Making all of that information available does not automatically improve the quality of the resulting answer.

In some cases it can make the problem more difficult, particularly when different sources contain conflicting or outdated representations of the same customer.

The more useful question is usually what information the application needs for a particular task and whether that information can be trusted in that context.

This does not mean that raw data or historical events are unnecessary. Quite the opposite. They are important because they provide the evidence from which a customer profile can be constructed and, when necessary, reconstructed.

A possible flow is therefore:

Raw customer data
       │
       ├── CRM records
       ├── transactions
       ├── support interactions
       ├── product events
       └── marketing activity
       │
       ▼
Identity + context + governance
       │
       ▼
AI-ready customer profile
       │
       ▼
AI application / agent

Keeping this distinction also has a practical advantage.

If identity-resolution rules change, or a source system introduces new information, the customer profiles can be recalculated from the underlying data rather than becoming another independent data store whose contents have to be maintained manually.

That is particularly useful as AI applications evolve and require different views of the same customer data.

Where does the CDP fit?

This naturally raises the question of whether a Customer Data Platform is the right way to implement this layer.

A CDP can bring together information from multiple systems, resolve customer identities, create unified profiles, and make those profiles available to other applications. These capabilities can provide an important part of the foundation required by Customer AI.

There is, however, a difference between having a unified customer profile and having a profile designed to provide reliable context to AI applications.

Many CDP implementations have historically been centered on marketing use cases: segmentation, audience creation, campaign activation, and personalization.

Those use cases remain relevant, but an AI application may have different requirements.

It may need to understand the relationship between a person and an organization, distinguish current information from historical information, trace information back to its source, or understand why two records were considered to represent the same entity.

For this reason, when evaluating a CDP for AI use cases, it is worth looking beyond the number of connectors or activation destinations.

The more fundamental question is how the platform represents customer identity and context, and whether that representation can be reliably consumed by applications outside the traditional marketing workflow.

Trust in AI also depends on the data foundation

Discussions about enterprise AI often concentrate on the model itself: accuracy, hallucinations, security, evaluation, and governance.

Those are all important areas.

But for customer-facing applications, there is another layer underneath them. The application needs to establish that the information it is using actually describes the right customer and that the information is sufficiently current and contextualized for the task.

That means being able to answer relatively practical questions.

Where did this information come from?

When was it updated?

Which identities have been connected?

Why were they connected?

What happened before the current state?

Can the relationship between two records be explained?

Can the profile be rebuilt if the underlying data or identity rules change?

These questions are primarily data and architecture questions, but they have direct consequences for AI applications.

A model can reason only over the context that is made available to it. If that context is fragmented or ambiguous, changing the model does not necessarily address the underlying problem.

Building the foundation for Customer AI

For organizations working toward Customer AI, the data foundation is therefore becoming an important part of the architecture.

It needs to bring together information from different systems, resolve identities, preserve the relationship with the original data, and provide applications with a consistent view of the customer.

In practice, this means being able to:

collect customer records and events from different systems
resolve identities across those systems
preserve source information and historical data
maintain relationships between people, companies, accounts, and other entities
provide sufficient context around customer information
apply appropriate governance and permissions
expose reliable customer profiles to applications that need them

A CDP can be one way of implementing these capabilities, but the architectural requirement exists independently of the product category.

As AI becomes more involved in customer service, sales, personalization, and other customer-facing processes, the quality of the underlying customer representation becomes increasingly important.

The challenge is not simply to make more data available to AI. It is to make the relevant customer context consistent enough that an AI application can use it without having to reconstruct the customer's identity and history from disconnected records every time.

That is the role of an AI-ready customer profile.

And in many organizations, building that profile may turn out to be one of the less visible, but more important, parts of the Customer AI architecture.

The real CDP decision: where should your customer profile live?

Marco Gazerro — Mon, 06 Jul 2026 12:18:27 +0000

Most CDP discussions I see start with features: connectors, audience builders, identity resolution, real-time events, and reverse ETL. But the harder question usually sits one level below the feature list: where should the customer profile actually live?

Imagine an AI assistant preparing a next-best-action suggestion for a sales rep. It can see signals from the CRM, billing, product usage, and the warehouse, but those systems may not agree on what the customer is doing or which state the account is really in. Before the assistant can recommend anything useful, the company has to decide which customer profile should be trusted, and where that profile should be built.

This is the basic prerequisite behind many AI use cases in marketing, sales, and customer success: a reliable view of the customer.

Whether the use case is an assistant that suggests the next best action for a sales rep, a workflow that prioritizes accounts at risk, or a campaign that adapts its message to product usage, they all need the same basic thing. They need to know who the customer is, what they did, which systems know something about them, and which version of that information should be trusted.

That sounds obvious until you look at how customer data usually lives inside a company. The CRM may hold contact and account details, billing may know the plan and payment history, the product database may have users and events, while support, email, and analytics tools each keep their own useful but partial view. Somewhere there may also be a data warehouse, where some or all of these signals are copied, modeled, and analyzed.

At that point, “the customer” is not a single record. It is closer to a distributed system, and this is the kind of problem Customer Data Platforms were created to solve.

The real CDP decision is not only which tool has the best connectors or audience builder. It is where the customer profile should live.

What a CDP is really doing

A Customer Data Platform, or CDP, is a system that collects customer data from different sources, connects records and identifiers that belong to the same person or account, builds customer profiles and segments, and makes those profiles available to other tools.

In practice, most CDPs deal with four broad jobs: collecting data, resolving identities, building profiles or audiences, and activating those audiences in downstream systems such as CRMs, email tools, ad platforms, support tools, or product engagement platforms.

For example, a CDP may receive an anonymous web event, later connect it to a logged-in user, enrich that user with CRM and billing data, place the user into a segment, and sync that segment to a marketing automation tool.

The value is easy to understand. Instead of every tool keeping its own partial view of the customer, the company gets a more coherent customer profile that can be used across teams.

The important question is not whether this is useful. It usually is. The more important question is where this profile should live.

The traditional model: the CDP as the center

Traditional CDPs solve the problem by creating a specialized platform with its own storage, data model, identity resolution logic, segmentation engine, and activation connectors.

The architecture is roughly this:

Sources → CDP database → Customer profiles / segments → Destinations

This model made a lot of sense, especially when many companies did not have a mature data warehouse or a data team able to build and maintain this infrastructure internally. A traditional CDP gave marketing and growth teams a ready-made environment to collect events, unify identities, build audiences, and push data to other tools without waiting months for a custom data platform.

This is worth saying clearly: traditional CDPs solved a real problem. They made customer data operational, not just analytical. They gave non-technical teams a way to work with data that would otherwise have stayed trapped in databases, logs, exports, or tickets in the data team backlog.

The trade-off is architectural. A traditional CDP often becomes another place where customer data lives. Data is copied from source systems into the CDP. The CDP builds its own representation of the customer. That representation may then coexist with another one in the data warehouse, another one in the CRM, and several partial versions in downstream tools.

That can work, but it introduces familiar problems: duplication, synchronization logic, possible inconsistencies, vendor lock-in, and governance that is split across multiple systems. If the CDP says a customer is “active” and the warehouse says they are “at risk,” which one is correct? If an AI workflow uses a customer profile, which version should it use?

These are not just philosophical questions. They become practical as soon as customer data starts driving automated decisions.

Why warehouse-first changed the conversation

Warehouse-first comes from a different context.

In many companies today, the data warehouse is no longer just a place for dashboards and monthly reports. It is where product events, CRM data, billing data, support data, marketing data, and finance data are combined. Whether the stack is built on Snowflake, BigQuery, Redshift, Databricks, or something else, the warehouse is often the closest thing the company has to a governed data foundation.

At that point, the CDP conversation changes. If the warehouse is already where the company combines and governs its data, it is reasonable to ask why the canonical customer profile should live somewhere else.

A warehouse-first CDP starts from this premise. Instead of treating the CDP vendor’s database as the center, it treats the customer’s warehouse as the center.

The architecture becomes closer to this:

Sources → Customer warehouse → Customer profiles / segments → Destinations

The CDP still has a job to do. It may handle ingestion, identity resolution, profile building, audience management, reverse ETL, or user-facing workflows. But the key difference is that the profile is built in the customer’s data environment, not inside a proprietary external silo.

For developers and data teams, this is the part that matters. The warehouse is queryable. It can be inspected. Models can be versioned. Lineage can be understood. Access control can follow existing policies. Profiles and segments can be reused by analytics, product, finance, customer success, and AI workflows, not only by marketing tools.

Warehouse-first is not always better, but it aligns the CDP with the place where many companies already manage their most important data assets.

Warehouse-first is not one architecture

Part of the confusion is that “warehouse-first CDP” is not a single architecture. It is a family of approaches.

Some tools are mostly read-in-place. They connect to tables that already exist in the warehouse, let users define audiences or mappings, and materialize only the outputs needed for activation.

Some tools are closer to reverse ETL platforms. They assume the warehouse already contains clean customer tables, traits, and segments, and focus on syncing those records to SaaS applications like Salesforce, HubSpot, Braze, Customer.io, Intercom, or advertising platforms.

Other systems take a more managed approach. They collect events, import identities and attributes from SaaS tools, and normalize everything into a canonical CDP schema inside the customer’s warehouse. On top of that schema, they perform identity resolution, build unified profiles, and activate those profiles back to downstream systems.

That last model matters because it sits between a pure “bring your own modeled tables” approach and a traditional CDP. It does create normalized tables, and in some cases that means duplicating data that was already present in the warehouse. But the copy lives in the customer’s warehouse, follows a schema the customer can inspect and control, and becomes part of the company’s own data architecture rather than a black box owned by the CDP vendor.

That is a small architectural detail with a large practical impact.

Duplication is not the real issue

Warehouse-first CDPs are often described as a way to avoid data duplication. That is directionally true compared with a traditional CDP that stores another customer database outside the warehouse, but it can also be misleading.

Some duplication is unavoidable. If customer data lives in SaaS tools, and you want to combine it with product usage, billing, support, and marketing data, you usually need to copy it into a common environment. If data already exists in the warehouse, it may still be useful to normalize it into a common schema for identity resolution, profile building, and activation.

So the real distinction is not “duplication or no duplication.” The better distinction is: who controls the duplication, where does it happen, and what purpose does it serve?

In a traditional CDP, the normalized customer profile often lives in the vendor’s platform. In a warehouse-first model, any necessary materialization happens in the customer’s warehouse. That does not eliminate every copy, but it avoids creating a separate proprietary customer data silo.

For a technical audience, this is the more honest way to frame it. Warehouse-first is not magic. It is an architectural choice. It says that if customer profiles, identities, and segments are strategic data assets, they should be built where the company can query them, govern them, reuse them, and move away from a vendor without losing the foundation of its customer data work.

AI raises the stakes

AI makes this discussion harder to ignore because it puts more pressure on the quality and consistency of customer context.

If AI systems are going to summarize accounts, suggest actions, personalize messages, classify users, detect churn risk, or update CRM records, they need customer context. That context cannot be a random mix of stale attributes, conflicting identifiers, and partial records from disconnected tools.

A traditional CDP can support AI use cases too. That is not the issue. But the warehouse-first model is often a more natural fit when AI needs cross-functional context: product usage, revenue, support, lifecycle, consent, account hierarchy, and operational history. Those signals often already exist, or should exist, in the warehouse.

In that sense, AI does not replace the need for a CDP. It raises the bar for what the underlying customer data layer needs to provide.

A CDP is an architecture decision

The comparison between traditional CDPs and warehouse-first CDPs is sometimes framed as a feature comparison: connectors, audience builder, real-time events, identity resolution, reverse ETL, and so on. Those features matter, but they are not the decision that shapes the architecture.

The core issue is where the customer profile should live. A traditional CDP builds it inside the CDP platform and activates it from there; a warehouse-first CDP builds it in the customer’s warehouse and uses the CDP layer to make it operational.

Both approaches can be valid, depending on the company’s maturity, team structure, use cases, and urgency. A marketing team without a mature data warehouse may get value from a traditional CDP faster. A company with a strong warehouse, a data team, and broader use cases across product, sales, customer success, and AI may prefer to keep the customer profile closer to its existing data foundation.

That trade-off should be explicit from the start. A CDP is not only a tool for sending audiences to other tools. It is a decision about the architecture of customer data.

Once customer data starts feeding automation and AI, that decision is no longer just an implementation detail.

This article was originally published on the Krenalis blog.

At Krenalis, we are building a warehouse-first CDP around the same idea: customer profiles should live in the company's own data environment, not in another proprietary silo.

You can learn more about our approach on the Krenalis website.

If the warehouse already has the data, why are we copying it elsewhere?

Marco Gazerro — Fri, 05 Jun 2026 09:10:49 +0000

When we started working on Krenalis, we spent a lot of time reviewing how customer data typically flows through a modern data stack.

One pattern kept showing up often enough that we started questioning it.

In many modern stacks, customer data already lands in a warehouse. Yet we often copy that same data into a CDP before we can start building customer profiles.

During one of those discussions, someone asked a question that sounded almost naive:

Why are we moving all this data in the first place?

Nobody had a particularly strong answer ready. The answer was mostly:

Because that's how CDPs work.

We expected the question to have an obvious answer. It didn't.

The warehouse is no longer just for analytics

Over the last few years, the role of the data warehouse has changed significantly. Warehouses are no longer just analytical systems. They're increasingly becoming the place where organizations centralize the context used by applications, AI agents, copilots, and business processes.

Customer data from systems like Shopify, Stripe, CRMs, support platforms, and internal applications often ends up there long before anyone starts thinking about segmentation or activation. In many organizations, the warehouse is already the place where teams answer questions about customers, revenue, retention, and product usage.

That made us wonder:

If the warehouse is already becoming the operational center of the data stack, why does customer identity usually live somewhere else?

Consider a customer who buys through Shopify, pays through Stripe, opens support tickets in Zendesk, and uses the product under a different email address. In many organizations, all of those records already end up in the warehouse. Yet building a unified profile often requires exporting that same data into another platform before identity can be resolved.

The cost of another copy

To be clear, data duplication is not inherently bad. Most software systems rely on some form of replication, caching, or denormalization.

The question is whether an additional copy is actually necessary.

When customer data exists across multiple platforms, a few familiar challenges tend to appear. Sooner or later, two systems report different numbers and someone has to determine which one is correct. As customer profiles become the result of multiple pipelines and transformations, understanding exactly how a profile was built becomes more difficult. Additional systems also introduce additional integrations, monitoring requirements, and opportunities for data drift.

None of these problems are unique to CDPs. They're simply common side effects of moving data between systems.

A different perspective

At some point we stopped asking:

How should we move data into the CDP?

and started asking:

What if we didn't?

Once we started looking at the problem from that angle, a warehouse-native architecture felt like the obvious thing to explore.

Instead of bringing customer data into the CDP, we started exploring what would happen if identity resolution, profile generation, and audience segmentation happened directly on top of the data that was already in the warehouse.

The underlying idea can be summarized in a simple sentence:

The CDP doesn't need to own the data. It only needs to understand it.

Whether that idea ultimately proves right or wrong is a different question. What mattered to us was that it seemed increasingly aligned with the direction the rest of the modern data stack was already taking.

Why this question feels relevant today

The idea behind Krenalis didn't emerge in isolation.

By the time we started working on it, many parts of the modern data stack had already moved closer to the warehouse. Analytics increasingly treats it as the source of truth, transformations often run there, and business logic is frequently built around it. More recently, AI applications and agent workflows have started using it as a source of context as well.

The trend itself wasn't particularly surprising. What caught our attention was the question that followed from it.

If so much of the modern data stack is converging around the warehouse, what does that mean for customer identity?

If customer events, transactions, support interactions, business metrics, and AI context are already stored in the warehouse, resolving customer identity there starts to feel less like a technical compromise and more like a natural extension of the same idea.

One aspect of this approach that we find particularly compelling is transparency. Customer identity becomes something that can be inspected, queried, and reasoned about using the same tools teams already use for the rest of their data.

Instead of treating identity as something produced by a separate platform, it becomes part of the data model itself.

There may still be good reasons to keep customer identity inside a dedicated system. Dedicated platforms can provide a better user experience, faster onboarding, and a simpler path for teams that don't want to operate directly on warehouse data.

But the more central the warehouse becomes, the more natural it feels to ask whether identity resolution should happen there too.

The trade-offs are real

Warehouse-native isn't a universal answer.

If a team doesn't already rely heavily on a data warehouse, introducing warehouse-native tooling may create more complexity than it removes. Likewise, if the primary goal is to launch campaigns quickly with minimal involvement from data teams, a traditional CDP may be a better fit.

A warehouse-native architecture also doesn't solve data quality problems. If customer data is incomplete, inconsistent, or fragmented, those issues remain. In fact, they often become more visible.

Depending on your perspective, that's either a benefit or an inconvenience.

A bet on where things might be heading

We're not arguing that every CDP should become warehouse-native.

Traditional CDPs solve real problems and continue to provide value for many organizations.

What interests us is a broader question. As warehouses become the foundation for analytics, business operations, AI applications, and agent workflows, will customer identity eventually follow the same path?

We think there is a strong case for that direction, especially in composable architectures where the warehouse is already the place where customer context is modeled, governed, and used.

Maybe this becomes the default model for some teams.

Maybe it remains one architectural option among many.

We kept coming back to that question, and eventually decided it was worth building around.

And it's one of the reasons Krenalis exists.

What do you think?

If you've worked on CDPs, customer identity, or warehouse-native architectures, we'd genuinely love to hear about your experience.

Leave a comment below or drop us a note at hello@krenalis.com.

For anyone interested in how we're approaching these problems, we've made the project repository available here:

https://github.com/krenalis/krenalis