Negli ultimi mesi Salesforce ha lanciato una delle provocazioni più interessanti sul futuro del software enterprise:
“Why should you ever log into Salesforce again?”
Non è soltanto uno slogan.
Con Headless 360, MCP e, più recentemente, Claudeforce, Salesforce sta progressivamente separando ciò che un software enterprise è da come gli utenti tradizionalmente lo usano.
Per decenni abbiamo considerato quasi inseparabili queste due cose. Un CRM era contemporaneamente un database, un insieme di regole, workflow, sistema di autorizzazioni, API e un’interfaccia attraverso cui le persone accedevano a tutto questo.
Per usare il sistema bisognava quindi entrare nel sistema: aprire Salesforce, cercare un’opportunità, modificare un campo, salvare, aprire un’altra schermata, avviare un Flow, controllare un report.
L’AI sta iniziando a rompere questa equivalenza. E potrebbe essere soltanto l’inizio.
Salesforce trasforma il CRM da applicazione a capability
Approfondimento: Cos’è davvero Headless 360 e perché cambia il software enterprise.
Salesforce descrive ufficialmente Headless 360 come un modo per rendere le capability della piattaforma disponibili ad agenti e altre esperienze mantenendo identità, permessi e governance (Salesforce: Enterprise Applications into Enterprise Capabilities).
Il principio è semplice ma potente: le funzionalità prima usate principalmente tramite interfaccia Salesforce sono ora esposte tramite API, CLI e soprattutto Model Context Protocol (MCP).
La documentazione del server Headless 360 descrive una superficie composta da quattro strumenti — Discover, Describe, Dispatch e Dispatch Read Only — invece di esporre migliaia di operazioni direttamente al modello (documentazione Salesforce Headless 360 MCP Server; Salesforce Developers Blog).
Un agente AI autorizzato può quindi scoprire e utilizzare direttamente dati e funzionalità della piattaforma senza dover simulare un utente che clicca pulsanti: può interrogare record, modificarli, usare workflow o invocare capability direttamente.
Questo rappresenta un cambiamento architetturale importante.
L’interfaccia smette di essere il punto di ingresso obbligatorio al software.
Il software, dati, autorizzazioni, regole, workflow e governance rimangono. Cambia chi orchestra queste componenti e tramite quale interfaccia.
Claudeforce evidenzia ulteriormente questa trasformazione
Claudeforce porta l’idea un passo avanti: un utente può lavorare con Claude mentre Salesforce rimane il sistema sottostante che custodisce dati, processi, autorizzazioni e regole.
Questa separazione è fondamentale perché un Large Language Model (LLM) è efficace nel comprendere intenzioni, interpretare contesto e pianificare azioni, ma un’azienda necessita di governance rigorosa.
Un pagamento deve essere autorizzato o meno. Un ordine deve avere uno stato preciso. Un permesso deve essere confermato. Una fattura non può essere soggetta a interpretazioni linguistiche.
Il futuro del software enterprise non è solo LLM → azione, ma piuttosto intenzione → reasoning → capability governate → esecuzione deterministica.
Una seconda domanda importante
Accettando la premessa di Salesforce, sorge un interrogativo:
Se l’utente non deve necessariamente entrare nel CRM per usarlo, perché continuare a configurarlo nello stesso modo?
Consideriamo un processo aziendale semplice: la gestione delle richieste di smart working.
Tradizionalmente, qualcuno definisce modello dati, crea oggetti e campi, costruisce workflow, configura condizioni, ruoli, autorizzazioni, approvazioni, interfaccia, testa e pubblica. Solo allora un dipendente può usare il processo.
Ma se un agente AI può comprendere richieste come “Voglio un processo per cui i dipendenti richiedano due giorni di smart working settimanali, con approvazione del responsabile e notifica automatica all’HR”, perché dovrebbe limitarsi a usare un processo esistente?
Perché non potrebbe anche costruirlo?
Dall’AI che usa il software all’AI che costruisce il software
Questo potrebbe essere il prossimo passo.
La prima generazione di enterprise AI è stata incentrata sulla conoscenza: AI che risponde.
La seconda riguarda l’azione: AI che utilizza software esistente, accelerata da MCP.
Già si intravede una terza: AI che modifica o costruisce il sistema necessario per raggiungere un obiettivo.
Non si tratta necessariamente di generare codice. L’artefatto importante per molti processi aziendali non è il codice, ma il processo eseguibile che definisce dati, stati, azioni, decisioni, ruoli, approval gate, integrazioni, regole e audit, tutto costruito attraverso la conversazione.
Questo è il concetto di Business Vibe Coding. Ulteriore approfondimento: Da vibe coding a Business Vibe Coding: quando l’AI costruisce processi, non codice.
Dal prompt al processo eseguibile
Immaginiamo di scrivere:
“Quando arriva un nuovo lead verifica se l’azienda esiste già. Se non esiste creala. Assegna il lead al commerciale responsabile della regione. Se il valore stimato supera 100.000 euro richiedi l’approvazione del direttore commerciale. Dopo l’approvazione genera l’opportunità e avvisa il commerciale.”
Non si sta chiedendo una risposta singola o di eseguire operazioni una tantum.
Si sta descrivendo come dovrà funzionare l’azienda da quel momento in avanti.
Questa distinzione è rilevante: il risultato non è testo o codice da copiare, ma un nuovo comportamento persistente e governato del sistema.
L’affidabilità è più importante dell’intelligenza
Più potere conferiamo all’AI, meno possiamo permetterci di affidare tutto all’AI senza controlli.
Un modello può suggerire che una richiesta debba essere approvata dal CFO, ma deve esistere un controllo deterministico che verifichi l’esistenza del CFO, il suo ruolo e la sua autorizzazione specifica.
Il modello può decidere quale azione intraprendere, ma il sistema deve validarla. Può costruire un processo, ma il sistema deve verificarne la coerenza prima di renderlo operativo. Può proporre modifiche, ma il sistema deve sapere con precisione quale versione dello stato è coinvolta.
Il modello può commettere errori. Il sistema deve poter recuperare.
Per questo, il vero problema dell’enterprise AI potrebbe spostarsi dal prompt engineering all’harness engineering. Approfondimento: MCP non basta: perché il futuro dell’enterprise AI è nell’harness.
Il vantaggio competitivo sarà costruire l’ambiente deterministico più affidabile in cui il modello opera, non solo avere il modello più intelligente.
Human-in-the-loop non significa conferma continua
Non si può rispondere all’incertezza dell’AI chiedendo conferma umana per ogni operazione, perché il sistema diverrebbe sicuro ma inutilizzabile.
Il vero problema è distinguere tra operazioni reversibili e irreversibili, basso e alto rischio, modifiche strutturali, decisioni con responsabilità umana e azioni autonomamente eseguibili entro policy definite.
L’approvazione umana deve essere parte integrante dell’architettura del processo, non un’aggiunta all’AI.
L’agente propone e orchestra. L’harness verifica. Le policy delimitano. L’essere umano interviene quando rischio o responsabilità lo richiedono.
La UI non sparisce ma cambia ruolo
Dire che “l’AI sostituirà la UI” è probabilmente una semplificazione. Continueremo ad avere interfacce grafiche, dashboard, tabelle, timeline, grafici, console amministrative ed editor.
Il cambiamento consiste nel fatto che la UI non è più il linguaggio obbligatorio per comunicare al software cosa vogliamo.
Per decenni abbiamo dovuto imparare il linguaggio delle applicazioni: menu, form, campi, wizard, setup, workflow builder, query builder.
L’AI permette di invertire questa relazione: è il software che deve imparare a comprendere il linguaggio dell’azienda.
Cos’è oggi un’applicazione enterprise?
Se l’interfaccia può essere sostituita da una conversazione, le capability scoperte dinamicamente tramite MCP, i dati interrogati in linguaggio naturale, i processi eseguiti e costruiti conversando, quanto rimane del concetto tradizionale di applicazione enterprise?
Probabilmente molto, ma il centro di gravità si sposta.
Il valore non è più tanto nella schermata, quanto nel modello dati, nelle capability, nelle regole, nello stato, nelle autorizzazioni e nei processi che rappresentano il funzionamento reale dell’organizzazione.
L’applicazione diventa un sistema di capability governate.
Headless 360 e oltre Salesforce
Headless 360 e Claudeforce sono rilevanti anche per chi non usa Salesforce.
Essi rappresentano il riconoscimento che l’interfaccia grafica non è più necessariamente il centro del software enterprise.
Headless risponde alla domanda: “Come permettiamo all’AI di utilizzare il software esistente?”
La domanda successiva potrebbe essere: “Come permettiamo all’AI di costruire il software di cui abbiamo bisogno?”
Proprio su questa seconda domanda sta lavorando Flowvenue.
Flowvenue non si limita a permettere a un agente di leggere o modificare dati tramite MCP, ma rende conversazionali anche il modello dati e il processo stesso: consente di descrivere un’esigenza aziendale, trasformarla in un processo governato, renderlo persistente, eseguirlo da client compatibili e modificarlo continuando la conversazione.
Il futuro non è “quale software comprare?”
Per anni il percorso è stato: problema → software → configurazione → integrazione → utilizzo.
L’AI sta comprimendo questa catena.
Potremmo avvicinarci a qualcosa di molto diverso: problema → conversazione → processo eseguibile.
Salesforce mostra che possiamo separare il valore del software dalla sua interfaccia. MCP crea un linguaggio comune per gli agenti che possono così accedere alle capability. I modelli sono sempre più capaci di orchestrare operazioni complesse.
Il passo successivo potrebbe essere rendere dinamico non solo come utilizziamo il software, ma anche come lo costruiamo.
La domanda non sarà più soltanto:
“Why should you ever log into Salesforce again?”
Potrebbe diventare:
“Why should you configure enterprise software manually again?”
Articoli correlati
- Cos’è davvero Headless 360 e perché cambia il software enterprise
- Salesforce Headless 360 e Flowvenue: cosa cambia davvero
- Business Vibe Coding: cos'è e come funziona
- MCP non basta: perché il futuro dell’enterprise AI è nell’harness
Domande frequenti
È l’approccio con cui Salesforce rende dati e capability della piattaforma accessibili anche senza passare necessariamente dalla tradizionale interfaccia grafica, attraverso API, CLI e Model Context Protocol.
MCP permette agli agenti AI di scoprire e utilizzare capability messe a disposizione dai sistemi software attraverso un protocollo comune, separando sempre più l’interazione dell’agente dall’interfaccia grafica.
È l’idea di trasformare una richiesta espressa in linguaggio naturale direttamente in un processo aziendale persistente ed eseguibile, con dati, azioni, decisioni, ruoli, integrazioni, approvazioni e governance.