What Is a DXP in 2026?

The CMS Is Still the Anchor

Whatever else a DXP becomes, it still rests on content management. A platform without a true CMS is an orchestration layer, an experience layer, or a point solution wearing a broader label. But it isn't a DXP in the way most of the market still uses the term. Content creation, structured modeling, governance, and delivery remain the core of the platform.

The rare exceptions are worth understanding precisely because they prove the rule. For example, Uniform offers a genuinely composable DXP that's so flexible, you can run it on an alternative CMS altogether, plugging in almost any headless or traditional system through a connector.

This is possible because of where Uniform came from: its heritage is experience orchestration, and it incorporated its own headless CMS only a couple of years ago. As such, it treats the CMS as one more connected component rather than as the foundation that everything else depends on.

Most platforms can't make this claim. And the fact that the flexibility traces back to an orchestration-first origin – rather than a content-first one – tells you how unusual it is. For the rest of the market, remove the CMS, and the platform stops being itself.

This is also where discoverability for AI belongs, and it gets marketed as a platform-level differentiator, with some vendors now claiming to have a GEO-Ready (Generative Engine Optimization) CMS. In practice, that capability can sit within the CMS, though it's sometimes handled adjacent to the search platform instead.

AEO (Answer Engine Optimization) is another key capability that's designed to help brands influence answer engines like ChatGPT and Google AI Overviews. This optimization relies on how content is structured, marked up, and exposed – including schema, metadata, clean structured fields, llms.txt, and other structural dimensions.

This is also where one of the "quieter" shifts in the category is showing up, because the audience for a digital experience is no longer only human. Agents represent more of the internet's traffic, reading more content and acting on it on behalf of users. This moves discoverability from traditional SEO rankings to AEO mentions and citations, and content must be legible to systems that are, themselves, doing the selecting. Legibility is won or lost where content meets retrieval.

Adding these capabilities is a change in what a DXP is delivering – and delivering against. It also raises the stakes on the content and search layers rather than introducing a separate one.

'Native Everything' Was Never the Test

A common misreading of the DXP category is that a truly complete platform has to provide every capability itself. It does not – and it never did.

That said, there are a few components that do tend to sit at the core, where buyers reasonably expect native strength. This includes CMS, personalization, and experimentation, the capabilities most associated with a DXP, and the ones a platform is expected to own rather than borrow.

Beyond that core, what matters is how cleanly a platform offers the capabilities it does not provide directly. This comes down to strong connectors, well-documented APIs, and a clear answer for the systems outside its walls.

DAMs (Digital Asset Management systems), search, and commerce are the components most often handled this way. These are also the capabilities a DXP may provide natively, but are just as legitimately expected to be covered through integration. Here's some additional detail:

The DAM is one example of that "connect-or-provide" pattern. Not every DXP ships an enterprise-grade DAM system. That's fine, provided there are connectors to the DAMs an organization is likely to run, whether that's Bynder, Canto, or another established player.

Search follows the same pattern across a spectrum. Some platforms ship basic search as a built-in feature, while others lean on connectors to dedicated providers like Algolia or Coveo. And a few carry genuinely robust native search, like Squiz does with Funnelback. Search matters more than its quiet reputation suggests, because it's the mechanism underneath the machine-audience shift. This is because an answer engine or an on-site agent retrieves and ranks content before it ever presents or acts on it.

Commerce sits in the same group. Some of the major DXP vendors offer a commerce solution, frequently one that arrived through acquisition, while others provide connectors to dedicated commerce platforms. It's not surprising that the depth of integration with the rest of the DXP is not always as good as the native components.

Across all of these areas, the presence or absence of any single component tells you far less about how well the platform reaches the adjacent stack and how much friction that reach involves in practice. A DXP that owns fewer components but integrates cleanly is often a better fit than one that owns everything and integrates poorly.

Two capabilities worth naming as "optional" are content operations and analytics. Neither is a requirement for an offering to qualify as a DXP, but content operations is a place where foresight has paid off for a couple of vendors: Optimizely and Sitecore.

Both acquired a CMP (Content Marketing Platform) several years ago and integrated it at a core level. This has been a real advantage for clients that lean heavily on editorial planning and workflow. If you choose a DXP without CMP capabilities – and later decide you need it – this can be a difficult gap to fill.

Analytics is similar in that most platforms integrate with analytics tools that pipe into data warehouses and ultimately into the CDP. But having it natively is not something a DXP is required to provide.

How Does the Platform Handle Integration and Orchestration?

If integration is the test, then how a platform approaches it becomes a defining characteristic. This is where DXP vendors diverge structurally rather than just on feature lists.

The most useful question is what the native tooling actually is: a full integration framework built into the platform, an iPaaS layer, or a library of prebuilt connectors for common systems.

Squiz, for instance, treats a genuine integration layer as a first-class part of its DXP, which is different from a catalog of connectors. What makes Squiz's layer notable is that it extends to content orchestration, helping organizations that already run multiple CMS solutions pull and unify content across them, a problem most platforms leave to the customer.

Sitecore Connect, which is built on Workato, is an interesting case. The integration engine is a third-party platform embedded in the offering, rather than a homegrown solution. A real iPaaS layer and a connector library imply different things about how much custom integration work an organization can do itself – and how far it can reach beyond a vendor's connectors.

Customer Data Sits Closer to the Core Than It Looks

The customer data layer deserves to be singled out – and for good reason. It shapes so much of what a DXP does and is frequently misunderstood as a peripheral consideration.

