Like every other MarTech domain, AI is shaking up how people think about one of the traditionally most difficult marketing aspirations: personalization. In the first of a two-part series, I’ll review an age-old architectural question for enterprise marketers…Where should personalization live?

Should it sit:

• In a central decisioning layer?
• Inside channel-specific platforms?
• In a data platform, such as a customer data platform (CDP)?
• Somewhere in the content stack?
• Somewhere else altogether?

The usual answer was “it depends.” However, as a practical matter, MarTech leaders and architectures have traditionally not been presented with a choice, since nearly all personalization services to date have shown up in a channel context, mixing logic, data, content, execution, and measurement all within that silo.

That’s been convenient, but problematic. For example, content rendering may sit close to the channel, whereas offer eligibility may sit somewhere else. Consent or suppression rules need broader visibility.

So the overall ambition never died. Enterprises quite rightly seek to coordinate the customer experience across channels rather than letting each touchpoint make its own decisions in a limited context. That’s just been hard to pull off, and so here we are, with the graphic below showing current state circa 2026.

AI raises that question again.

Every MarTech vendor now claims to have an AI-led personalization story. Most email vendors promise AI-driven message creation. Content tools offer AI-based dynamic assembly using content fragments (also AI-generated). Web platforms promise real-time adaptation. Video platforms offer one-to-one variants. Agent builders claim they can optimize customer journeys. CDP vendors will build custom segments for you. Even tools that started as copy generators now describe themselves as orchestration engines.

Some of this is obviously useful. But a lot of it is also marketing hype. What has certainly changed is that AI has lowered the nominal cost of local optimization inside individual tools. A system that used to handle a single, narrow function can now purport to generate variants, find patterns, adapt its output, and plausibly claim to personalize.

That creates a familiar enterprise problem in a new form: every local tool gets smarter within its own silo, but the overall customer treatment can still become less coordinated and potentially less effective.

I am using “customer treatment” deliberately here rather than the more common phrase “customer experience.” Customer experience is broader: what the customer perceives across brand, product, service, commerce, content, and support. Customer treatment is narrower and more operational. It is the action the enterprise chooses to take with a customer at a given moment: show an offer, suppress a campaign, escalate a service response, change the next message, or do nothing. That is the level at which personalization decisions are actually made.

Personalization is more than producing content variants

At Real Story Group, we have long argued that personalization involves a lot more than producing variants. It is about coordinating “customer treatment.” And, in addition to content variants, that also requires context, policies, constraints, prioritization, measurement, and some way to reconcile decisions across touchpoints.

No doubt, AI can help with parts of this. Generative AI can create tailored copies, localize offers, adapt images to channels and sizes, summarize customer context, and assemble interaction fragments faster than older production models. Insights AI can help by scoring signals and surfacing patterns that would have been hard to spot manually. Decisioning AI can help rank options, arbitrate offers, and adjust treatment paths.

However, those capabilities still leave a gap in your personalization strategy, since they do not, by themselves, coordinate customer treatment across the enterprise. A web tool can adapt a page, an email tool can generate a message, and a service tool can summarize context, but each may still be working from its own identity, rules, content, and success metrics.

Many vendor demos gloss over this part. AI can make personalization easier to implement, demo, and justify inside a local tool. But that does not answer the architecture question: which decisions belong inside the channel, and which decisions need to be governed underneath the channel?

Content adaptation Vs treatment decisions

I would like to propose a useful distinction here between content adaptation and treatment decisioning.

Content adaptation is about how something gets said or rendered. Should the copy be shorter? Should the image change? Should the message be adapted for mobile? Should a service response be rewritten in simpler language? GenAI can be useful here, especially when it works from approved content, brand rules, and channel constraints.

Treatment decisioning is a different aspect. Who should receive this offer? Should this customer receive a sales message at all? Should the service interaction temporarily suppress marketing? Which channel should take precedence? What happens when a high-value retention offer conflicts with a compliance constraint or a customer fatigue rule?

Many tools do content adaptation, but imply that they are personalizing decisions. Buyers should separate those two. A system that generates twenty versions of copy may accelerate a campaign. But that does not mean it can decide who should get what, under what constraints, in what sequence, and with what trade-offs across channels.

That distinction is useful because enterprises often confuse campaign acceleration with personalization, and personalization with decisioning. AI will make that confusion more common unless buyers force the conversation about architecture earlier.

Omnichannel can fragment again

For the better part of two decades, enterprises have talked about omnichannel personalization while continuing to operate in siloed channels. Email teams work on optimizing emails. Web teams optimized web content. Call center teams optimized service. Data might be shared, but decisions were still often made locally.

AI can make that drift worse by making local personalization easier to rationalize. It is now relatively easy for each vendor to say, “Why wait for a shared layer? We can personalize right here.”

Sometimes that is indeed a reasonable choice. Channel-native rendering should usually stay local. Format adaptation is local. Creative assembly often belongs close to execution. Some experiments work best inside a specific channel. It would be a mistake to centralize every micro-decision.

Therefore, some things still need to sit below your channels. They need to be abstracted out of channels into an independent layer.

Enterprises need a common approach to identity, eligibility, prioritization, frequency rules, compliance guardrails, and measurement. Identity is especially important. If web, email, service, commerce, and mobile tools cannot agree on who the customer is, they cannot reliably coordinate treatment, suppress messages, manage frequency, or measure outcomes.

