The Week Every New Surface Arrived With Its Constraint Attached
There is a move I have now watched three times in this industry, and it took a loyalty release to make me see it clearly. Each time it looks like a vendor entering a new category, and each time what is actually happening is narrower and more interesting. The vendor leaves the system of record exactly where it is, and takes the judgement that sits on top of it.
The customer data platform did it first, when it stopped being a place data went and became the place activation was decided. The engagement platform did it next, when decisioning moved out of the campaign tool and into the journey. This week Adobe did it to loyalty. Journey Optimizer shipped Loyalty Challenges, and the most revealing sentence in the announcement is about what the product declines to do: it does not replace the systems that already manage points, tiers and rewards. It connects to them, through reward fulfilment APIs and event definitions, and takes everything above that line.
TL;DR
- Adobe took the motivation layer of loyalty and left the points ledger exactly where it was. Loyalty Challenges connects to the systems that already manage points, tiers and rewards through reward fulfilment APIs rather than replacing them, which is the right architectural call and which also creates a reconciliation junction that neither vendor owns.
- Braze and Showpad shipped remote MCP servers five days apart, and neither led with reach. Braze led with the statement that no user-profile PII is exposed, Showpad with the claim that everything runs under the governance rules already protecting the platform. When vendors stop selling distribution and start selling the boundary, the protocol has moved into its second phase.
- The wider the write scope, the louder the constraint. 6sense is explicitly read-only and barely mentions its boundaries, while Optimove, whose MCP can generate and deploy a live playable game and hand back a working URL, ships a one-day default session and a plain sentence about identity never being exposed.
- Two different things are now both called an agent, and they are governed in different consoles. MCP is about reach, which systems an external agent can call and under what scope. Adobe’s Coworker skills are about depth, what a first-party agent can do inside one vendor’s stack. Most organisations will end up running both, on different review cycles, with no obvious owner when one of them does something unexpected.
What Adobe actually took, and what it left
Loyalty Challenges turns loyalty into gamified experiences that motivate specific behaviours. Marketers build challenges in three shapes. Standard challenges ask for any number of tasks in any order. Streak challenges ask for the same task repeated consecutively, and Adobe’s own example is buying coffee seven days running to earn a free drink. Sequential challenges ask for tasks in a defined order, which is really onboarding wearing a different hat. There is a fourth type in restricted availability where the whole task-and-reward framework is assembled from your own loyalty data.
Administrators wire this up through a new Loyalty configurations menu that connects reward fulfilment APIs, event definitions, product inventory, exclusions and identity settings. The capability requires a separate Journey Optimizer Loyalty licence and the documentation is badged private beta, so this is not something most teams will touch this quarter.
Two details in the release are worth more attention than the challenge types. The first is that Journey Optimizer generates the journeys that orchestrate each challenge in the background. You author a challenge and the orchestration is derived from it rather than built by hand. The second is that the module introduces what Adobe calls Coworker skills, covering challenge creation, setting properties, managing audiences and reviewing participation insights.
Hold on to that word. It reappears somewhere important.
The reconciliation nobody owns
If the challenge logic lives in Journey Optimizer and the points balance lives in your loyalty platform, then somewhere between them there is a customer who completed a streak according to one system and did not receive a reward according to the other.
This is not a hypothetical failure mode, it is the normal condition of any two systems that share a workflow and not a database. The reward fulfilment API is the junction, and junctions are where the operating model has to be explicit and almost never is. When that ticket arrives, the loyalty vendor will correctly observe that it fulfilled every request it received, and the engagement vendor will correctly observe that it sent every request it generated, and the customer will still be short a free coffee.
I do not think this is a reason to avoid the product. Splitting the ledger from the orchestration is the right architectural call, and the alternative, where the CEP tries to own points and tiers too, would be much worse. But it does mean the interesting question in an evaluation is not what the challenge builder can express. It is what happens when the two sides disagree, who notices, and how quickly.
The auto-generated journeys deserve the same scrutiny for a related reason. Deriving orchestration from a challenge definition is a genuine productivity gain, and it is also a journey that nobody read before it went live. When something behaves strangely in six months, somebody will have to open a flow they did not design and reason about logic they never chose. That is a familiar cost, and it is worth pricing in rather than discovering.
The best example of the week came from Bloomreach
If you want a single, unglamorous illustration of a capability shipping with its guardrail already attached, it is in the Bloomreach 1.314 release notes.
The Loomi marketing agent can now put discount codes into the campaigns it builds, drawing unique per-customer codes from an existing voucher pool and saving each customer’s code so follow-up emails reuse the same one. Useful, and slightly alarming if you think about it for a second, because a generative agent handling discount codes is a generative agent one hallucination away from honouring a code that never existed.
Bloomreach’s answer is a single line in the documentation: the agent only uses voucher pools and attributes that already exist in the project, and if nothing is configured it tells you instead of inventing a code.
That is the whole thing. Not a policy document, not a governance framework. A constraint on what the agent is permitted to make up, stated in the release note next to the feature.
The same release lets Loomi build SMS and combined email-and-SMS campaigns from a plain-language brief, and applies the same instinct: SMS is only offered where SMS is actually configured, and the agent follows project-wide settings including silent hours and frequency caps. The agent inherits the platform’s rules rather than operating alongside them.
I have been asking for two years what it looks like when a vendor takes agent governance seriously at the feature level rather than the slide level. It looks like this, and it is boring, which is the point.
Meanwhile, the protocol grew a control plane
The other half of this week ran on a completely different track and arrived at a similar place.
Two vendors shipped remote-hosted MCP servers within five days of each other. Braze published one in early access: a single endpoint URL, separate US and EU endpoints, OAuth sign-in including SSO, read access across campaign, Canvas and segment analytics, custom attributes, events and catalogs, and write access to email templates, Content Blocks and media library assets. Showpad shipped one positioned as making its content available to any AI a team uses, whether that is Microsoft Copilot, Agentforce, Glean or something built in-house.
What is notable is not that they shipped. It is what each chose to lead with. Braze’s announcement states that no user-profile PII is exposed. Showpad’s states that everything runs under the governance rules already protecting the platform. Neither led with reach. Both led with the boundary.
For several months the MCP story on this beat was distribution. Expose the intelligence, let any agent call it, stop writing a bespoke integration per tool. That story is finished, and the evidence is that vendors have stopped selling it. 6sense’s server is explicitly read-only, does not execute actions or modify data, requires each user to authorise individually, and includes a strikingly candid line: once data reaches the assistant, how it is handled and retained is determined by the assistant platform, not by 6sense. That is an honest description of where a vendor’s control actually stops.
The client side moved in the same direction in the same week. Anthropic added an administrator key that disables the persistent “Always allow” approvals for MCP tools while keeping session-scoped ones, which means an organisation can now require that permission be re-granted rather than accumulate silently. Microsoft put org-built agents behind an admin review before they become discoverable in its Agent Store.
Every integration layer walks this path. First the protocol proves the connection is possible. Then somebody asks who approved it, what it can write, and how long the permission lasts.
Somebody finally shipped a console for the agents
The week’s most quietly damning product launch is HubSpot’s, and it is damning because of the problem it admits exists.
HubSpot released Agent Hub and Agent Builder in public beta. Agent Builder is the expected half: a no-code canvas that assembles agents from natural language and the CRM context you already have. Agent Hub is the interesting half. It is a console that shows live status for every active agent, lets you activate dormant ones, and puts the builder and the marketplace in one place.
Read that again. The selling point is knowing which of your agents are currently running.
HubSpot’s own framing of the problem is a prospecting agent contacting a customer in the same week a service agent is working that account’s open complaint, with neither aware of the other. That is not a hypothetical from a product manager’s imagination. That is a support escalation somebody has already had.
Put it next to the rest of the week and a sequence appears. Anthropic shipped a key controlling how long an agent’s tool permission survives. Microsoft shipped a review gate before an agent becomes discoverable to colleagues. HubSpot shipped a screen listing which agents exist and whether they are on. Workato, a vendor most marketers have never heard of, is now selling an Enterprise MCP Registry alongside an MCP Gateway and an MCP Proxy as a governance product in its own right.
Three of those four are answers to the same question, and it is not “what can agents do.” It is “what do we currently have running, and who turned it on.”
Organisations deployed agents the way they deployed SaaS in 2015: departmentally, enthusiastically, and without a register. The bill for that is arriving as a product category.
How far does write access go? Ask Optimove
Everyone shipping an MCP server this week drew a line somewhere, and putting the four side by side gives you the actual spectrum rather than the marketing version.
6sense sits at one end: explicitly read-only, does not execute actions or modify data, and each user must authorise individually. Showpad serves content out to whatever agent a team already uses. Braze allows writes, but scoped to content objects, templates, Content Blocks, media assets, and states that no user-profile PII is exposed.
Optimove went furthest by some distance. Its MCP can now explore a segment conversationally, asking for average deposit amount or the age breakdown of a Target Group and getting an answer without a report or an export. And through two actions named create_mini_game and save_mini_game, you can describe a game in a sentence, have the AI generate and deploy it, and get back a live playable URL.
That is an agent producing a customer-facing asset and putting it live. Not a draft. Not a template in an inventory awaiting approval. A working URL.
Notice what travels with it. The default MCP session lasts one day, with longer sessions granted per tenant on request rather than by default. And Optimove states directly that customer identity is never exposed, only behavioural data.
There is a pattern in that pairing, and it holds across all four vendors: the wider the write scope, the louder the constraint. Read-only servers barely mention their boundaries. The one that deploys live assets ships a one-day session by default and a plain sentence about PII.
That is roughly the right instinct, and it is also the thing to check rather than assume. A one-day session is a meaningful control. “Identity is never exposed” is a claim about a data path, and claims about data paths are worth testing against your own schema before you decide they are true for your tenant.
Two different things are both called an agent
Now back to that word. Adobe’s Experience Platform release, which landed the same week, includes a Sandbox Tooling agentic skill delivered in something called CX Coworker. Journey Optimizer Loyalty introduces Coworker skills. The same name, two products, a few days apart. Adobe has named its agent layer in public and is extending it across the stack.
The Sandbox Tooling skill is the more instructive of the two, because of how it behaves. It discovers objects in a source sandbox, packages them with their dependencies, validates changes before import, migrates them and monitors progress. And it surfaces execution plans and dependency analysis so the work can be reviewed before it runs. That is a plan-then-approve pattern applied to exactly the kind of operation where an agent acting directly would be alarming and an agent proposing a reviewable plan is genuinely useful.
Put the two threads side by side and a distinction emerges that I think is going to matter for the next few years of stack design. MCP is about reach: which systems an external agent can call, and under what scope. Coworker, or whatever each vendor ends up calling its equivalent, is about depth: what a first-party agent can do inside one vendor’s stack, where the permission model and the dependency graph are already understood.
These are not competing. Adobe is building the second while participating in the first through its own MCP server. Most organisations will end up with both. The problem is that they are governed in different consoles, by different teams, on different review cycles, and when an agent does something unexpected the question of which layer was supposed to stop it does not have an obvious owner.
The CDP started recording the conversation with the model
One more item, which I nearly missed entirely and which may end up being the most consequential thing in this week’s notes.
Tealium added an Anthropic data source. The description is a single sentence: use it with the Tealium Anthropic connector to send prompts and AI model responses through Tealium. There is an OpenAI Measurement Pixel and an OpenAI Events connector alongside it.
Read that as an architecture decision rather than a connector announcement. The customer data platform, whose job has always been to collect the events that constitute a customer relationship, has started collecting what the customer said to the model and what the model said back.
Every argument we have had about customer data for fifteen years is about to be re-run on this material, and the material is worse. Page views are structured and boring. Prompts are unstructured, unpredictable, and frequently contain things the customer would never have typed into a form: health details, financial circumstances, the actual reason they are shopping. If that flows into the profile store, it flows into segmentation, and from segmentation into activation, and from activation into an ad platform.
I am not saying do not do this. The signal in a genuine expression of intent is enormous, and pretending the interaction did not happen is not governance either. But if you are wiring model conversations into the CDP, the schema design and the retention policy are not paperwork to be done afterwards. They are the decision.
The quiet items that will actually cost you time
Three things this week will affect more people than the loyalty module, and none of them will make a slide.
Adobe changed how Experience Platform consolidates profile attributes, moving the work from read time to write time. Exports complete significantly faster and downstream activation becomes available sooner, which is the headline. The part that matters operationally is the other half: ingestion of profile attributes may now take slightly longer. Adobe’s own guidance is to review the timing buffer between scheduled ingestion and segmentation jobs and to consider moving activation schedules earlier. If you run those windows tightly, this is a change to test rather than to read about.
Separately, and quietly, Adobe fixed a bug where datasets created through the Customer Journey Analytics audience publishing flow were not flagged as system-generated and could inflate pseudonymous profile counts in Real-Time CDP. If your profile counts move this month without an obvious cause, that is likely why.
And tomorrow, 31 July, Marketo Engage ends support for its SOAP API, and REST Merge Leads calls carrying more than 25 IDs start returning an error and being skipped. A correction to my own record while I am here: last week I described this as a triple deadline including the access_token parameter deprecation. That one is 31 August, not 31 July, and the merge limit returns 1080 rather than the 1003 I quoted, which belongs to a separate static-list rule landing 30 September. I would rather correct that publicly than have somebody schedule a migration around my mistake.
There is a lesson in the ordering. This was a week of loyalty gamification, propensity-based channel selection and remote MCP servers, and the thing most likely to break something in production tomorrow morning is a SOAP endpoint switching off on a schedule published in June, in a table nobody scrolls to.
And while we were all looking at the products
Two things happened in the same seven days that will shape more roadmaps than anything above, and I nearly filed this piece without either.
The EU AI Omnibus entered into force on 27 July, extending implementation timelines, simplifying compliance for smaller businesses and expanding access to regulatory testing programmes, while leaving the AI Act’s safety framework intact. If you have been building an AI compliance plan against the original dates, they moved.
And on 28 July New York finalised rules requiring platforms to give under-18s chronological feeds instead of behaviour-driven recommendations, and to stop sending them overnight push notifications, from 25 January. Fines run to $5,000 per violation, and platforms will need to estimate or verify user ages.
Read that second one as a martech practitioner rather than a policy watcher. Overnight push suppression by age. Age estimation or verification as a precondition for personalisation. A jurisdiction-specific rule about what ranking logic is permitted for which users. Every one of those is a change to a system somebody in this industry owns, and none of them is a feature request that will come through a vendor release note.
The pattern worth naming
I have spent two years on this beat watching capability arrive ahead of control. Platforms shipped the thing and then, eventually, shipped the guardrail, usually after somebody’s incident.
This week did not look like that. Loyalty Challenges arrived reusing the existing Journey Optimizer and Experience Platform permission sets rather than inventing a parallel one. The MCP servers arrived with their boundaries stated as the headline. The Sandbox Tooling agent arrived with a review step built into the workflow rather than bolted on. Adobe shipped firewall allowlisting for landing pages and a new permission specifically motivated by hiding personally identifiable information in campaign previews, in the same release as the new toys.
That is a healthier pattern than what came before, and it deserves to be named as such rather than treated as the baseline. It is also incomplete, because a boundary stated in a release note is a claim, not a control. The work of checking whether the boundary holds, and of reconciling the three or four permission models you now operate, still belongs to whoever owns the architecture.
Every new surface this week arrived with its constraint attached. That is progress. Verifying the constraint is still your job.
Sources
Adobe Journey Optimizer Loyalty Challenges
Adobe Journey Optimizer July ‘26 release
Adobe Experience Platform July ‘26 release
Adobe Journey Optimizer B2B 2026.6
Adobe Marketo Engage deadlines
Braze remote MCP server
Showpad Summer ‘26
6sense MCP scope
Optimove July 2026 release
Bloomreach 1.314
HubSpot Agent Hub and Agent Builder
Klaviyo Composer
Iterable release notes
Tealium release feed
MoEngage June 2026 release
Regulatory and industry items (EU AI Omnibus, New York minors’ feed rules, Clarify/Seam AI, RocketReach MCP, Workato Enterprise MCP Registry)
Weekly roundup
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 July 30, 2026, covering release notes and product updates across several CEP platforms and vendors.
If you find errors or gaps in coverage, I want to know. The process improves when the output is challenged.
