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 time. However, a year later, I'm watching the rest of the industry arrive at the same word from different doors, and the argument has changed.
Everyone arrived at the same word
Scott Brinker published "Systems of Context and Systems of Truth" in February, framing it as the mental model that replaces systems of record and systems of engagement now that AI agents are doing a lot of the engaging. Snowplow's Alex Dean, writing alongside Databricks, described a customer context layer where real-time behavioral signals flow into agents at the moment they decide. Amperity launched real-time customer context at Amplify 2026 as a shared layer unifying identity, behavior, and history. Lee Hammond raised the contextual CDP unprompted on a call with me two weeks ago. Frans Riemersma and the State of Martech 2026 report center context as one of the defining shifts of the year.
That convergence matters more than any single framing. When five smart, independent observers reach for the same word to describe the same underlying problem, the word has stopped being a positioning exercise and started being a shared reference point. The question is no longer what is context. It is:
What does the layer that holds it actually have to do?
In Part 1 I called these contextual fragments and described the customer profile as a real-time construct rather than a single golden record. A year on, with Scott Brinker calling it systems of context and Snowplow calling it a customer context layer, the thing has a name. So let's spend the rest of this piece on what that named thing has to do at the build level.
Four things the layer has to deliver
If an agent is going to act on behalf of a customer in real time, the layer it reads from has to do four things well. None of these are novel individually. The novelty is that they all have to be true at once, and most stacks deliver two out of four.
It has to be queryable. An agent deciding whether to send a message, hold a message, or escalate to a human needs to ask a specific question and get a specific answer back fast enough to act on it. Has this customer opened the last three sends is a query. Is this customer in an active service issue right now is a query. The layer either answers those in milliseconds or it doesn't, and if it doesn't, the agent either guesses or stalls. Both are bad outcomes. The build move is treating customer state as an API surface from day one, not as a report that gets refreshed nightly.
It has to be addressable. Every entity the agent might ask about needs a stable name. A customer, a household, a session, a cart, a service ticket, each of these is a thing the agent can fetch by key. This sounds basic and it is, but it's where a lot of real implementations come apart. Identity resolution gives you the customer key. The harder work is giving every other entity a key the agent can reach for too, and keeping those keys stable as the underlying systems change. The build move is publishing a small, deliberate set of addressable entities and letting agents read against those rather than against the source systems directly.
It has to be current. Current means current enough for the decision being made, which is a different threshold for different decisions. A churn-risk score can be current to yesterday. A cart-abandonment trigger needs to be current to the last few minutes. An in-session next-best-action needs to be current to the last few seconds. This is what I was reaching for in Part 2 when I argued real-time isn't speed, it's right time. The build move is being honest about which decisions need which freshness, and architecting the read paths accordingly. Trying to make everything sub-second is expensive and unnecessary. Letting everything default to overnight is cheaper and broken.
It has to be accountable. When an agent acts, you need to be able to ask later what it read, and when it read it. If you can't reconstruct the state the agent saw at the moment of decision, you can't debug the decision, you can't audit it, and you can't learn from it. This is the same ground I covered in Part 3 as trust as the interface and in Part 5 as the audit-friendly stack with narrative debugging. The build move is logging the read alongside the action. Not the whole profile, just the specific values the agent saw at the moment it acted. That log is what makes the layer trustworthy over time.
Queryable, addressable, current, accountable. Most stacks I've worked on deliver two of these well, a third sometimes, and the fourth as an aspiration. The work of the next two years, for most teams, is closing those gaps.
What this looks like next to the systems you already have
None of this replaces anything. The warehouse still stores. The CDP still resolves identity and persists the profile. The CEP still executes. If that is your martech stack at least.
What's new is the read layer that lives between the persistent systems and the agents asking questions of them. The systems-of-context framing is the cleanest mental model I've seen for where this lives: the systems of truth keep arbitrating what's canonical, and a thinner layer in front of them organises that truth for whatever context the agent is operating in.
That's also why composability stopped being chaotic, which is the argument I made in Part 5. The chaos wasn't composability itself. The chaos was composability without a shared read layer, which meant every consuming system invented its own version of the customer. Once the read layer is in place, composability becomes what it was always supposed to be: pick the best system for each job, knowing they all agree on what the customer looks like right now.
Martech Stack Builder
The interesting build questions
Three design choices are live right now in real implementations. None of them have a single right answer. All of them are worth your team chewing on.
How current is current? The temptation is to make everything as fresh as possible. The reality is that freshness costs money, latency, and operational complexity, and not every decision needs it. A useful exercise is to list the decisions your agents and workflows make, then assign each one a freshness tolerance: this minute, this hour, this day, this week. The shape of that list tells you which read paths need to be hot, which can be warm, and which can stay cold. Most teams find that a small number of decisions need real-time and the rest are fine on a slower cadence. That distribution is what your architecture should match.
How do you expose state without exposing everything? An agent asking is this customer eligible for the loyalty offer doesn't need the full profile. It needs the answer to that question. The build choice is whether to give agents access to the underlying attributes and let them compute the answer, or to expose pre-computed answers as named values. The first is flexible and harder to govern. The second is governed and harder to change. Most mature implementations I've seen end up doing both, with the named-value approach for high-volume decisions and the attribute approach for exploratory or edge cases. The trick is being deliberate about which is which.
How do you log the read? Logging every read at full fidelity is expensive and produces noise no one will ever look at. Logging nothing means you can't debug a bad agent decision after the fact. The middle path most teams are landing on is logging the read at the same grain as the action: if the agent took a decision, log the values it consulted to take that decision, with a timestamp. That gives you a replayable record of what the agent saw without drowning in observability cost. It's also the foundation for the audit trail you're going to need as regulators start asking harder questions about how automated decisions get made.
These are the questions I'd want a team to be able to answer before they commit to an architecture. Not because there's a textbook answer, but because the answers reveal what the team actually values.
Matthew Niederberger
Where to start this week
Pick one agent or workflow in your stack that's currently using customer state to make a decision. Could be a triggered email, a personalised recommendation, an in-app message, a routing rule. Anything where state shapes the action.
Trace three things on one page.
- What does it read?
- When does it read it?
- How stale is that read by the time the action fires?
That single page is the smallest useful version of a context audit.
It will tell you, immediately, which of the four properties you're delivering for that one decision and which you're not. The gap is your first meter of work. Do it for one agent this week, two more next week, and within a month you'll have a map of where your stack actually stands against what agentic marketing needs. That's a more useful artefact than any architecture diagram you could buy.
Read the full Contextual CDP series:
- Part 1: Contextual CDPs, is this the next-gen?
- Part 2: Memory, not identity, is what makes context work
- Part 3: Trust as a feature
- Part 4: Building the bridge
- Part 5: Composable, not chaotic
- Part 6: Contextual Fluency
Do you have any questions after reading this article?
Or need support with your Martech projects?
Discussion