Weekly MarTech Signals That Matter to Me: Part 4, Week 21
🇮🇹 Leggi in italiano

Your CEP Is Quietly Becoming an Operational Control Layer

There is a version of the weekly MarTech scan that covers AI content generators and new dashboard widgets. This is not that version. This one is about the infrastructure that will determine whether your CEP actually scales.

The AJO May 2026 release dropped this week, and it is one of the most architecturally significant releases in the first half of 2026. Not because of any single feature, but because of what the combination of features reveals about what Adobe thinks a customer engagement platform needs to become. The pattern is consistent with signals from Bloomreach and Klaviyo this week, and worth taking seriously.



When features stop being features

Look at what the May release notes delivered or announced for this month.

None of these are marketing features. You cannot use any of them to send a better email. What they are is operational infrastructure: the tooling required to manage a large journey estate without it becoming unmanageable. Any team running 50 or more active journeys in AJO knows exactly why each of these matters. Journey Fragments mean you write the eligibility check once and reuse it everywhere instead of copying the same three-node sequence across twenty journeys and debugging them independently when requirements change. Automatic journey completion means the journey inventory actually reflects what is running, which matters when you are governing consent compliance, performance reporting, or simply trying to understand what is live. The Limited Availability status of Journey Fragments is worth tracking: teams that need this now should engage their Adobe account team rather than wait for GA.

The implicit argument in this release is that the CEP has crossed a complexity threshold. At scale, managing journeys requires the same discipline as managing code: modularity, reusability, version control, governance gates. Adobe is building those primitives into the platform, in other words, turning a CEP into a programme management system for campaigns.


AJO May 2026: five operational infrastructure features and what each one enables




RCS becomes first-class infrastructure

The other headline in the AJO May release is the consolidation of SMS, MMS, and RCS under a single Mobile Message action, with native RCS authoring (carousels, suggested actions, rich media) built directly into Journey Optimizer.

I want to be precise about why this matters, because the marketing press will cover it as “AJO adds RCS support” and that framing misses what is actually changing.

The channel fragmentation problem in mobile messaging has not been that platforms lack RCS connectivity. Many enterprise messaging stacks have already found ways to route RCS through partners or channel integrations. The issue was rarely pure reachability. The issue was operational fragmentation. The problem has been that RCS required a separate authoring interface, separate template management, separate suppression logic, and a separate data stream, all of which had to be stitched together with the SMS infrastructure that was already there. The result was operational overhead that made RCS an expensive exception rather than a default channel. Teams added RCS to specific premium use cases and continued routing everything else through SMS because the cross-channel management complexity was not worth it for the marginal uplift.

What AJO has shipped is not RCS connectivity. It is RCS integration into the existing channel governance model: one configuration surface, one suppression list, one frequency cap, one reporting view. The channel complexity disappears because the operational model becomes uniform. For brands that have been running a hybrid SMS/RCS strategy with separate management overhead, this changes the cost basis of maintaining RCS as a default rather than an exception.

Before, RCS lived in a parallel stack: separate tools, separate rules, separate reporting. After this release, SMS, MMS, and RCS share one operational surface: configuration, suppression, frequency, reporting.

This matters most for brands already running hybrid SMS/RCS programs at scale; for everyone else, it quietly lowers the future cost of turning RCS on by default.




Bloomreach closes the governance gap

Bloomreach shipped two releases this week: 1.308, rolling out from May 4, with an updated link shortener pattern for SMS/MMS and Performance Dashboard improvements, and 1.309, rolling out from May 18, with the approval workflow for scenarios.

The approval workflow will not appear in marketing headlines. It is not photogenic. But I have seen it cited as a blocker in multiple Bloomreach enterprise evaluations over the past two years. The scenario is always the same: a brand in financial services or insurance, or a retailer with a large agency team making automation changes, needs a structured review process before a journey goes live. Without it, the change control governance that the business requires has to be built outside the platform: manual sign-off processes, spreadsheet tracking, documentation workarounds. None of that is reliable at scale.

1.309 adds the review step natively. The gating mechanism exists in the platform. For the procurement decisions where this was a blocker, it stops being a blocker.

The Performance Dashboard update in 1.308 addresses a different kind of operational friction: not setup, but monitoring usability. Faster reloads, short-term caching and fewer request-limit interruptions may sound minor, but they matter when campaign teams are actively watching performance during launches or high-volume periods.