They also need some way to arbitrate across offers, messages, and touchpoints. Otherwise, the web experience, email campaign, outbound notification, and service interaction may all be “personalized,” but not coordinated.

Below, I’ll come back to the major risk you face here, around recreating all these enterprise services individually in each channel.

Orchestration is getting used too loosely

There is another source of confusion: orchestration. Vendors increasingly use that word for two different things:

The first is customer-facing orchestration. That means deciding which message, offer, service response, or experience should go to which person, account, or buying group, at what moment, in which channel. This is where decisioning, journey coordination, frequency management, eligibility rules, and arbitration belong.

The second is tool and process orchestration. That means coordinating the mechanics around customer engagement: content creation, approvals, compliance review, asset production, workflow routing, publishing, analytics, and execution handoffs.

Both are useful in themselves. However, they solve different problems.

Many newer AI and agentic vendors are stronger in the second category. They can help teams produce, review, adapt, and distribute content faster. They can sequence work across systems, invoke tools, check policies, trigger approvals, and maintain an evidence trail. Some can ingest audience signals and optimize within a campaign context.

That can be valuable. But an agent that coordinates workflow has not thereby become a customer treatment layer. It still needs shared identity, shared context, explicit permissions, decision rights, and a way to reconcile competing local optimizers.

Enterprises need a control layer for treatment decisions

The answer is not to centralize everything. Instead, consider what logic should remain shared, and what can safely be delegated to embedded AI in execution tools.

So think of this as a control layer for treatment decisions. It does not have to render every page, generate every email, or assemble every asset. Channels can still execute locally. But the shared layer needs to coordinate decisions that should not be made independently within each channel.

In practice, that layer needs to handle several functions:

• Planning and arbitration: sequence journeys and resolve conflicts among offers, messages, and service actions
• Policy and eligibility: apply consent, caps, suppression rules, compliance constraints, and qualification logic before execution
• Identity and permissions: Identity resolution determines the subject of the interaction: a person, an account, a household, a device, an anonymous visitor, an authenticated customer, or a buying group. This also defines what each tool is allowed to do
• Context packets: pass the relevant customer, journey, content, and policy context into execution tools with freshness and provenance
• Audit and Observability: keep a record of what was decided, why, by which system, and with what outcome

Enterprises will not be able to govern personalization by manually inspecting every generated message. They will need evidence trails: which signal was used, which policy was applied, which model or rule contributed to the decision, which content source was used, and what happened next.

Absence of Context makes demos deceiving

The control layer depends on shared context. This is where many AI personalization demos look better than real implementations.

In practice, shared context has several parts.

The semantic layer defines what customer actions, segments, metrics, products, offers, and content types actually mean.

The state layer captures what is true right now: profile, journey position, recent behavior, eligibility, inventory, service status, and channel availability.

The policy layer defines which treatments are allowed: consent, caps, suppression rules, legal constraints, brand rules, and risk thresholds.

The governance layer defines ownership: who maintains the definitions, who approves changes, how often rules get refreshed, and how exceptions are handled.

In the absence of shared context, AI tools can confidently optimize yet still make poor decisions. They may use stale data, apply inconsistent definitions, ignore a suppression rule, or select a locally attractive offer that conflicts with a broader customer treatment plan.

This is also where content plays an important role. A context layer cannot rely only on customer data and prompt text. If AI is going to generate, adapt, or select content dynamically, it needs a governed content context: approved claims, reusable modules, offer variants, rights, disclosures, brand rules, content lineage, and freshness.

That is where the content warehouse enters the story. I will take that up in the second article. The point for now is simpler: AI personalization cannot run on prompts, stale copy, and channel-specific content fragments alone. Now let’s return to the risks I previewed above. If you undertake a channel-by-channel, platform-embedded personalization strategy using the vendor’s AI tooling, you run the risk of having to build out all these services separately within each platform. We already see many vendors encouraging customers to do that, in the interest of improving results, yes, but at enormous cost and the unwieldiness of replication across channels. Better to centralize your control plane and other shared services.

This, in turn, poses new questions and requirements for your MarTech vendors.

Better questions for vendors

The question “Does this tool do personalization?” is becoming less useful. Too many tools can answer yes.

Better questions include:

• Does it personalize content adaptation, treatment decisions, or both?
• Is the optimization local to a single channel, or does it account for the enterprise context? Crucially, how can it ingest that context from centralized control panels?
• Which identity does it use, and how does it reconcile anonymous, authenticated, household, account, and buying-group identities?
• Where do policy and eligibility rules have to reside? How does it tap these remotely?
• What happens when several tools personalize at the same time?
• Can the system produce an evidence trail for decisions and generated content, and then share it with a central log?
• What degrades when data is stale, missing, or contradictory?
• Which content source fed the generated response, and how was that content governed?

Vendors must answer those questions clearly so you know that the demo isn’t ahead of what the architecture can support.

AI can make personalization more adaptive in the right places. It can also create a new generation of AI-enabled silos. The hard part is deciding where treatment logic should live, who governs it, and how decisions get reconciled across channels before “omnichannel” slips back into disconnected local optimization.

At RSG, we have been having many advisory conversations with our enterprise clients about AI’s impact on Personalization, the importance of the Context Layer, the Content Warehouse, and related topics. Feel free to reach out if you’d like to discuss your situation.

This is the first article in a two-part series on AI and the future of personalization. The next article will look at the content side of that architecture and why the context layer will need a content warehouse.