As previously stated, most of the major DXP vendors acquired a CDP years ago and wove it deep into their platforms. That data layer now underpins far more than a dashboard of audiences. It powers hyper-personalization, feeds experimentation, informs recommendations, and supplies the signals that agents increasingly reason over.

This made the unified customer profile one of the most important elements of a modern DXP. Rather than a standalone module sitting off to the side, it reaches outward, integrating with tools like marketing automation platforms – so that the same profiles power personalized communications across channels like email.

In principle, the CDP and personalization engine should be cleanly separable, one feeding the other through a defined interface. But in most composable suites, they aren't – because vendors bound their CDPs tightly to their personalization capabilities. As a result, the two ended up deeply intertwined, which is why a platform's personalization is often only as good as the customer data feeding it. It's also why swapping one without disturbing the other is harder than the architecture diagram suggests.

A DXP needs to connect audience, event, and profile data into experiences – and do it all in real time. The harder question is not whether the platform can achieve this, but how much of that data layer it expects to own rather than share with the rest of the enterprise. That's exactly where the composability claims start to fray, because the customer data layer is one of the components vendors most often describe as "open," when it is anything but.

What Does 'Composable' Actually Mean When You Test It?

Composability is the claim most worth pressure-testing, because it's where vendor positioning and architectural reality separate most cleanly.

Several of the traditional DXP vendors now describe themselves as composable suites, promising that you can swap in the components you prefer and replace the ones you don't.

The honest test is narrower than the pitch: can you replace a given component and keep the personalization, experimentation, and governance value the platform was sold on?

The CDP is one example, and a telling one with composable suites, or with traditional composable vendors transitioning into composable suites. In practice, "bring your own CDP" usually means feeding your data into the vendor's CDP, the one that actually powers more advanced personalization. The integration is real, but you haven't replaced a component. You've added a source to one that was always going to stay in place.

The same pattern holds more broadly, since removing the native CMS (assuming the platform even permits it) frequently breaks personalization and experimentation, because they were built against that CMS rather than against an abstraction. The components are composable with each other far more than they are composable with the outside world.

The genuinely open end of the spectrum does exist, where a platform built to orchestrate other systems treats its components as interchangeable in a way most content-first platforms never will. Most vendors have not made that choice, and for many buyers, they don't need to.

Deep coupling is not the problem here. Mislabeling it as composability is. Where a component is not genuinely swappable, the platform is still a capable integrated suite with a good integration story – and it's simply not composable in the sense the buyer was led to picture.

Where Does the Agentic Layer Fit?

This is becoming the central question. The agentic framework is the newest layer in the ecosystem, and the one driving all of the rebranding.

The real shift is from AI spread horizontally across components – which most platforms have offered for several years – to an agentic system that can act with some autonomy and coordinate across the platform. The first assists a person doing the work, while the second does the multi-step work itself. This is a different proposition for what a DXP is and how much of the operating model runs through it.

A few things separate the substance from the positioning. I've written about evaluating the agentic offering in more depth, but I'll provide the short version here for what to look for:

Most platforms now offer a common AI assistant. The more telling question is whether you can build your own agents for use cases the vendor has not predefined, and whether you can chain them into genuine multi-agent orchestration that spans multiple products and components.

Interoperability is the other piece. Specifically, whether the platform or its individual products expose an MCP server, so that agents with an external framework can use and act on a DXP's data. This is a big question, given that in a multi-vendor composable scenario, support often sits at the product level rather than across the suite.

When a vendor rebrands around this layer, the agentic framework is positioned as the defining characteristic of the platform. But I believe it is more accurate to see it as the newest capability running across an ecosystem whose center has not moved.

Timing varies across the market, and a credible DXP today may still be building this layer out rather than shipping it – so its absence right now doesn't leave anyone out of the category.

The agentic direction, though, is not really in question. Most vendors made big moves last year, and the rest are acting now. By 2027, it would be surprising to find a DXP without an agentic layer of some kind, which is what makes it part of a forward-looking definition – even as the timelines differ.

What Still Has to Be True

The category's central question is whether a DXP is a product you buy – or a martech stack philosophy you assemble. Suite-oriented platforms answer that one way, composable architectures answer it another, and the agentic rebranding sits across both.

If the term is going to mean something specific in 2026, a few "tells" separate a DXP from a point solution or an orchestration layer wearing the label:

1. There is a true CMS at the center. Content creation, structured modeling, governance, and delivery are first-class – not bolted on.
2. Personalization and experimentation are part of the core. Alongside the CMS, these are the capabilities a DXP is expected to own rather than borrow.
3. Customer data is core infrastructure, not a side module. A unified profile feeds personalization, supports targeting and measurement across experiments, and reaches outward to channels like email, and the platform has a clear position on how much of that data layer it owns versus shares with the enterprise.
4. It connects to the broader martech stack. Strong connectors, documented APIs, and a clear native integration model – whether a genuine iPaaS layer or a well-maintained connector library – matter more than owning every component natively, whether the component in question is a DAM, search, or commerce.
5. Its composability claims survive a real test. You can point to which components are genuinely swappable and which are coupled, rather than taking "composable" at face value.
6. It carries, or is clearly building toward, an agentic layer that runs across the ecosystem. Not a single assistant inside one product, but agents you can build and chain, with a position on multi-agent orchestration and MCP. By 2027, this will be hard to do without.

A platform that meets these criteria functions as a hub for an ecosystem of capabilities and still fits the DXP label as it currently implies – even if the agentic layer is still maturing across much of the market.

The read today is as much about where a platform is heading as where it stands. A DXP that meets only some of them may be excellent at what it does, but the label is describing an ambition rather than a reality. And knowing the difference is what makes the category more navigable.