Dopo Headless 360: se l’AI sostituisce l’interfaccia, cosa succede al software enterprise?

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, dei workflow, un sistema di autorizzazioni, delle API e un’interfaccia attraverso cui le persone accedevano a tutto questo.

Per utilizzare 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 sta trasformando 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 dietro Headless 360 è semplice quanto potente. Le funzionalità che prima venivano utilizzate principalmente attraverso l’interfaccia Salesforce possono essere esposte tramite API, CLI e soprattutto Model Context Protocol.

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. Non deve necessariamente simulare una persona che clicca pulsanti: può interrogare un record, modificarlo, utilizzare un workflow o invocare una business capability direttamente.

È un cambiamento architetturale molto più importante di quanto possa sembrare.

L’interfaccia smette di essere il punto di ingresso obbligatorio al software.

Il software rimane. I dati rimangono. Le autorizzazioni rimangono. Le business rule rimangono. I workflow rimangono. La governance rimane.

Quello che cambia è chi li orchestra e attraverso quale interfaccia.

Claudeforce rende questa trasformazione ancora più evidente

Claudeforce porta questa idea un passo avanti: l’utente può lavorare con Claude mentre Salesforce continua a svolgere il ruolo di sistema sottostante.

Il modello ragiona. Salesforce custodisce dati, processi, autorizzazioni e regole.

È una separazione fondamentale, perché un LLM è straordinariamente efficace nel comprendere intenzioni, interpretare contesto e pianificare azioni. Ma un’azienda non può essere governata esclusivamente dalla probabilità.

Un pagamento deve essere autorizzato oppure no. Un ordine deve avere uno stato preciso. Un utente deve avere oppure non avere un permesso. Una fattura emessa non può diventare una questione di interpretazione linguistica.

Il futuro del software enterprise non sembra quindi essere semplicemente LLM → azione.

È molto più probabilmente: intenzione → reasoning → capability governate → esecuzione deterministica.

Ma c’è una seconda domanda

Se accettiamo la premessa di Salesforce, emerge una conseguenza interessante.

Se l’utente non deve necessariamente entrare nel CRM per utilizzarlo, perché deve continuare a configurarlo nello stesso modo?

Prendiamo un processo aziendale relativamente semplice: un’azienda vuole gestire le richieste di smart working.

Tradizionalmente qualcuno deve definire il modello dati, creare oggetti e campi, costruire il workflow, configurare condizioni, ruoli e autorizzazioni, creare le approvazioni, realizzare l’interfaccia, testare e pubblicare.

Dopo tutto questo, finalmente un dipendente può utilizzare il processo.

Ma se un agente è già in grado di comprendere una richiesta come “Voglio un processo con cui i dipendenti possano richiedere due giorni di smart working alla settimana, con approvazione del responsabile e notifica automatica all’HR”, perché dovrebbe limitarsi a utilizzare un processo precedentemente costruito?

Perché non potrebbe anche costruirlo?

Dall’AI che usa il software all’AI che costruisce il software

Qui potrebbe trovarsi il passaggio successivo.

La prima generazione di enterprise AI ha riguardato soprattutto la conoscenza: AI che risponde.

La seconda sta riguardando l’azione: AI che utilizza software esistente. MCP sta accelerando enormemente questa fase.

Ma ne intravediamo già una terza: AI che modifica o costruisce il sistema necessario per raggiungere un obiettivo.

Non significa necessariamente generare codice. Ed è proprio questo il punto.

Per molti processi aziendali il codice potrebbe non essere affatto l’artefatto interessante. L’artefatto potrebbe essere direttamente il processo eseguibile: dati, stati, azioni, decisioni, ruoli, approval gate, integrazioni, regole e audit.

Tutto costruito conversando.

È ciò che possiamo chiamare Business Vibe Coding. Per entrare nel merito: 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 stiamo chiedendo una risposta. Non stiamo nemmeno chiedendo semplicemente a un agente di eseguire una serie di operazioni una volta.

Stiamo descrivendo come dovrà funzionare l’azienda da quel momento in avanti.

Questa distinzione è enorme. Il risultato della conversazione non è testo. Non è codice da copiare. È un nuovo comportamento persistente del sistema.

Ed è qui che l’affidabilità diventa più importante dell’intelligenza

Più potere diamo all’AI, meno possiamo permetterci di affidare tutto all’AI.

