Contextual CDPs: the context layer in six parts

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

Contextual CDP, let me explain why...

A personal message on my motivations for writing the series.

I’ve just kicked off a new blog series on something I’ve been thinking about a lot lately: how customer data platforms could work if they were built around context, not just profiles.

This short video (<4 minutes) is a personal reflection on what led me to write the series, what I’m exploring, and how memory, inference, and nuance might change the way we think about CDPs.

Curious what you think. Watch the video, then let me know what questions it raises for you.

Contextual CDPs: Memory, not identity, is what makes context work

Part 2 of 6: How model context protocols could replace the brittle logic of user tracking.

In Part 1, I explored how model context protocols (MCPs) could shift CDPs from passive data stores into dynamic context engines. Profiles that update themselves in the moment, based on intent, tone, and history. Not just segments, but signals. And now? Let’s see what happens when those signals actually drive decisions… in real time, across multiple touchpoints.

Because here’s the next big unlock: context-aware orchestration.

Real-time isn’t just about speed

Let’s be honest, "real-time" has been one of those buzziest of buzzwords we’ve collectively abused for years. It often means “fast batch,

Contextual CDPs: Trust as a feature

Part 3 of 6: Why identity graphs can’t create relationships, and how context might.

In Part 1, I looked at how model context protocols could reshape the customer profile, from static to dynamic, from collected to interpreted. In Part 2, I spoke about how that same shift could drive smarter, more human orchestration across channels and touchpoints.

But there’s a deeper layer we need to talk about. Not tech. Not tactics. Trust.

Because when our systems start inferring, remembering, and deciding → the stakes change. And our responsibilities as builders shift right along with them.

Dynamic Context == Dynamic Responsibility

With great memory comes great obligation.

Sorry, Uncle Ben.

When we move from static profiles

Contextual CDPs: Building the bridge

Part 4 of 6: What connects today's CDPs to tomorrow’s agent-driven context

If the first three parts of this series explored what’s possible when context becomes the driving force behind customer data, then this one asks a more grounded question:

How do we actually get there?

I’ve spoken with teams who are genuinely excited by the idea of using memory, inference, and context to make their CDPs smarter. But many feel stuck between inspiration and implementation. They see the potential, but don’t quite know where to start.

Let’s be honest, the martech stack is already complex enough. The last thing anyone wants is to bolt on a new

Contextual CDPs: Composable, not chaotic

Part 5 of 6: Contextual CDPs need lightweight structure, not heavyweight rebuilds

By now, we’ve explored what context can unlock in a CDP, from dynamic profiling to real-time orchestration and trust. We’ve talked about layering memory and inference without blowing up your current stack. So in this fifth part, let’s look at what happens when you want to make these contextual layers stick… without making everything feel like a pile of duct-taped services.

Because that’s the risk. Composability gives us incredible flexibility, but without some architectural discipline, it becomes hard to explain, harder to maintain, and impossible to govern.

Let’s explore how to structure context-

Contextual CDPs: Contextual Fluency

Part 6 of 6: Being contextual is also about competence.

Over the last five posts, we’ve moved from speculative to strategic to practical. We’ve looked at how memory, inference, and model context protocols can enhance personalization, orchestration, governance, and architecture in and around the CDP. So, where does that leave us?

Right here.. yes, with the last post in the series, but more importantly, with the people, with YOU!

Because it’s one thing to build a system that can understand context. It’s another thing entirely to make that understanding usable across your organization. That’s what this final piece is about, turning contextual awareness into team

What does the context layer actually have to do?

Queryable, addressable, current, accountable. Four things the layer of customer state has to deliver if AI agents are going to act on it in real time. A follow-up to the six-part Contextual CDPs series, written a year on, now that the industry has caught up to the language.

A follow-up to the six-part Contextual CDPs series.

A year ago, I published a six-part series on contextual CDPs. It started with MCPs reframing the CDP as a dynamic context engine, then memory as the orchestration layer, then trust as the interface when systems start to infer and decide, then the practical bridge between today's stack and an agent-driven future, then composability that needs sequence and scaffolding rather than more connectors, and finally contextual fluency as a human skill rather than a technical one.

I thought I was making an argument that needed defending at

The Context Audit

A follow-up to the follow-up. My last piece explaining "what the context layers has to do" argued that customer state has to be Queryable, Addressable, Current, and Accountable if agents are going to act on it in real time. It ended pointing at a one-page audit and stopped there.

This is that audit.

The context layer's job is to make the customer state usable when an agent needs to act on it. Whether it's doing that job is not a question anyone can answer from an architecture diagram. Architecture diagrams describe

Which context wins when two systems disagree about your customer?

Two systems calculate lifetime value differently and nobody has said which counts. I tried to score that in my context audit and broke my own rubric.

Back in June, while writing about composable CDPs, I asked a question and then, like a distracted person, walked straight past it.

When two systems disagree about something like a customer's email opt-in status, which value wins, and is that rule written down anywhere?

I gave it one line of answer. In packaged systems the vendor sorts it out for you, in composable systems the work goes to your data team. Both true, but neither one tells you which number is right. That has bothered me on and off ever since.

Composable CDP, translated for marketers

Composable CDP

Posts tagged with Contextual CDPs

Real-time isn’t just about speed

Dynamic Context == Dynamic Responsibility