Questo articolo è una traduzione assistita dall’AI dell’originale in inglese, revisionata dall’autore.
La settimana in cui ogni nuova capacità è arrivata con i propri limiti già dichiarati
C’è una dinamica che ho ormai visto ripetersi tre volte in questo settore, ma è stato necessario un rilascio dedicato alla loyalty perché riuscissi a riconoscerla con chiarezza.
Ogni volta sembra che un vendor stia entrando in una nuova categoria. In realtà sta facendo qualcosa di più circoscritto e, dal punto di vista architetturale, più interessante: lascia il system of record dove si trova e porta nella propria piattaforma la logica decisionale che utilizza quei dati.
La customer data platform lo ha fatto per prima, quando ha smesso di essere soltanto il luogo in cui confluivano i dati ed è diventata il luogo in cui si decideva come attivarli. Lo ha fatto poi la piattaforma di engagement, quando il decisioning ha iniziato a spostarsi dagli strumenti di campaign management ai journey.
Questa settimana Adobe ha applicato lo stesso principio alla loyalty.
Journey Optimizer ha introdotto Loyalty Challenges, ma la frase più significativa dell’annuncio riguarda ciò che il prodotto non vuole diventare. Non sostituisce i sistemi che già gestiscono punti, livelli e premi. Si collega a essi tramite API di erogazione delle ricompense e definizioni degli eventi, prendendo in carico tutto ciò che sta sopra il registro contabile della loyalty: le challenge, i comportamenti da incentivare, l’orchestrazione e la comunicazione con il cliente.
TL;DR
-
Adobe ha portato nel CEP la logica di ingaggio della loyalty, lasciando ai sistemi esistenti la gestione di punti, livelli e premi. Loyalty Challenges si collega tramite API alle piattaforme che già amministrano saldi, tier e ricompense, invece di provare a sostituirle. È la scelta architetturale corretta, ma crea anche un punto di raccordo nel quale le anomalie devono essere riconciliate e del quale nessuno dei due vendor è realmente proprietario.
-
Braze e Showpad hanno rilasciato server MCP remoti a cinque giorni di distanza, e nessuno dei due ha messo al centro la portata dell’integrazione. Braze ha sottolineato che non vengono esposti dati personali contenuti nei profili utente. Showpad ha insistito sul fatto che ogni operazione continua a rispettare le regole di governance già applicate dalla piattaforma. Quando i vendor smettono di raccontare fin dove può arrivare il protocollo e iniziano a spiegare dove si ferma, significa che MCP è entrato nella sua seconda fase.
-
Più un agente può intervenire sui sistemi, più espliciti devono diventare i limiti entro cui può farlo. Il server di 6sense è esclusivamente read-only e dedica relativamente poco spazio ai propri confini. Optimove, il cui MCP può generare e pubblicare un gioco destinato ai clienti restituendo un URL immediatamente utilizzabile, imposta invece sessioni della durata predefinita di un giorno e dichiara esplicitamente che l’identità del cliente non viene mai esposta.
-
Oggi chiamiamo “agenti” due cose diverse, governate attraverso console differenti. MCP riguarda l’estensione: quali sistemi può utilizzare un agente esterno e con quali autorizzazioni. Le Coworker skills di Adobe riguardano la profondità operativa: ciò che un agente first-party può fare all’interno dello stack di un singolo vendor. La maggior parte delle organizzazioni finirà per utilizzare entrambi i modelli, sottoponendoli però a cicli di controllo diversi e senza un responsabile evidente quando qualcosa non funzionerà come previsto.
Cosa ha preso davvero Adobe e cosa ha lasciato dov’era
Loyalty Challenges trasforma i programmi di loyalty in esperienze gamificate progettate per incoraggiare comportamenti specifici.
I marketer possono costruire tre tipi principali di challenge. Le challenge Standard richiedono di completare un certo numero di attività, senza imporre un ordine preciso. Le challenge Streak richiedono di ripetere consecutivamente la stessa azione. L’esempio proposto da Adobe è l’acquisto di un caffè per sette giorni di seguito in cambio di una bevanda gratuita. Le challenge Sequential richiedono invece di completare una serie di attività in un ordine definito, che in molti casi equivale a un percorso di onboarding presentato in una forma diversa.
Esiste inoltre un quarto modello, per ora disponibile soltanto in forma limitata, nel quale l’intera struttura di attività e ricompense viene costruita utilizzando i dati del programma di loyalty del cliente. La configurazione passa da un nuovo menu, Loyalty configurations, attraverso il quale gli amministratori collegano le API per l’erogazione delle ricompense, le definizioni degli eventi, l’inventario dei prodotti, le esclusioni e le impostazioni relative all’identità.
La funzionalità richiede una licenza separata per Journey Optimizer Loyalty e la documentazione è ancora contrassegnata come private beta. Non è quindi qualcosa che la maggior parte dei team potrà utilizzare nel corso di questo trimestre.
Due elementi del rilascio meritano più attenzione dei diversi tipi di challenge.
Il primo è che Journey Optimizer genera automaticamente, in background, i journey necessari a orchestrare ogni challenge. Il marketer definisce la challenge e la piattaforma ne ricava l’orchestrazione, invece di richiedere che il journey venga costruito manualmente.
Il secondo è l’introduzione di quelle che Adobe chiama Coworker skills, dedicate alla creazione delle challenge, alla configurazione delle proprietà, alla gestione delle audience e all’analisi della partecipazione.
Tenete a mente questa definizione. Tornerà più avanti in un punto importante.
Il problema di riconciliazione che nessuno possiede
Se la logica della challenge vive in Journey Optimizer e il saldo dei punti vive nella piattaforma di loyalty, prima o poi esisterà un cliente che, secondo un sistema, ha completato correttamente una streak e che, secondo l’altro, non ha ricevuto la ricompensa prevista.
Non è un’ipotesi remota. È la condizione normale di due sistemi che condividono un processo, ma non condividono lo stesso database.
L’API di erogazione delle ricompense è il punto di raccordo tra questi due mondi. Ed è proprio nei punti di raccordo che il modello operativo dovrebbe essere definito con la massima precisione, anche se quasi mai lo è. Quando arriverà una segnalazione, il vendor della piattaforma di loyalty potrà correttamente affermare di aver eseguito tutte le richieste che ha ricevuto. Il vendor della piattaforma di engagement potrà altrettanto correttamente affermare di aver inviato tutte le richieste generate dal journey. Il cliente, nel frattempo, continuerà a non aver ricevuto il proprio caffè gratuito.
Non considero questo un motivo per evitare il prodotto. Separare il registro contabile della loyalty dalla sua orchestrazione è la scelta architetturale corretta. L’alternativa, nella quale il CEP cerca di assumersi anche la gestione di saldi, tier e premi, sarebbe molto peggiore. Significa però che, durante una platform evaluation, la domanda interessante non è soltanto quali challenge sia possibile configurare.
La domanda è cosa succede quando i due sistemi non sono allineati, chi rileva l’anomalia e quanto tempo serve per risolverla ed anche i journey generati automaticamente richiedono attenzione, per una ragione simile.
Derivare l’orchestrazione dalla definizione della challenge rappresenta un reale miglioramento in termini di produttività. Allo stesso tempo, produce un journey che nessuno ha progettato direttamente e che, probabilmente, nessuno ha esaminato riga per riga prima della pubblicazione.
Quando qualcosa inizierà a comportarsi in modo anomalo tra sei mesi, qualcuno dovrà aprire un flusso che non ha costruito e interpretare una logica che non ha scelto. È un costo già noto in molti altri ambiti dell’automazione. Conviene includerlo fin dall’inizio nella valutazione, invece di scoprirlo in produzione.
Il miglior esempio della settimana è arrivato da Bloomreach
Per trovare un esempio semplice e poco spettacolare di una funzionalità rilasciata insieme al proprio guardrail basta leggere le note della versione 1.314 di Bloomreach.
L’agente di marketing Loomi può ora inserire codici sconto nelle campagne che genera. Utilizza codici univoci per ciascun cliente, prelevandoli da un voucher pool già esistente, e memorizza il codice assegnato in modo che le comunicazioni successive possano riutilizzare lo stesso valore.
È una funzionalità utile. Diventa anche leggermente preoccupante non appena ci si riflette per qualche secondo. Un agente generativo che gestisce codici sconto è infatti un agente generativo che, in assenza di controlli, potrebbe inventare un codice inesistente e comunicarlo a un cliente come se fosse valido.
La risposta di Bloomreach occupa una sola riga nella documentazione: l’agente può utilizzare esclusivamente voucher pool e attributi che esistono già all’interno del progetto. Se non trova una configurazione valida, lo segnala invece di generare un codice. È tutto, non un documento di policy, non un framework di governance, ma semplicemente un vincolo concreto su ciò che l’agente può o non può inventare, documentato accanto alla funzionalità.
La stessa release permette a Loomi di costruire campagne SMS e campagne combinate email e SMS partendo da un brief in linguaggio naturale. Anche in questo caso viene applicato lo stesso principio: il canale SMS viene proposto soltanto nei progetti in cui è realmente configurato, mentre l’agente eredita le impostazioni generali della piattaforma, comprese le silent hours e i frequency cap.
L’agente opera all’interno delle regole del sistema, non in parallelo a esse.
Da due anni mi domando come si presenti un vendor che prende sul serio la governance degli agenti al livello delle singole funzionalità, invece di limitarla alle slide di presentazione. Si presenta così.
Ed è noioso nel senso più positivo del termine, e questo è esattamente il punto.
Nel frattempo, attorno al protocollo è nato un livello di controllo
L’altra metà delle novità di questa settimana ha seguito un percorso completamente diverso, arrivando però a una conclusione molto simile.
Due vendor hanno rilasciato server MCP gestiti da remoto a cinque giorni di distanza. Braze ne ha pubblicato uno in early access. Offre un unico endpoint, con indirizzi separati per Stati Uniti ed Europa, autenticazione OAuth con supporto SSO, accesso in lettura alle analisi di campagne, Canvas e segmenti, oltre che ad attributi personalizzati, eventi e cataloghi. Consente inoltre operazioni di scrittura su template email, Content Block e asset della media library.
Showpad ha presentato il proprio server MCP come uno strumento per rendere contenuti e conoscenze disponibili a qualsiasi AI utilizzata dall’organizzazione, che si tratti di Microsoft Copilot, Salesforce Agentforce, Glean o di un agente sviluppato internamente.
L’aspetto interessante non è il fatto che abbiano rilasciato questi server, è ciò che hanno scelto di mettere in primo piano. Braze ha sottolineato che il server non espone informazioni personali presenti nei profili degli utenti. Showpad ha dichiarato che ogni operazione continua a rispettare le regole di governance che già proteggono la piattaforma. Nessuno dei due ha aperto l’annuncio parlando della portata dell’integrazione. Entrambi hanno aperto parlando dei suoi confini.
Per diversi mesi, la narrazione attorno a MCP è stata soprattutto una narrazione di distribuzione: esporre dati e funzionalità, permettere a qualsiasi agente di utilizzarli e smettere di costruire un’integrazione specifica per ogni singolo strumento. Quella fase è ormai conclusa, e la prova è che i vendor hanno smesso di venderla come elemento principale.
Il server MCP di 6sense è esplicitamente read-only. Non esegue azioni e non modifica i dati. Richiede inoltre che ogni utente autorizzi individualmente l’accesso. La documentazione contiene anche una frase particolarmente onesta: una volta che i dati raggiungono l’assistente, le modalità con cui vengono trattati e conservati dipendono dalla piattaforma dell’assistente, non più da 6sense ed è una descrizione trasparente del punto esatto in cui termina il controllo del vendor.
Nella stessa settimana si è mosso anche il lato client, Anthropic ha introdotto una configurazione amministrativa che permette di disabilitare le autorizzazioni persistenti “Always allow” per gli strumenti MCP, mantenendo però le autorizzazioni limitate alla singola sessione. In questo modo un’organizzazione può imporre che il permesso venga concesso nuovamente, anziché permettere che continui a rimanere valido senza ulteriori verifiche. Microsoft ha invece sottoposto gli agenti sviluppati internamente a una revisione amministrativa prima che possano diventare visibili e utilizzabili all’interno dell’Agent Store.
Ogni livello di integrazione attraversa la stessa evoluzione, prima si dimostra che il collegamento è possibile e poi qualcuno inizia a chiedere chi lo abbia autorizzato, quali operazioni possa eseguire e quanto a lungo rimanga valido il permesso.
Finalmente qualcuno ha creato una console per sapere quali agenti sono attivi
Il lancio di prodotto più silenziosamente rivelatore della settimana è quello di HubSpot, proprio per il problema che ammette di dover risolvere.
HubSpot ha rilasciato Agent Hub e Agent Builder in public beta.
Agent Builder è la parte più prevedibile: un ambiente no-code che permette di costruire agenti utilizzando il linguaggio naturale e il contesto già disponibile nel CRM.
Agent Hub è la parte più interessante. È una console che mostra lo stato in tempo reale di tutti gli agenti, permette di attivare quelli inattivi e riunisce nello stesso ambiente il builder e il marketplace.
Vale la pena soffermarsi su questo punto. Uno dei principali vantaggi dichiarati è poter sapere quali agenti siano attualmente in esecuzione. La stessa HubSpot descrive il problema con un esempio: un agente di prospecting contatta un cliente nella stessa settimana in cui un agente del customer service sta gestendo un reclamo aperto su quello stesso account, senza che nessuno dei due sappia cosa stia facendo l’altro.
Non sembra uno scenario ipotetico inventato da un product manager, sembra piuttosto un’escalation che qualcuno ha già dovuto gestire.
Affiancando questo lancio alle altre novità della settimana emerge una sequenza precisa.
Anthropic ha introdotto un controllo sulla durata delle autorizzazioni concesse agli strumenti.
Microsoft ha aggiunto una revisione prima che un agente diventi disponibile ai colleghi.
HubSpot ha creato una schermata che mostra quali agenti esistano e quali siano attivi.
Workato, un vendor che molti marketer probabilmente non conoscono, ha iniziato a vendere un Enterprise MCP Registry insieme a un MCP Gateway e a un MCP Proxy, trasformando la governance degli agenti in una categoria di prodotto a sé stante.
Tre di queste quattro soluzioni rispondono alla stessa domanda, non: “Che cosa possono fare gli agenti?” , ma: “Quali agenti abbiamo attualmente in esecuzione e chi li ha attivati?”.
Le organizzazioni hanno introdotto gli agenti nello stesso modo in cui hanno adottato il SaaS nel 2015: reparto per reparto, con entusiasmo e senza costruire un registro centralizzato.
Ora il conto di quella scelta sta arrivando sotto forma di una nuova categoria software.
Quanto può spingersi in scrittura un server MCP? Chiedetelo a Optimove
Ogni vendor che ha rilasciato un server MCP questa settimana ha tracciato un confine diverso, mettere le quattro soluzioni una accanto all’altra permette di vedere lo spettro reale delle possibilità, al di là della narrazione commerciale.
Braze consente operazioni di scrittura, ma le limita agli oggetti di contenuto: template email, Content Block e asset multimediali. Dichiara inoltre che non vengono esposti dati personali appartenenti ai profili utente.
Optimove si spinge molto più lontano.
Il suo server MCP permette di esplorare un segmento attraverso una conversazione. È possibile chiedere, per esempio, quale sia il deposito medio effettuato dagli utenti o quale sia la distribuzione per età di un determinato Target Group, ottenendo una risposta senza dover preparare un report o esportare i dati. Attraverso due azioni chiamate create_mini_game e save_mini_game, è inoltre possibile descrivere un gioco in una frase, lasciare che l’AI lo generi e lo pubblichi, e ricevere come risposta un URL già attivo e immediatamente utilizzabile.
Non una bozza, mon un template salvato in attesa di approvazione, ma un asset destinato ai clienti, generato e pubblicato dall’agente.
È importante osservare quali vincoli accompagnano questa capacità. La sessione MCP ha una durata predefinita di un giorno. Sessioni più lunghe possono essere concesse su richiesta per singolo tenant, ma non sono abilitate automaticamente. Optimove dichiara inoltre che l’identità dei clienti non viene mai esposta e che l’agente accede soltanto ai dati comportamentali. Esiste un pattern evidente in questa combinazione, e si ripete in tutti e quattro i vendor: più ampie sono le azioni che un agente può compiere, più espliciti diventano i limiti che lo accompagnano.
I server esclusivamente read-only dedicano poco spazio ai propri confini. Il server capace di pubblicare direttamente asset rivolti ai clienti imposta sessioni brevi e dichiara apertamente quali dati non possono essere esposti ed è, in linea generale, l’approccio corretto.
Rimane comunque qualcosa da verificare, non da accettare automaticamente. Una sessione di un giorno è un controllo concreto. L’affermazione secondo cui “l’identità non viene mai esposta” descrive invece un percorso dei dati. E qualsiasi affermazione relativa a un percorso dei dati dovrebbe essere verificata rispetto allo schema e alla configurazione del proprio tenant prima di essere considerata vera.
Stiamo chiamando “agenti” due cose profondamente diverse
Torniamo ora alla parola Coworker. Il rilascio di Adobe Experience Platform arrivato nella stessa settimana include una skill agentica per il Sandbox Tooling, distribuita all’interno di una soluzione chiamata CX Coworker e Journey Optimizer Loyalty introduce, a sua volta, le Coworker skills.
Stesso nome, due prodotti diversi, a pochi giorni di distanza, Adobe ha quindi iniziato a dare un’identità pubblica al proprio livello agentico e a estenderlo progressivamente attraverso lo stack.
La skill dedicata al Sandbox Tooling è particolarmente istruttiva per il modo in cui opera, individua gli oggetti presenti in una sandbox sorgente, li inserisce in un pacchetto insieme alle relative dipendenze, convalida le modifiche prima dell’importazione, esegue la migrazione e ne monitora lo stato. Mostra inoltre il piano di esecuzione e l’analisi delle dipendenze, permettendo agli utenti di revisionare il lavoro prima che venga effettivamente eseguito.
È un modello “prima pianifica, poi chiedi approvazione”, applicato esattamente al tipo di operazione per cui un agente completamente autonomo sarebbe preoccupante, mentre un agente capace di proporre un piano verificabile può essere realmente utile. Affiancando questa evoluzione a quella dei server MCP emerge una distinzione che, a mio avviso, diventerà importante nella progettazione degli stack dei prossimi anni.
MCP riguarda l’estensione: quali sistemi può utilizzare un agente esterno e con quale livello di autorizzazione.
Coworker, o qualunque nome gli altri vendor assegneranno alle proprie soluzioni equivalenti, riguarda invece la profondità operativa: ciò che un agente first-party può fare all’interno dello stack di un singolo vendor, dove il modello dei permessi e le dipendenze tra gli oggetti sono già conosciuti.
Non sono due modelli in competizione e Adobe sta costruendo il secondo e, allo stesso tempo, partecipa al primo attraverso il proprio server MCP.
La maggior parte delle organizzazioni finirà per adottarli entrambi, il problema è che verranno governati attraverso console diverse, da team diversi e con cicli di revisione differenti e quando un agente si comporterà in modo inatteso, non sarà affatto chiaro quale livello avrebbe dovuto impedirlo e chi ne fosse responsabile.
La CDP ha iniziato a registrare le conversazioni con i modelli
C’è un ultimo elemento che ho rischiato di non notare e che potrebbe rivelarsi la novità più importante contenuta nelle note di questa settimana, Tealium ha introdotto una nuova data source dedicata ad Anthropic.
La descrizione occupa una sola frase: utilizzatela insieme al connettore Anthropic di Tealium per inviare attraverso la piattaforma i prompt e le risposte generate dal modello e accanto a questa integrazione compaiono anche un OpenAI Measurement Pixel e un connettore OpenAI Events.
Non leggetela come il semplice annuncio di un nuovo connettore, ma leggetela come una decisione architetturale. La customer data platform, il cui compito è sempre stato raccogliere gli eventi che descrivono la relazione tra cliente e azienda, ha iniziato a raccogliere anche ciò che il cliente dice a un modello e ciò che il modello gli risponde. Tutte le discussioni che abbiamo affrontato negli ultimi quindici anni sui dati dei clienti stanno per ripetersi su questo nuovo materiale e questa volta il materiale è molto più complesso.
Le visualizzazioni di pagina sono strutturate e prevedibili. I prompt sono destrutturati, imprevedibili e possono contenere informazioni che un cliente non inserirebbe mai in un form tradizionale: dettagli sulla propria salute, difficoltà finanziarie, circostanze personali o la vera motivazione che lo ha portato a valutare un acquisto.
Se queste informazioni entrano nel profile store, possono entrare nella segmentazione e dalla segmentazione possono passare all’attivazione e dall’attivazione possono arrivare fino a una piattaforma pubblicitaria Non sto sostenendo che queste conversazioni non debbano essere raccolte in quanto il valore di un’espressione autentica dell’intenzione del cliente è enorme, e ignorare completamente l’interazione non rappresenta una forma di governance migliore, ma se le conversazioni con i modelli vengono collegate alla CDP, la progettazione dello schema e la policy di conservazione dei dati non possono essere considerate attività amministrative da svolgere successivamente.
Sono la decisione architetturale.
Le modifiche poco visibili che vi faranno perdere davvero tempo
Tre novità di questa settimana interesseranno probabilmente più persone del nuovo modulo di loyalty, anche se nessuna di esse finirà in una slide.
Adobe ha modificato il modo in cui Experience Platform consolida gli attributi dei profili, spostando parte del lavoro dal momento della lettura al momento della scrittura. Il vantaggio dichiarato è che le esportazioni vengono completate molto più rapidamente e che i dati possono diventare disponibili prima per le attivazioni downstream. Dal punto di vista operativo, però, conta anche l’altra metà della modifica: l’ingestion degli attributi dei profili potrebbe richiedere leggermente più tempo. La stessa Adobe consiglia di verificare il margine temporale esistente tra le ingestion pianificate e i job di segmentazione, valutando anche la possibilità di anticipare le pianificazioni delle attivazioni. Se le vostre finestre operative sono configurate con margini molto stretti, è una modifica da testare, non soltanto da leggere nelle release note.
Separatamente, e con pochissimo risalto, Adobe ha corretto un bug relativo ai dataset creati attraverso il processo di pubblicazione delle audience di Customer Journey Analytics. Questi dataset non venivano correttamente identificati come generati dal sistema e potevano quindi aumentare artificialmente il numero dei profili pseudonimi conteggiati in Real-Time CDP. Se il numero dei profili cambia questo mese senza una causa immediatamente evidente, questa potrebbe essere la spiegazione.
Domani, 31 luglio, Marketo Engage terminerà inoltre il supporto per la propria API SOAP e nella stessa data, le chiamate REST Merge Leads contenenti più di 25 ID inizieranno a restituire un errore e verranno ignorate.
Questa è stata una settimana di loyalty gamificata, selezione dei canali basata sulla propensione e server MCP remoti.
Eppure, la modifica con maggiori probabilità di rompere qualcosa in produzione domani mattina è la disattivazione di un endpoint SOAP, annunciata a giugno all’interno di una tabella che quasi nessuno avrà letto fino in fondo.
E mentre tutti guardavamo i prodotti
Nello stesso arco di sette giorni sono accadute due cose che influenzeranno più roadmap di quasi tutte le funzionalità citate finora, e ho rischiato di pubblicare questo articolo senza includerle.
L’EU AI Omnibus è entrato in vigore il 27 luglio, estendendo alcune tempistiche di implementazione, semplificando gli obblighi per le imprese di dimensioni minori e ampliando l’accesso ai programmi di sperimentazione regolamentare, senza modificare l’impianto generale di sicurezza dell’AI Act, serie avete costruito un piano di compliance basandovi sulle date originarie, quelle date sono cambiate.
Il 28 luglio, lo Stato di New York ha inoltre finalizzato nuove regole che, a partire dal 25 gennaio, imporranno alle piattaforme di mostrare agli utenti con meno di 18 anni feed cronologici anziché raccomandazioni determinate dal comportamento e di interrompere l’invio di notifiche push durante le ore notturne.
Le sanzioni possono raggiungere i 5.000 dollari per singola violazione e le piattaforme dovranno introdurre meccanismi per stimare o verificare l’età degli utenti, provate a leggere questa seconda novità dal punto di vista di chi progetta e gestisce piattaforme MarTech, non soltanto da quello di chi segue l’evoluzione normativa.
Soppressione delle notifiche push notturne in base all’età. Stima o verifica dell’età come prerequisito per la personalizzazione. Regole specifiche per giurisdizione che stabiliscono quale logica di ranking possa essere utilizzata per determinate categorie di utenti.
Ognuno di questi requisiti implica una modifica a un sistema gestito da qualcuno nel nostro settore e nessuno di essi arriverà sotto forma di una feature request pubblicata nelle release note di un vendor.
Il pattern che merita di essere riconosciuto
Negli ultimi due anni ho osservato più volte le funzionalità arrivare prima dei controlli, le piattaforme rilasciavano nuove capacità e soltanto in seguito, spesso dopo un incidente, introducevano i guardrail necessari a governarle.
Questa settimana il pattern è stato diverso. Loyalty Challenges è arrivato riutilizzando i permission set già esistenti in Journey Optimizer ed Experience Platform, invece di creare un modello autorizzativo parallelo, i server MCP sono arrivati dichiarando fin dall’inizio i propri confini.
La skill di Sandbox Tooling è stata progettata con un passaggio di revisione incorporato nel workflow, invece di aggiungerlo in un secondo momento. Nello stesso rilascio delle nuove funzionalità, Adobe ha inoltre introdotto l’allowlisting tramite firewall per le landing page e una nuova autorizzazione specifica per impedire che informazioni personali identificabili vengano mostrate nelle anteprime delle campagne.
È un pattern più sano rispetto a quello che abbiamo visto in passato e merita di essere riconosciuto, invece di essere trattato come qualcosa di scontato anche se rimane comunque un pattern incompleto.
Un limite dichiarato in una release note è un’affermazione, non ancora un controllo verificato, il lavoro necessario per accertarsi che quel limite funzioni davvero e per riconciliare i tre o quattro modelli di autorizzazione che un’organizzazione finirà per gestire continua a spettare a chi possiede l’architettura.
Questa settimana ogni nuova capacità è arrivata con i propri limiti già dichiarati. È un progresso. Verificare che quei limiti funzionino davvero rimane comunque una responsabilità dell’architettura.
Fonti
Adobe Journey Optimizer Loyalty Challenges
Adobe Journey Optimizer, release di luglio 2026
Adobe Experience Platform, release di luglio 2026
Adobe Journey Optimizer B2B 2026.6
Scadenze Adobe Marketo Engage
Server MCP remoto di Braze
Showpad Summer ‘26
Scope MCP di 6sense
Optimove, release di luglio 2026
Bloomreach 1.314
HubSpot Agent Hub e Agent Builder
Klaviyo Composer
Release note Iterable
Feed dei rilasci Tealium
MoEngage, release di giugno 2026
Elementi normativi e di settore (EU AI Omnibus, regole di New York sui feed per minori, Clarify/Seam AI, RocketReach MCP, Workato Enterprise MCP Registry)
Riepilogo settimanale
Il digest alla base di ogni articolo settimanale è prodotto attraverso una scansione strutturata, assistita dall’AI, di release note ufficiali e fonti di product update. Io rivedo l’output, verifico i segnali rilevanti e scrivo l’interpretazione architetturale.
Questo articolo si basa sulle scansioni del Martech Weekly Digest eseguite il 30 luglio 2026, che coprivano release note e aggiornamenti di prodotto su diverse piattaforme CEP e vendor.
Se trovate errori o lacune nella copertura, voglio saperlo. Il processo migliora quando l’output viene messo in discussione.
