CDPs, CRMs, and data warehouses are all built around the individual
Your current platforms differ in how much structure they define upfront, not in their core focus.
A CDP typically recognizes just one entity: the individual. An email address or phone number serves as the unique key to merge data into that profile. Everything you store is saved as an attribute of a person.
A CRM is slightly broader, covering the individual, the company, the deal, and a few related data points. It offers more scope, but is just as predetermined.
A custom-built data warehouse is the most flexible option, but even then, someone has to decide upfront which data to include, what to exclude, and how it all connects. In practice, IT makes these decisions based on what users requested at the time.
All three systems assume that your customer data can be neatly organized around the customer, and that the questions you ask today are the same as when the system was first configured. This approach falls short in three key areas.
Most of the data relevant to your customer is not actually about them
Take an airline, for example. You have customers, a fleet, flights that use that fleet, and tickets.
If you cancel a flight, that event is fundamentally about the flight itself. It affects the three hundred passengers booked on it, but the data point does not belong to them.
Inventory is no different. In a customer-centric model, you have to track who might be interested and the current stock level for each individual. But inventory belongs to the product, not the person. The same goes for store hours, order statuses, reviews, locations, and insurance policies.
This is not an edge case. This is the vast majority of the information you need to deliver meaningful customer communication.
When your model forces every data point to link directly to a person, one of two things happens. Either the data goes into a different system, or it gets forced into a place where it doesn't belong. We often see companies creating customer records for physical stores in their CRM just to get the data into the platform, even though the system was never designed for that.
That is not sloppiness; it is the only workaround the model allows.
Siloed systems store data, not relationships
Splitting your data comes at a cost, and it is not the price of storage. It is the loss of relationships.
If your reviews are stored in one system and your customer data in another, or your flights in one place and your passengers in another, you cannot connect the dots. Because the data does not live together, you cannot even ask the question, let alone find the answer.
Here is a concrete example. Who left a negative review? Which store are those reviews about? Is there a regional trend? Who lives nearby, and which of those neighbors have purchased from you before?
Each step relies on a relationship between data points that simply does not exist across siloed systems. Instead, you end up exporting data from Trustpilot, merging files, raising IT tickets, and planning sprints. By the time you get the insight, the momentum is gone. The wait is the symptom people complain about, but the root cause is that the relationship was never captured in the first place.
Even within a single system, you run into roadblocks. If you store everything as an attribute on the customer record, you only capture one-way causality: "this belongs to this customer." You cannot easily discover connections between the data points themselves. It is also incredibly slow. Without directional relationships, finding who wrote a negative review means scanning five million records for five million customers.
Those are just the "known unknowns", the obstacles you are already aware of. Beneath them lies a layer of "unknown unknowns": the insights you would discover if all your data actually lived together.
A rigid data model cannot adapt to your business
On average, a customer system of record remains in a company's application stack for five to seven years.
Consider how much AI has advanced in just the last three years, and then imagine relying for another six years on a foundation that is already causing friction today.
Because your business will change. If you are an insurer currently offering only auto insurance, expanding into home insurance introduces a new entity. This entity comes with new relationships to your existing services and to customers by region. In a rigid data model, adding this requires a formal request, a complex migration, and a long wait, or you might simply decide it is not worth the trouble.
AI agents need relationships, not profiles
There is a new type of user in town. While humans need a button-based interface, an AI agent requires an API or an abstraction layer like an MCP server. That difference is relatively minor.
What is not minor, however, is that an agent must be able to follow relationships that no one planned for. You cannot simply set an agent loose on your CDP, CRM, data warehouse, and data lake, expecting it to scan millions of records in each system to find a connection between X and Y.
Take a seemingly simple question: "What are the opening hours of the nearest store?" To answer this, an agent needs to know who the customer is, where they live, how far they are from your locations, and what those locations' current hours are. Store hours are rarely static: holidays shift, staffing shortages force temporary closures, or you might extend hours for a promotion. This leaves you with two scenarios: an agent that asks where the customer lives but still cannot provide the answer, or an agent that retrieves everything from a single source in one go.
Think about how you feed knowledge to an agent: crawling your website, uploading PDFs, and connecting your knowledge base so everything is searchable in one place. That works. Customer data is no different.
In a graph, the relationship itself is the data point
The Customer Context Platform is not a CDP, a CRM, or a data warehouse. It sits in between: a home for structured data that is relevant to your customer, without needing to be directly about them.
Picture nodes, circles containing a data point, connected by relationships. These relationships can be one-way or two-way. If they are directional, you need to know which node points to which.
For our airline example, this means managing four distinct entities side-by-side, rather than stuffing everything into a single profile:
Customer → has → Ticket
Ticket → for → Flight
Flight → operated by → Aircraft
You can add new entities in the data manager and map the relationships immediately, or discover them later. That is the key: you do not need to know how a data point relates to everything else upfront.
Do not confuse this with a knowledge graph. Knowledge graphs deal with fuzzy inputs like text snippets and PDFs to structure unstructured data. A CXP does the opposite: it makes structured data explorable in a more flexible, unstructured way.
A segment should be a question, not a project
A segment becomes a question. Today, segmentation is a rigid, predetermined exercise: you brainstorm what might be interesting, configure the rules, and generate a static bucket of customers. In a graph, you simply start with the "review" entity, select the negative ones, and follow the relationship back to the customers. You do not have to build the query just to ask the question.
Technology becomes a query. Until recently, "people who bought X also bought Y" was a complex big data challenge: pooling all events, applying collaborative filtering, and serving recommendations on your site. In a graph database, this is no longer an AI-heavy task. It is simple graph traversal, a query you can build with a few clicks.
Updating a single counter instead of a million records. If you have six items in stock and sell one, you simply update the product inventory to five without touching anything else. The relationships are already established, such as linking that product to customers who added it to their cart in the last ten days but did not check out.
Small questions become worth asking. Today, minor queries are often discarded due to the effort-to-value ratio. If a scenario only happens fifty times a day, setting up the tracking is too expensive. But when retrieving the answer costs next to nothing, you actually do it, and those small insights quickly add up.
Uncovering connections from conversations. Real-time insights extracted from customer conversations land directly in the graph. If you know a company exists and a person exists, but do not yet know that the person works there, you can capture that relationship the moment they mention it in a chat. While a CRM might handle this specific example, a graph allows you to extend this logic to entities that a CRM or CDP simply cannot accommodate.
Discovering unexpected segments. When all your data is connected, you can surface latent segments automatically instead of trying to brainstorm them, and these insights do not always have to start from the customer's perspective.
Predictions improve when relationships are already mapped
Once "people who bought X also bought Y" becomes a simple query, you can raise the bar for what you ask your AI to do.
Within CXP, we train a dedicated model for each customer, built entirely from scratch. While its architecture is similar to an LLM, it is much more compact and trained exclusively on your data. It is fully air-gapped and unique to your business. This model predicts what content to send to a customer, the best time to send it, and their likelihood of churning.
In our own customer tests, we saw recommendation hit rates double compared to the previous setup.
This is not just due to the data platform. The model itself is also more advanced than the one used in our previous CDP. The key advantage of the graph data model is that implicit relationships are already mapped. Because the model does not have to spend time discovering these connections during training, it can focus on deeper, more advanced learning.
You can also fine-tune the system. For example, you can apply business rules to filter recommendations for inventory clearance: if a product needs to be off the shelves within a month, you can prioritize it in recommendations even if it is not the absolute perfect fit. However, the core predictions work out of the box without requiring you to write any custom logic.
Not every business needs a graph
The primary benefit is not flexibility, but centralizing your data. You can achieve this with a data warehouse too, which is still far better than running ten disconnected systems. We go a step further: with our platform, this central repository does not need to be locked down upfront. You will notice the difference the moment your business needs to adapt.
However, we want to be completely transparent about two things.
First, if your customer relationships are straightforward and stable, and you already know exactly which data fields you will need five years from now, a standard CDP will serve you perfectly. In that case, we cannot offer you anything better.
Second, a flexible model cannot fix poor data input. If you are not extracting insights from your customer conversations, you will simply end up with an empty graph instead of an empty table. The graph is where your data lands, not the mechanism that generates it.
CXP is the data layer of the CM.com platform
CXP is our platform's open data layer. Instead of replacing your entire tech stack, you can easily connect your existing CRM, commerce platform, ERP, or data warehouse.
What sets us apart from standalone data platforms is our integrated channel infrastructure. Conversations flow directly through our network, where our Conversational Router analyzes language, intent, sentiment, and entities in real time, writing them directly to the graph regardless of the channel. There are no nightly batch imports or custom integrations to build. On the output side, your business users and HALO AI agents access this exact same context, while our custom prediction model runs directly on top of the graph for each customer.
After all, AI is only as smart as the context it is given.
