“La SaaS apocalypse non riguarda la fine del software. Potrebbe riguardare la fine del software che costringe gli esseri umani a fare tutto il lavoro.” Con questa provocazione Marc Benioff, cofondatore, presidente e CEO di Salesforce, ha aperto il keynote principale di Dreamforce 2026, indicando negli agenti il passaggio successivo dell’evoluzione del software aziendale: sistemi capaci di eseguire processi utilizzando contesto, regole, autorizzazioni e controlli già presenti nella piattaforma.
La Interface Revolution introdotta da Salesforce a Dreamforce 2026 separa l’esperienza utente dal CRM sottostante e rende dati, workflow, logica applicativa, semantica e autorizzazioni accessibili da interfacce differenti. Su questa base, gli agenti possono utilizzare direttamente quel patrimonio per eseguire processi, mantenere memoria e stato, richiamare azioni controllate e operare sotto policy di sicurezza e governance.
I frontier model forniscono capacità di reasoning; dati e metadati descrivono il contesto dell’impresa; il livello semantico attribuisce significato alle informazioni; memoria e durable execution mantengono i processi nel tempo; le trusted actions trasformano parte del reasoning in azioni ripetibili; Agent Fabric censisce e governa gli agenti distribuiti nell’organizzazione, mentre Guardian ne controlla identità, accesso ai dati e comportamenti rischiosi.
Il keynote ha tenuto insieme due piani che raramente convivono con questa continuità: l’ingresso degli agenti nei processi reali delle imprese e l’infrastruttura necessaria perché modelli e sistemi possano sostenerli su scala. Siemens e Adecco hanno portato esempi concreti nei processi industriali e nel recruiting, mentre Dario Amodei e Jensen Huang hanno spostato il confronto sulle capacità dei frontier model, sulla sicurezza e sull’infrastruttura che ne rende possibile l’esecuzione.
Circa 7.000 dipendenti Salesforce utilizzano già Claudeforce, l’integrazione che permette di lavorare sui dati e sui processi Salesforce direttamente da Claude. Salesforce utilizza internamente anche alcuni degli agenti specializzati disponibili ai clienti: Hunter lavora sullo sviluppo della pipeline commerciale e Casey sull’assistenza clienti, mentre Fin, la tecnologia di customer service entrata nel perimetro Salesforce con l’acquisizione dell’omonima società, viene utilizzato per automatizzare le interazioni di assistenza. Hunter ha generato 500 milioni di dollari di pipeline nell’ultimo trimestre, Casey ha gestito 5 milioni di conversazioni di assistenza su help.salesforce.com e Fin è stato messo in funzione internamente in circa 12 giorni. Agentforce ha superato i 30.000 clienti, mentre Agent Script e le funzioni vocali sono ora in disponibilità generale.
Marshall apprende un processo SAP e lo trasforma in trusted actions
“Stiamo portando una tecnologia probabilistica in un mondo deterministico. Le allucinazioni non funzionano davvero in fabbrica.” La frase di Roland Busch, presidente e CEO di Siemens, riassume il problema che emerge quando un agente entra in processi industriali governati da procedure rigide e sistemi come SAP. Marshall, l’agente dedicato ai processi di supply chain e back-office, viene utilizzato nell’onboarding dei fornitori Siemens, una procedura che attraversa documenti, verifiche, approvazioni e sistemi back-end.
Il risultato dell’apprendimento viene trasformato in una libreria di trusted actions, cioè in un insieme di azioni operative già apprese e definite che Marshall può richiamare durante l’esecuzione del processo. Nella fase di apprendimento il modello usa il reasoning per capire come funziona la procedura — quali campi compilare, quali passaggi seguire e quali regole di business modificano il percorso — ma, una volta costruita la libreria, non deve ragionare nuovamente da zero a ogni onboarding. Per Salesforce è il passaggio dal reasoning probabilistico all’esecuzione deterministica: Marshall esegue ogni volta lo stesso insieme di trusted actions, riducendo lo spazio lasciato all’improvvisazione proprio nelle operazioni che devono essere ripetibili e corrette.
Se SAP o il processo sottostante cambiano, l’automazione non rimane cristallizzata sulla procedura precedente: Marshall torna nella sandbox, riapprende il flusso e adatta la propria libreria di azioni. È questa combinazione tra apprendimento tramite AI e successiva esecuzione controllata che Salesforce definisce trusted process automation.
Da questa combinazione nasce la trusted process automation: il reasoning viene utilizzato per apprendere e interpretare il processo, mentre l’esecuzione successiva si appoggia a trusted actions controllate e ripetibili, così che il modello non debba ricostruire ogni volta la procedura. Salesforce descrive questo passaggio come la trasformazione del reasoning dell’AI in esecuzione deterministica: l’intelligenza del modello serve a comprendere il flusso e le sue regole, mentre l’operatività viene affidata a un insieme di azioni già apprese e riutilizzabili. Per Siemens, l’onboarding dei fornitori può così scendere da giorni a ore.
Piper trasforma una conversazione in pipeline
Sempre in Siemens, Piper, l’AI SDR agent (Sales Development Representative) di Qualified, acquisita da Salesforce nell’aprile 2026, lavora sulla generazione e qualificazione della pipeline. Riconosce un potenziale cliente proveniente da una precedente comunicazione, utilizza ruolo, azienda e informazioni disponibili nel CRM e costruisce una presentazione personalizzata direttamente nell’interfaccia del sito.
Quando la conversazione passa dalle informazioni generali a una domanda sul modello commerciale, Piper interpreta il segnale come intenzione d’acquisto, individua in Salesforce l’account executive responsabile e permette di fissare direttamente un incontro. La conversazione diventa così pipeline senza modulo intermedio e senza attendere una successiva qualificazione manuale, mentre identità, dati CRM e regole commerciali determinano quando il contatto debba passare dall’agente a una persona. Sul versante outbound, Hunter lavora invece sulla qualificazione e sullo sviluppo delle opportunità commerciali.
Dati e metadati rimangono sotto interfacce differenti
Dati, metadati, processi, autorizzazioni e business logic possono essere utilizzati indipendentemente dall’interfaccia attraverso cui l’utente accede alla piattaforma. Parker Harris, cofondatore di Salesforce e creatore di Lightning, ha sintetizzato questa separazione con una domanda: perché l’utente dovrebbe ancora essere obbligato ad accedere a Salesforce se un’altra interfaccia può utilizzare gli stessi dati e gli stessi processi?
L’architettura metadata-first mantiene oggetti, campi, relazioni, processi, autorizzazioni e altre definizioni applicative nel livello dei metadati invece di vincolarle alla singola schermata; gli stessi elementi possono quindi essere ricomposti in interfacce differenti senza ricostruire ogni volta la logica dell’applicazione.
Le applicazioni Salesforce sono headless, una direzione già sviluppata con Headless 360: il livello applicativo continua a gestire dati, metadati, processi e autorizzazioni, mentre l’esperienza utente può essere costruita altrove. Claude, Slack, Lightning o un’altra interfaccia possono diventare front-end differenti dello stesso patrimonio applicativo. “In realtà le applicazioni non hanno mai avuto una ‘testa’: quella funzione è sempre stata nel livello dei metadati”, osserva Benioff.
Un SDK di AIforce consentirà inoltre a sviluppatori e clienti di costruire applicazioni e interfacce proprie su questo livello. Benioff prevede che entro il prossimo Dreamforce possano esistere decine di live interface differenti costruite sulla piattaforma.
Claudeforce rende Claude un’interfaccia verso Salesforce
Claudeforce collega Claude alla piattaforma Salesforce attraverso un server Model Context Protocol (MCP) preconfigurato, skill e strumenti dedicati. Patrick Stokes, EVP Product & Industries Marketing di Salesforce, ha realizzato una prima versione funzionante della propria interfaccia in sei-otto minuti, perfezionandola poi nei giorni successivi attraverso richieste in linguaggio naturale.
Patrick Stokes, EVP Product & Industries Marketing di Salesforce, ha mostrato durante il keynote la live interface costruita attraverso richieste in linguaggio naturale: una prima versione, ha spiegato, può essere realizzata in circa sei-otto minuti, mentre i giorni successivi servono a iterare sull’interfaccia e aggiungere funzionalità.
L’utente può definire come organizzare l’interazione con dati, record e processi e modificare l’interfaccia senza intervenire direttamente sul codice della piattaforma sottostante. Il plug-in comprende l’accesso MCP, il supporto alla Zero Data Retention, che impedisce la conservazione del contesto aziendale da parte del provider del modello oltre quanto previsto per l’elaborazione, e skill Salesforce per Claude Enterprise, con controllo amministrativo sugli utenti autorizzati.
Il modello generalista non conosce l’impresa
Rohan Kumar, President of Platform and Engineering di Salesforce, parte da un limite fondamentale dei frontier model: possono conoscere enormi quantità di informazioni sul mondo, ma non conoscono automaticamente clienti, prodotti, dipendenti, transazioni, conversazioni e workflow di una specifica organizzazione. Per operare nell’impresa, il modello deve quindi ricevere quello che Salesforce chiama enterprise context, cioè l’insieme di dati e relazioni necessario per comprendere il contesto nel quale sta agendo.
Informatica individua, cataloga e prepara i dati distribuiti tra applicazioni, data lake, warehouse e altri sistemi; Data 360 costruisce poi il contesto utilizzabile dall’agente, anche attraverso meccanismi zero-copy che permettono di lavorare su dati esterni senza doverli duplicare fisicamente nella piattaforma.
A questo livello si aggiunge quello semantico. Termini apparentemente semplici come ricavi, churn o account receivable non hanno necessariamente lo stesso significato in aziende diverse, perciò Tableau mette a disposizione degli agenti metriche, relazioni e definizioni di business necessarie per interpretare correttamente quei dati. Il modello lavora quindi su tre categorie di conoscenza differenti — dato, contesto e semantica — senza le quali può essere molto capace sul piano generale e contemporaneamente incapace di comprendere come funzioni l’organizzazione nella quale deve operare.
Il runtime deve inoltre poter utilizzare modelli differenti in funzione del compito. Koa, il CRM reasoning model sviluppato da Salesforce con Nvidia sulla famiglia Nemotron, è stato progettato anche per agenti di lunga durata che eseguono più attività e perseguono risultati complessi. La scelta del modello può così essere adattata al rapporto tra prestazioni, costo e risultato richiesto, mentre memoria, contesto, workflow e capacità operative rimangono nel livello Agentforce.
Memoria e durable execution per processi che durano giorni o settimane
Molti processi aziendali si protraggono per giorni o settimane, attendono un’approvazione, vengono interrotti da un evento esterno e successivamente riprendono. Il runtime di Agentforce, cioè il livello che mantiene in esecuzione gli agenti e ne coordina stato e attività, supporta memoria e durable execution, permettendo a un processo di riprendere dal punto in cui era stato interrotto senza ricostruire da zero il contesto precedente.
Il dynamic steering consente di modificare istruzioni o comportamento durante l’esecuzione, adattando il processo senza doverne ricostruire integralmente il flusso, mentre Agent Script permette di definire in modo esplicito istruzioni, condizioni e branching. Le parti che richiedono reasoning possono quindi convivere con regole più rigide e percorsi deterministici.
La Multi-Agent Orchestration coordina più agenti specializzati all’interno dello stesso processo, mentre Agent Optimizer analizza le esecuzioni e individua possibilità di miglioramento. Agentforce assume così anche il ruolo di runtime per processi persistenti, capaci di conservare stato e memoria, attendere eventi esterni e coordinare più agenti durante un’esecuzione che può protrarsi nel tempo.
Gli agenti entrano nei processi di Sales, Service, Marketing e Commerce
Sul versante commerciale, Hunter opera nelle attività outbound e può utilizzare fonti esterne di dati per prospezione e qualificazione, mentre un Campaign Agent costruisce campagne marketing, ne modifica i contenuti e continua a iterare sulla base dei risultati. In Commerce Cloud, uno shopper agent utilizza informazioni operative come disponibilità di magazzino e condizioni di consegna e può proporre alternative quando il prodotto richiesto non è disponibile.
Nei processi operativi, l’interazione voice-to-text del Field Service permette a un tecnico di compilare moduli e aggiornare la documentazione parlando mentre continua a lavorare. Revenue Cloud utilizza invece un renewals agent per individuare gli account sui quali intervenire, gestire i rinnovi e riconoscere opportunità di upselling, mentre nel customer service un Contact Center as a Service (CCaaS) riunirà telefonia e CRM nello stesso sistema.
Sul fronte IT, una nuova Configuration Management Database (CMDB) aggiorna automaticamente la mappa degli asset. Tableau aggiunge proactive intelligence, con analisi che possono essere prodotte senza attendere una richiesta esplicita dell’utente. Il tratto comune è l’accesso dell’agente ai dati operativi e alle azioni dell’applicazione: inventario, appuntamenti, rinnovi, documentazione tecnica e configurazione IT diventano elementi dello stesso processo di esecuzione.
Agent Fabric gestisce agenti Salesforce e di altri fornitori
MuleSoft Agent Fabric è il livello di discovery, governance e osservabilità destinato a gestire agenti provenienti da piattaforme differenti. Gli scanner individuano continuamente quelli presenti nell’organizzazione, compresi gli agenti esterni all’ecosistema Salesforce, e possono censire sistemi di Microsoft/Azure, AWS, Google e Agentforce, evitando che l’amministrazione dipenda da registri separati per ciascun provider.
Per ogni agente diventano visibili le skill utilizzate, le sorgenti da cui proviene il grounding, cioè il contesto informativo fornito al modello, e la data lineage, che permette di ricostruire la provenienza delle informazioni. L’integrazione con Informatica consente inoltre all’amministratore di stabilire a quali fonti l’agente possa collegarsi.
Al registro si aggiunge un livello di osservabilità che comprende latenza media, tasso di errore, violazioni delle policy e volume delle richieste, in modo da seguire il comportamento dell’agente nel tempo e confrontarlo con le regole previste. Gli Agent Fabric Wallets associano inoltre budget ai singoli agenti e permettono di monitorarne il consumo nel corso del mese, mentre l’analisi delle interazioni può produrre raccomandazioni per ridurre il consumo di token, sottoposte all’amministratore prima dell’applicazione.
Un agente viene quindi trattato come una risorsa governata: ha un’identità, utilizza dati e modelli, consuma risorse, genera costi e può violare policy, con un proprio ciclo di vita e parametri operativi da controllare.
Guardian separa l’identità dell’agente da quella dell’utente
Salesforce Guardian, evoluzione delle tecnologie di sicurezza Shield e Trusted Services, concentra il controllo su due aree: agent identity e data security. L’accesso tradizionale ai sistemi enterprise parte dall’identità di una persona o di un servizio e dalle autorizzazioni attribuitele; gli agenti aggiungono un livello ulteriore, perché possono agire autonomamente per conto di un utente e utilizzare in pochi secondi una quantità di permessi e dati che una persona impiegherebbe molto più tempo ad attraversare.
Guardian individua gli agenti considerati rischiosi in base alle azioni che stanno compiendo e identifica contemporaneamente dati non classificati o non protetti. Permette quindi di applicare policy a uno specifico agente, alle risorse che può utilizzare, allo scopo dell’accesso e al grado di autonomia consentito, separando l’identità dell’agente da quella della persona per conto della quale opera.
Rimane inoltre il principio di Zero Data Retention: il contesto aziendale utilizzato dai modelli per il reasoning non deve essere conservato al di fuori dei confini definiti dall’organizzazione.
Adecco applica Agentforce ai processi centrali del recruiting
Oltre 5 milioni di candidature al mese danno la misura del problema che Adecco sta affrontando con Agentforce. Denis Machuel, CEO di Adecco Group, lega l’automazione soprattutto alle attività che sottraggono tempo alla relazione tra recruiter, candidati e clienti.
Un agente basato su Agentforce Voice gestisce conversazioni con i candidati 24 ore su 24, utilizzando il contesto di Data 360 e Customer 360 per conoscere identità, candidatura, ruolo richiesto e stato delle certificazioni. Nel 2026 sono già state gestite 2,6 milioni di interazioni agentiche.
Una certificazione scaduta può, per esempio, bloccare una candidatura: durante la telefonata l’agente identifica il problema, riceve dal candidato il numero della certificazione rinnovata, ne verifica la validità e aggiorna lo stato della pratica. Lo stesso servizio può essere eseguito contemporaneamente per centinaia di migliaia di candidati, mentre una live interface in Slackforce permette ai responsabili di seguire la distribuzione geografica delle conversazioni e la progressione dei candidati verso l’assunzione, quindi non soltanto il volume delle interazioni ma l’avanzamento del processo fino al risultato.
“Siamo un’azienda di persone e il recruiting riguarda persone che parlano con persone”, osserva Machuel. I recruiter svolgevano però molte attività che lasciavano troppo poco tempo alla relazione diretta con candidati e clienti. “Non siamo partiti da dove era facile. Siamo partiti da ciò che contava di più, dai processi centrali.”
L’automazione ha liberato, secondo il CEO, circa il 35-40% del tempo dei recruiter, riutilizzato per conversazioni di maggiore qualità con clienti e candidati. Adecco attribuisce a questa maggiore capacità di relazione anche 20.000 persone in più collocate dall’inizio dell’anno.
Dario Amodei: capacità dei modelli e diffusione nell’impresa corrono a velocità diverse
La distanza tra ciò che i modelli sanno già fare e ciò che le imprese riescono effettivamente a utilizzare è uno dei punti centrali dell’intervento di Dario Amodei, cofondatore e CEO di Anthropic. Anthropic sviluppa Claude ed è il partner tecnologico alla base di Claudeforce; la velocità con cui strumenti recenti come MCP, Coworker e Claude Skills vengono adottati mostra, nella sua lettura, quanto rapidamente le nuove capacità possano tradursi in prodotti e valore economico.
Il miglioramento dei modelli procede più rapidamente della loro diffusione effettiva nelle organizzazioni. “Anche se congelassimo la tecnologia al livello attuale, cosa che non stiamo facendo, probabilmente stiamo utilizzando soltanto il 5 o il 10% del suo valore possibile”, afferma Amodei.
L’esempio arriva dallo stesso utilizzo di Salesforce dentro Anthropic. I responsabili commerciali possono interrogare Claude sui dati CRM per sapere quali siano le dieci trattative più importanti della settimana, quali abbiano maggiori probabilità di essere perse, quali temi ricorrano nei deal a rischio e quali azioni possano aumentarne le possibilità di successo. Il CRM rimane la fonte dei dati, mentre Claude diventa il livello attraverso il quale quei dati vengono interrogati, correlati e utilizzati nel processo decisionale.
Soltanto una frazione delle persone che potrebbero trarre utilità da questo tipo di interazione ne ha già sperimentato le possibilità, lasciando un ampio divario fra ciò che i modelli sono già in grado di fare e ciò che le imprese riescono effettivamente a incorporare nei propri workflow. Questa distanza attribuisce maggiore importanza ai livelli che collegano il modello ai sistemi aziendali: accesso ai dati, contesto, semantica, strumenti, memoria, autorizzazioni e capacità di esecuzione.
La sicurezza e il ritmo di sviluppo dei frontier model rimangono parte integrante della posizione di Amodei, che lega l’aumento delle capacità dei modelli alla necessità di meccanismi di controllo più robusti e di una governance capace di seguire la crescente concentrazione tecnologica ed economica dell’AI. Negli ultimi mesi il CEO di Anthropic ha proposto checkpoint di sicurezza, valutatori indipendenti e forme di coordinamento tra i principali sviluppatori di AI di frontiera; a Dreamforce ha insistito sullo stesso principio, sostenendo che gli incidenti dei concorrenti dovrebbero spingere le aziende a verificare le proprie pratiche, aumentare la trasparenza, investire ulteriormente nella sicurezza e contribuire alla definizione di standard condivisi, affiancati da un coordinamento internazionale.
La stessa impostazione riguarda il rapporto tra apertura e controllo dei rischi. Anthropic non propone un divieto generalizzato dei modelli open weight, ma controlli mirati su capacità, distillazione, chip e valutazioni di sicurezza. L’aumento delle capacità dei modelli procede così insieme a due problemi distinti: la loro diffusione nei processi aziendali e la costruzione di meccanismi di sicurezza adeguati alla velocità con cui avanzano.
Jensen Huang: l’AI diventa un nuovo livello infrastrutturale sopra il software
Con Jensen Huang, fondatore e CEO di Nvidia, il discorso passa dalla diffusione dei modelli alla scala infrastrutturale necessaria per sostenerli. L’AI, nella sua lettura, sta assumendo un ruolo paragonabile per portata a elettricità e Internet, fino a trasformare ogni impresa e, più in generale, ogni organizzazione in una “AI company”.
Nvidia ha esteso progressivamente il proprio ruolo da produttore di GPU a fornitore di un’infrastruttura full stack basata sulle AI factory, grandi sistemi nei quali potenza di calcolo e dati vengono convertiti in capacità di inferenza. La collaborazione con Salesforce comprende anche Koa, costruito sulla famiglia Nemotron.
Sopra questa infrastruttura Nvidia sta costruendo famiglie di modelli specializzati. Nemotron è dedicato al linguaggio, Cosmos ai world model, BioNeMo alla biologia e alle proteine, GR00T alla robotica, mentre altri modelli coprono sistemi autonomi e navigazione. Huang insiste sulla natura aperta di questi modelli e sulla possibilità per le imprese di utilizzarli come base per sistemi propri.
Il modello costituisce soltanto una parte dello stack. Nvidia affianca ai modelli un agentic harness, il livello che raccoglie modello, strumenti e runtime necessari all’esecuzione degli agenti, e OpenShell, una sandbox e un runtime sicuro destinati alla distribuzione degli agenti su larga scala nelle imprese. Huang prevede inoltre una coesistenza fra modelli chiusi, modelli open e modelli privati personalizzati dalle singole imprese: proprio in quest’ultima direzione si colloca la collaborazione con Salesforce, nella quale il modello generalista fornisce una base, mentre dati, specializzazione e contesto aziendale consentono di costruire sistemi più aderenti ai singoli domini applicativi.
Anche sulla sicurezza Huang rifiuta una contrapposizione rigida tra rapidità dell’innovazione e controllo. “La sicurezza è soprattutto un problema ingegneristico”, sostiene, indicando come elementi centrali ambienti di test adeguati, verifica dei sistemi e decisione di sospenderne la distribuzione finché funzionalità e sicurezza non abbiano raggiunto un livello considerato adeguato. Velocità e sicurezza, nella sua lettura, possono procedere insieme: “Si possono avere entrambe contemporaneamente.”
Huang collega inoltre la crescita dell’AI enterprise alla pluralità dei modelli e alla tendenza delle aziende a costruire sistemi personalizzati sui propri dati e processi. Questa architettura lo porta a respingere anche la tesi sulla fine del software: “La fine del software è una sciocchezza. Questo sarà un livello sopra il software.”
Per Huang il nuovo livello sarà agentico e permetterà di utilizzare meglio il software esistente. I system of record continuano a custodire dati, relazioni, autorizzazioni, regole e processi; sopra di essi si forma un livello capace di interpretarli e agire. La posizione converge con la tesi iniziale di Benioff sulla SaaS apocalypse: a perdere centralità può essere il software inteso come sequenza di schermate, menu e procedure che una persona deve conoscere e percorrere direttamente.
Dal modello all’esecuzione
Il modello fornisce reasoning e può essere generalista o specializzato; il contesto enterprise gli fornisce dati e conoscenza dell’organizzazione; il livello semantico stabilisce il significato aziendale delle informazioni; memoria e durable execution mantengono stato e continuità dei processi; le trusted actions trasformano parte del reasoning in esecuzione controllabile; Agent Fabric censisce, osserva e misura gli agenti; Guardian governa identità e dati.
L’interfaccia rimane uno dei possibili punti di accesso, mentre dati, semantica, regole, processi e azioni costituiscono il patrimonio che l’agente utilizza per raggiungere un risultato. La “SaaS apocalypse” evocata da Benioff riguarda quindi il rapporto tra persone e applicazioni: una parte crescente dell’esecuzione passa agli agenti.
Il software continua a codificare il funzionamento dell’impresa. Cambia chi lo percorre.
