3D visualization of a unified AI data layer connecting multiple customer data sources to personalization, search, and audience experiences.
Back to home

SitecoreAI's quiet unification: one data layer under everything

Miguel Minoldo's picture
Miguel Minoldo

If you only read the SitecoreAI changelog for the headline items, you missed the more important story.

The agents, the Marketer MCP, the Agentic Studio. Those got the stage time at SUGCON events. They are easy to demo and easy to write about, but the releases that actually change how you architect on the platform shipped quietly, one small changelog entry at a time, over the last few months.

Identity resolution, Affinities, Profiles, Component personalization, affinities as an audience condition: each one landed as a modest "feature is rolling out in phases" note. None of them made enough noise.

Put them next to each other and they are the same move. SitecoreAI now has one unified profile layer, and almost every surface on the platform reads from it. The loud features work because the quiet ones shipped first.

What changed underneath

For most of the composable era, the visitor profile was something you assembled. You wired CDP to the CMS, you pushed segments back through a webhook, you reconciled identities across SDKs yourself. The profile existed, but it was the output of an integration you owned.

In SitecoreAI the profile is the substrate, not the output. Three releases made that real, and they stack on top of each other in a specific order.

  • Identity resolution links fragmented interactions into a single profile. Without it, a visitor is a pile of disconnected sessions and client IDs. With it, those sessions collapse into one record with continuity across devices. The docs are blunt about the dependency: without identity resolution, profiles stay fragmented and carry less actionable data.
  • Affinities sit on top of that. They are computed interest signals, derived from what the visitor actually viewed, not what someone tagged them with. The algorithm watches page views and learns, for example, that a visitor leans toward content of type blog, then boosts results accordingly. This is a model, not a rule a marketer wrote by hand.
  • Profiles make the layer legible. Shipped at the end of March, the Profiles view in Audience and insights gives you a session heatmap, daily device usage, top affinities, and a world map of session locations per visitor. A month later it got live monitoring, refreshing every 30 seconds so you can watch open sessions as they happen.

So the order is deliberate: Identity resolution unifies, Affinities enrich and Profiles expose. Each layer is fed by the same VIEW and IDENTITY events your Cloud SDK already emits.

The same data now feeds every surface

Here is the part worth slowing down on. The unified profile is not a reporting feature that lives off to the side. It is the input to everything you build.

SitecoreAI surfaces (what marketers and agents touch)
Click to expand
SitecoreAI surfaces (what marketers and agents touch)

Walk the surfaces left to right.

Component personalization was, for me, the first visible proof that the layer existed. I wrote about it on LinkedIn when it dropped, because it solved a real complaint from teams coming off XP: page variants were too coarse, and now you can target a single banner or CTA without owning the whole page. The mechanism is a decision table that evaluates each visitor against rules built on profile data, conditions, or custom values. That decision table only makes sense if there is a profile to evaluate. It is the unified layer, consumed at the component grain.

Audiences consume the same layer from the other direction. When you build an audience in Personalize mode, one of the condition templates is Affinities, the exact same affinity model from Audience and insights. So the signal the platform computed about a visitor's interests is not locked inside an analytics screen. It is a condition you can drop into a real-time targeting rule. That is the unification, made concrete in the page builder.

Search relevancy is the one most people will not notice. In SitecoreAI search, results are ordered by a single relevancy score, and the docs list its inputs plainly: textual relevance, personalization, and ranking. Personalization is now a native factor in the search score, not a layer you bolt on afterward. The same profile that decides which banner shows can influence which results rank first. You still get boost, bury, and pin rules on top for editorial control, but the baseline order already knows who is asking.

The Agent API and Marketer MCP are the programmatic face of all of it. The May Agent API v2.0 release and the matching Marketer MCP update added tools like create_perso_version_multi and update_perso_version, so an agent can create and update personalization variants against multiple audience conditions without a human in the page builder. (Worth flagging if you have automation in production: the v1.0 personalization endpoints are deprecated and scheduled for removal on 4 August 2026.)