Un modello può proporre che una richiesta debba essere approvata dal CFO. Ma deve esistere qualcosa di deterministico che verifichi che quel CFO esista, che abbia quel ruolo e che sia autorizzato ad approvare quella specifica operazione.

Il modello può decidere quale azione utilizzare, ma il sistema deve controllare che quell’azione sia valida. Può costruire un processo, ma il sistema deve poter verificare che sia consistente prima di renderlo operativo. Può tentare una modifica, ma il sistema deve sapere con certezza quale versione dello stato stia modificando.

Il modello può sbagliare. Il sistema deve poter recuperare.

Per questo il vero problema dell’enterprise AI potrebbe spostarsi rapidamente dal prompt engineering all’harness engineering. Abbiamo approfondito questo punto in MCP non basta: perché il futuro dell’enterprise AI è nell’harness.

Il vantaggio competitivo non sarà soltanto avere il modello più intelligente. Sarà costruire l’ambiente deterministico più affidabile dentro cui quel modello può operare.

Human-in-the-loop non significa mettere un “Conferma” ovunque

La risposta all’incertezza dell’AI non può essere chiedere conferma umana per qualsiasi operazione. Un sistema del genere sarebbe sicuro, ma probabilmente inutilizzabile.

Il vero problema diventa distinguere fra operazioni reversibili e irreversibili, basso e alto rischio, modifiche strutturali, decisioni che richiedono responsabilità umana e azioni che possono essere autonomamente eseguite entro policy definite.

L’approvazione umana diventa quindi parte dell’architettura del processo, non una toppa aggiunta all’AI.

L’agente propone e orchestra. L’harness verifica. Le policy delimitano. L’essere umano interviene dove il rischio o la responsabilità lo richiedono.

La UI non scompare. Cambia ruolo.

Dire che “l’AI sostituirà la UI” rischia di essere una semplificazione. Probabilmente continueremo ad avere interfacce grafiche, dashboard, tabelle, timeline, grafici, console amministrative ed editor.

Il cambiamento è un altro: la UI smette di essere il linguaggio obbligatorio con cui dobbiamo spiegare al software cosa vogliamo.

Per quarant’anni siamo stati noi a dover imparare il linguaggio delle applicazioni: menu, form, campi, wizard, setup, workflow builder, query builder.

L’AI permette potenzialmente di invertire questa relazione. È il software che deve imparare a comprendere il linguaggio dell’azienda.

E allora cos’è davvero un’applicazione?

Se l’interfaccia può essere sostituita da una conversazione, le capability possono essere scoperte dinamicamente tramite MCP, i dati possono essere interrogati in linguaggio naturale, i processi possono essere eseguiti dagli agenti e gli stessi processi possono essere costruiti conversando, quanto rimane del concetto tradizionale di applicazione enterprise?

Forse molto. Ma cambia il centro di gravità.

Il valore non sarà necessariamente nella schermata. Sarà nel modello dati, nelle capability, nelle regole, nello stato, nelle autorizzazioni e nei processi che rappresentano il funzionamento reale dell’organizzazione.

L’applicazione diventa sempre meno una destinazione. Diventa un sistema di capability governate.

Salesforce ha aperto una porta molto più grande di Salesforce

Ed è per questo che Headless 360 e Claudeforce sono interessanti anche per chi non utilizza Salesforce.

Salesforce sta implicitamente riconoscendo qualcosa di importante: l’interfaccia grafica non è più necessariamente il centro del software enterprise.

Ma potrebbe esserci un passaggio ulteriore.

Headless risponde alla domanda: “Come permettiamo all’AI di utilizzare il software che abbiamo già costruito?”

La domanda successiva potrebbe essere: “Come permettiamo all’AI di costruire il software di cui abbiamo bisogno?”

È su questa seconda domanda che stiamo lavorando in Flowvenue.

L’obiettivo non è semplicemente permettere a un agente di leggere o modificare dati attraverso MCP. È rendere conversazionali anche il modello dati e il processo stesso: descrivere un’esigenza aziendale, trasformarla in un processo governato, renderlo persistente, eseguirlo da client compatibili e modificarlo continuando la conversazione.

La prossima domanda non sarà “quale software devo 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 sta mostrando che possiamo separare il valore del software dalla sua interfaccia. MCP sta creando un linguaggio comune attraverso cui gli agenti possono accedere alle capability. I modelli stanno diventando sufficientemente capaci da orchestrare operazioni sempre più complesse.

Il passaggio successivo potrebbe essere rendere dinamico non soltanto 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?”