Together, 1.308 and 1.309 represent Bloomreach systematically closing the operational maturity gaps that have historically separated it from first-tier consideration in enterprise accounts with governance requirements. My read is that these are not isolated improvements. They look like enterprise prospect feedback being converted into roadmap commitments.




Composability as a design philosophy

There is something worth stepping back to observe across the AJO release in total. Chained orchestrated campaigns. Journey Fragments. Loop-based personalisation for relational data: a new block that iterates over orders, accounts, or bookings and renders one content block per record in a single email (announced for June 1). AEM Content Fragments in Decisioning. File-based targeting for orchestrated campaigns (announced for June 1). And over in AEP, chained activation in Audience Composition, shipping in the same release cycle.

This is a coherent design philosophy, not a feature list. Adobe is building composability into the entire execution layer: build once, reuse across journeys, across campaigns, across channels, across offer logic. Journey Fragments are to journey design what code modules are to software engineering. Chained campaigns decompose complex orchestration into reusable flows. Loop-based personalisation renders relational data without requiring separate template variants. AEM Content Fragments in Decisioning allow the same piece of content to serve both campaign authoring and offer selection without duplication.

The prerequisite, and this is important for anyone planning AEP/AJO implementations, is a content architecture and data model disciplined enough to take advantage of composability. Concretely, that means a coherent AEM taxonomy, content fragments that map to business concepts rather than campaigns, and relational schemas for orders, accounts, or bookings that stay consistent across markets. A brand with inconsistent asset taxonomy, unstructured content fragments, and ad hoc relational models will not benefit from these capabilities until those foundations are in place.

The platform is ahead of where most implementations are, that gap is the delivery risk that belongs in every scoping conversation. That is the planning conversation to be having with clients right now.


AJO composability: Journey Fragments — build once, reuse across the estate




Klaviyo’s AWS Marketplace signal

Klaviyo launched on AWS Marketplace on May 19. Enterprise brands can now use AWS EDP committed spend to procure Klaviyo, simplifying contracts and accelerating vendor procurement through existing cloud spend frameworks.

This is not a product feature. But the category signal is worth noting.

AWS Marketplace is where enterprise technology procurement goes. The brands that evaluate Klaviyo via AWS Marketplace are a different buyer profile from the mid-market and SME brands where Klaviyo built its installed base. They have longer sales cycles, more complex procurement governance, and existing relationships with AWS account teams who can co-sell. They are also the brands that are running the same CEP evaluations where Braze, Bloomreach, Insider, and occasionally AJO are on the shortlist.

What changes with the AWS listing is not what Klaviyo can do: it is how enterprise procurement teams can buy it. That is the same motion Braze and Bloomreach are already operating in. It removes one structural procurement objection that could previously make Klaviyo harder to evaluate in enterprise buying motions.

Just as Adobe and Bloomreach are building operational infrastructure into the product, Klaviyo is building procurement infrastructure around it. All three signals point to CEPs maturing into systems that fit enterprise programme management, not just campaign execution.

Klaviyo’s Spring 2026 product depth positions it for those evaluations on product terms: Customer Agent across email, WhatsApp, and live chat; RCS GA; Composer AI campaign generation; multi-email profile; per-individual send time optimisation. The AWS Marketplace listing is the GTM infrastructure to match. Watch for the enterprise packaging and contract tier announcements that will follow.




What this means for practitioners

If you are running a CEP selection or re-evaluation in 2026, the evaluation criteria need to include operational infrastructure, not just channel capability.

The question “does the platform support RCS?” is less interesting than “what does the operational model for managing RCS alongside SMS look like, and who owns the governance overhead?” The question “does the platform have AI personalisation?” is less interesting than “what is the data architecture required for the AI to work at the resolution I need, and do I have it?”

In practical terms, the next CEP evaluation should include questions like these:

Adobe’s May release is notable not because it added features, but because it added infrastructure. The CEP is not becoming a project management tool. But it is becoming the operational control layer for customer engagement programmes at scale. The platforms making that transition well are the ones building governance primitives, reusability patterns, and operational controls alongside the headline AI capabilities.




Sources

Adobe Journey Optimizer



Adobe Experience Platform



Bloomreach Engagement



Klaviyo




The digest behind each weekly article is produced through a structured AI-assisted scan of official release notes and product update sources. I review the output, verify the relevant signals and write the architectural interpretation.

This article draws from the Martech Weekly Digest scans run on May 21, 2026, covering release notes and product updates across 11 CEP platforms and 10 vendors.

If you find errors or gaps in coverage, I want to know. The process improves when the output is challenged.