Contextual CDPs, is this the next-gen?
Part 1 of 6: What Model Context Protocols mean for the future of Customer Data Platforms.
There’s been a lot of noise lately about context windows, model memory, RAG systems, and how all these emerging AI patterns might play out across industries. And if you’re working in customer data or Martech, you’ve probably felt a mix of curiosity and overwhelm. I know I have.
So let’s slow it down for a moment and approach this from a different angle. I’m not an MCP expert, far from it. This series is more about curiosity than conclusions. It’s a way for me to explore how these ideas could apply to CDPs and the messy, fascinating work of customer data. Here’s the question I’ve been asking myself:
What happens when we stop thinking of a CDP as a static profile store and start treating it like a dynamic context engine?
Because the answer opens up a whole world of possibilities, ones that go far beyond better segmentation or audience targeting. We're talking about profiles that adapt in real time, decisions that reflect actual customer intent, and systems that can remember nuance.
From static profiles to dynamic context
The traditional promise of the CDP has been pretty consistent: unify customer data into a single profile, stitch events across systems, make that profile available to your tools. But lately, I’ve been wondering if that framing is starting to show its age.
Modern customer experiences are happening in real-time, across fragmented ecosystems, with constantly shifting context. And yet most CDPs are still acting like a slow-moving ledger, great for recordkeeping, less great for interpretation. It’s like using a filing cabinet to run a conversation.
This is where model context protocols (MCPs) come in.
Technologies like memory systems, retrieval-augmented generation (RAG), and context window management aren’t just useful for chatbots or generative apps. They point to a new way of thinking: one where context is not stored, it’s reconstructed and interpreted on demand. And that principle? It could be game-changing for the next generation of CDPs.
If we can reimagine context as a fluid layer that adapts to the task at hand, whether it’s support, personalization, compliance, or analytics, we can start to build systems that are genuinely customer-aware.
How model context protocols could rethink the CDP stack
Let’s get a bit imaginative.
What if, instead of only storing hard attributes and recent events, your CDP also worked with a memory system that could summarize the sentiment and needs expressed in a customer’s recent support call? Maybe even flag that this customer is getting frustrated, before they churn.
Or what if your identity resolution engine used a RAG pattern to dynamically retrieve fragments of a customer’s profile from different systems, based on what’s relevant to the moment, not just what’s stored in the core schema?
These aren’t technical fantasies. Tools like Tilores are experimenting with RAG-based resolution techniques. Tealium recently announced a formal integration of Model Context Protocols into their CDP stack, specifically to support real-time personalization, memory layering, and smarter orchestration.
I asked Tealium for a response to the series, and to their press release:
“As AI frameworks and design patterns proliferate, organizations need the ability to fuel their own AI models with clean, consented, and context-rich data. With Model Context Protocol (MCP) compatibility, Tealium empowers customers to stream real-time data into their AI stack using Tealium's Moments APIs → enabling more intelligent, privacy-compliant personalization across every touchpoint.”
~ BJ Allmon | Tealium
That’s a strong signal, not just experimentation, but a deliberate architectural choice to make customer data context-aware.
Hightouch, for comparison, is exploring reinforcement learning to drive agent-led decisioning. And while platforms like Amperity and Treasure Data have begun embedding intelligence across their ecosystems, it’s not yet clear whether they’ve adopted MCP principles or are building along adjacent paths.
What’s interesting here is less the tech, and more the implication: the customer profile becomes less of a static truth and more of a real-time construct, composed contextually, based on purpose.
Think about that for a second. A profile that can adapt itself depending on whether you’re personalizing a landing page, replying to a support request, or handling a privacy query. That’s a very different beast than the CDPs most teams are currently running.
It also changes how we think about orchestration. If every touchpoint has access to a slightly different "view" of the customer, tailored to the channel, the timing, and the intent, we move away from the myth of a single golden record and toward something more flexible, even empathetic.
The power (and risk) of inferred data
Here’s where things get interesting, at least for the seasoned professional. As soon as we let our CDP ecosystem start interpreting data, not just collecting it, we open up new opportunities and new responsibilities.
For example, memory systems can help us derive useful summaries: "This customer often responds well to direct messaging." Or, "They’ve repeatedly flagged sustainability as a key concern." These aren’t attributes someone manually entered into a CRM (we have definitely passed that opportunity). They’re inferred from tone, patterns, behavior.
This kind of contextual enrichment can massively improve how we engage. But it also needs to be transparent, ethical, and (where required) revocable. After all, if we’re building dynamic profiles from fuzzy memory, we’d better be able to explain what the AI remembered... and why.
Inferred data might also raise tensions internally: How do you explain to marketing that an AI thinks a customer prefers a certain tone of voice, based on a chatbot interaction from three months ago? That’s where interpretability and traceability become core features.
There’s a whole governance angle here, and I’ll get into that more in a later post because consent-aware prompting is going to matter a lot.
From golden record to contextual fragments
If we embrace the idea that a customer profile is no longer a single source of truth but a fluid, situation-dependent construct, we also have to let go of the notion that there’s one definitive view to maintain across all systems.
That golden record we’ve all been chasing? Maybe it was a useful metaphor when customer journeys were simpler. But today, it’s more like chasing a mirage, a record that’s always just a few interactions behind.
Instead, what we need are contextual fragments. Bits of insight that can be retrieved, interpreted, and composed on demand, depending on what the system, or the team, is trying to achieve. These fragments don’t live in one place. They’re distributed across systems: support logs, transaction histories, product usage, survey responses. MCPs don’t unify them into a giant data blob. They help us stitch together just what’s relevant for the moment.
Think of it like building a sentence instead of reciting a script. Every touchpoint forms its own version of the customer narrative → not arbitrarily, but purposefully. That kind of assembly demands new retrieval logic, trust models, and a willingness to accept that profiles are partial by nature.
And that’s okay. In fact, it might be the only way to keep up.
Looking ahead
In the next post, I’ll dig into how these ideas play out in real-time decisioning and cross-channel orchestration. And how memory systems can make that orchestration feel a whole lot more human.
But for now, just sit with this: your customer profile doesn’t have to be static. It can be fluid. Contextual. A living, partial truth that adapts to the moment.
And maybe that’s exactly what we need.
We don’t need more data. We need systems that understand the data we already have, moment to moment, and customer to customer.
I’m just scratching the surface here, but if this resonates, there’s more to come.
Part 3: Trust as a feature
Part 4: Building the bridge
Part 5: Composable, not chaotic
Part 6: Contextual Fluency