Why the agent layer needed this first

This reframes the agent story.

An agent that "optimizes experiences" is only as good as the data and the surfaces it can act on. If your profile data is fragmented, your affinities do not exist, and your personalization is page-level only, then an autonomous agent has almost nothing useful to do. It cannot target a component, because component targeting did not exist. It cannot reason about a visitor, because the visitor was a scatter of sessions.

The quiet releases built the preconditions. Identity resolution gave the agent a coherent subject. Affinities gave it signal. Component personalization gave it a fine-grained surface to act on. The Agent API gave it the verbs. The demo-friendly part, an agent creating personalization variants, is the last brick, not the foundation.

That is why I would not evaluate these as separate features. They are one architectural decision, released in pieces.

Where this is honestly still early

I am not going to oversell it. The unified layer is real, but it is early, and a few things will bite you if you assume it is finished.

It is gated by a phased rollout. Profiles, component personalization, and the search rules all carry the same note: the feature may not be in your organization yet. So "SitecoreAI has this" and "your tenant has this" are different statements. Check before you promise it to a client.

The layer is only as good as its setup. Profiles without identity resolution and affinities are fragmented and thin. The richness everyone wants depends on capturing enough VIEW and IDENTITY events, and on doing the identity work first. This is configuration, not magic.

The Profiles view has hard limits. It surfaces the 500 most recent visitors, a maximum of 40 sessions per profile over 90 days, 100 events per session, and 10 client IDs. It is an operational lens on recent activity, not a data warehouse. If your use case is long-horizon analytics, that lives elsewhere (more on that below).

Order matters, and it is not always obvious. Component personalization uses a decision table that returns the first matching rule, and your default is the last row, not an implicit fallback. Search boost and bury rules higher in the list override the ones beneath them, and when semantic reranking is on, boost and bury override semantic relevance while pinned slots stay pinned. None of this is hard, but it is the kind of thing that produces a "why is this visitor seeing that" ticket if you build without thinking about evaluation order.

Where it is heading

The direction Sitecore set out at the Symposium makes the intent explicit. The traditional CDP is being positioned as a centralized unified data layer, Azure-native, with the ability to use Microsoft Fabric shortcuts, pipelines, and transformations against that data.

Read that next to the limits above and the picture is consistent. The in-product Profiles view is the operational, real-time face of the layer. Fabric and OneLake are the analytical, long-horizon face of the same data. One profile, two consumption patterns. I would treat the Fabric piece as roadmap rather than something to design a delivery on today, but the direction tells you where the boundary between "operational personalization" and "enterprise analytics" is going to sit.

What this means if you architect on the platform

A few practical shifts I am already making in discovery conversations.

Stop scoring SitecoreAI feature by feature. The right question is not "does it have component personalization" or "does it have profiles." It is "how mature is the data layer, and how much of my use case can read from one source instead of an integration I maintain." That is a different evaluation, and it usually favors native more than the feature checklist does.

If a client's roadmap includes AI-driven automation inside the DXP, the unified layer is the enabling architecture, not a nice-to-have. Every agent action that touches both content and audience data is cheap when they share a layer and expensive when they do not. I made this same point in the CDP comparison, and the agent releases only sharpen it.

And do the unglamorous work first. Identity resolution and affinity setup are the foundation that makes everything above them worth using. A personalization strategy on top of a fragmented profile is a demo, not a system.

Closing thought

The interesting thing about this round of releases is how little attention they got relative to how much they change. Nobody ships a press release for "identity resolution is now generally available." But that is the release that makes the agent, the component variant, and the personalized search result all draw from the same picture of the visitor.

The headline features were the proof. The data layer underneath them was the work.

If you are seeing the unified layer behave differently in production, especially around affinity quality once identity resolution is properly set up, I would be interested to compare notes.

References

Tags:
SitecoreAISitecoreCDPPersonalizePersonalizationProfilesComponentPersonalizationMarketerMCPDataLayer DXP