Come siamo arrivati qui

Per molto tempo il rapporto tra software e intelligenza artificiale è stato relativamente semplice: l'applicazione inviava un prompt a un modello, il modello restituiva testo, e il software decideva cosa farne. Questo approccio funzionava bene per generare contenuti, riassumere documenti o rispondere a domande, ma mostrava subito i suoi limiti quando il modello doveva fare qualcosa: leggere dati, modificare record, avviare workflow, interrogare sistemi esterni o prendere decisioni operative.

Per superare questo limite sono nati i meccanismi di function calling e tool use. L'idea è semplice: invece di chiedere al modello solo una risposta testuale, gli si fornisce un elenco di strumenti disponibili, ognuno con un nome, una descrizione e uno schema di input. Il modello può così scegliere quale strumento invocare e con quali parametri.

Questo ha rappresentato un passaggio fondamentale. I modelli hanno smesso di essere semplici generatori di testo e sono diventati orchestratori di azioni. Tuttavia, ogni provider ha iniziato a implementare questo paradigma a modo proprio: OpenAI con il proprio function calling, Anthropic con il proprio tool use, Google con i propri strumenti, e così via.

Il risultato è stato un nuovo tipo di frammentazione. Non bastava più costruire una capacità applicativa; bisognava anche adattarla al formato richiesto da ogni modello. Cambiare provider significava spesso riscrivere adapter, payload, gestione degli errori, formati di risposta e logiche di orchestrazione.

MCP nasce dentro questo contesto: non come una bacchetta magica, ma come tentativo di standardizzare il modo in cui un modello può scoprire e invocare capability esterne. In altre parole, MCP prova a rispondere a una domanda concreta: possiamo evitare che ogni applicazione debba reinventare da zero il proprio modo di parlare con ogni modello?

Perché molti sviluppatori preferiscono la CLI

Per comprendere davvero il dibattito attuale è importante partire da una constatazione semplice: gran parte degli sviluppatori che criticano MCP non stanno attaccando il protocollo in sé. Stanno evidenziando un problema pratico che incontrano ogni giorno quando costruiscono agenti AI che devono interagire con sistemi reali.

Se un modello deve eseguire un deploy Kubernetes, creare una branch Git, lanciare un test automatico o interrogare Docker, esiste già uno strumento progettato esattamente per questo scopo: la CLI. Questi strumenti sono maturi, documentati, stabili e utilizzati da milioni di sviluppatori in tutto il mondo.

Da questo punto di vista la critica è perfettamente ragionevole. Se l'obiettivo finale è eseguire:

docker deploy
kubectl apply
git commit
terraform apply

introdurre un ulteriore livello di astrazione può apparire inutile. Molti agenti moderni sono perfettamente in grado di comprendere la documentazione di una CLI, generare i comandi corretti, interpretarene l'output e gestire eventuali errori. In questi casi la shell diventa già un'interfaccia universale.

Non sorprende quindi che sia nata una corrente di pensiero sintetizzata nella frase:

MCP is bad, bash is better.

Dietro questa provocazione esiste una logica tecnica precisa. Una CLI presenta alcuni vantaggi difficili da contestare:

• È estremamente efficiente dal punto di vista computazionale.
• Non richiede descrizioni verbose degli strumenti.
• Non genera overhead di token per la scoperta delle capability.
• È altamente deterministica.
• È già parte integrante dell'ecosistema DevOps moderno.
• Può essere utilizzata sia da umani sia da sistemi automatici.

In molti scenari tecnici, soprattutto quelli orientati all'automazione infrastrutturale, la CLI rappresenta probabilmente la soluzione più semplice ed elegante disponibile oggi.

Ed è proprio qui che nasce il malinteso più frequente. Quando si osservano questi casi d'uso è facile arrivare alla conclusione che MCP sia soltanto una versione più complessa di una CLI. Ma questa conclusione deriva da un'assunzione implicita: che il problema da risolvere sia semplicemente l'esecuzione di un comando.

In realtà esistono contesti in cui il comando rappresenta soltanto l'ultimo anello di una catena molto più lunga. Quando il dominio non è più una macchina, ma un'intera applicazione aziendale fatta di processi, autorizzazioni, workflow, regole e dati, il confronto diretto tra MCP e CLI inizia a perdere significato.

Perché MCP e CLI non sono concorrenti diretti

A questo punto è utile fermarsi un momento e osservare come viene normalmente rappresentato il confronto tra MCP e CLI.

Nella maggior parte delle discussioni il ragionamento segue questo schema:

Modello AI
    ↓
   MCP
    ↓
docker deploy

contro:

Modello AI
    ↓
   CLI
    ↓
docker deploy

Se il problema è realmente questo, la conclusione è spesso corretta: una CLI può essere più semplice, più efficiente e più immediata.

Tuttavia questa rappresentazione nasconde un presupposto fondamentale: assume che ciò che viene esposto al modello sia semplicemente un comando tecnico.

Nella realtà delle applicazioni aziendali moderne, il livello di astrazione è spesso molto diverso. Un sistema gestionale, un CRM, una piattaforma di workflow o un sistema ERP non espongono semplicemente comandi. Espongono concetti di business.

Ad esempio:

Approva una nota spese
Apri un'opportunità commerciale
Genera il report KPI del trimestre
Pubblica un processo
Avanza una pratica alla fase successiva
Calcola il budget residuo

Nessuna di queste operazioni corrisponde necessariamente a un singolo comando. Dietro ognuna possono esistere decine di controlli, autorizzazioni, validazioni, interrogazioni di database, chiamate API, regole di business e workflow.

In questi scenari il confronto corretto non è più:

MCP vs CLI

ma:

Come rappresento capability aziendali
in modo comprensibile per qualsiasi AI?

Questo cambia radicalmente la prospettiva.

Una CLI è progettata principalmente per consentire a un operatore o a uno script di eseguire operazioni tecniche. Un protocollo come MCP, invece, nasce per descrivere a un modello:

• quali capability sono disponibili;
• quando possono essere utilizzate;
• quali parametri richiedono;
• quali vincoli devono essere rispettati;
• quali risultati producono.

Non significa che MCP sia superiore alla CLI. Significa che stanno operando a livelli diversi dell'architettura.

Un'analogia utile può essere quella tra database e API REST.

Nessuno direbbe che PostgreSQL è "migliore" di un'API REST o viceversa. Sono strumenti che risolvono problemi differenti. Il database gestisce la persistenza dei dati; l'API espone funzionalità consumabili da sistemi esterni.

Allo stesso modo una CLI e un protocollo di integrazione per modelli possono coesistere perfettamente. Anzi, in molti casi le implementazioni migliori utilizzano entrambe le soluzioni: la CLI come interfaccia operativa e un protocollo standard come strato di interoperabilità verso gli agenti AI.

Per questo motivo il dibattito "MCP contro CLI" rischia spesso di essere fuorviante. Non perché una delle due tecnologie sia sbagliata, ma perché stanno cercando di risolvere problemi che solo in parte si sovrappongono.

Il vero problema: il disaccoppiamento dal modello

Il punto centrale non è scegliere tra MCP e CLI. Il punto centrale è capire quanto la propria applicazione dipenda dal modello AI che sta usando in quel momento.

Oggi molte applicazioni AI nascono in modo molto rapido: si sceglie un modello, si scrive un prompt, si aggiungono alcuni tool e si costruisce un primo flusso funzionante. Questo approccio è efficace per prototipare, ma può diventare fragile quando l'applicazione inizia a gestire processi reali.

Il rischio è che il modello non sia più solo un componente dell'architettura, ma diventi di fatto il runtime dell'applicazione. In altre parole, il comportamento del sistema dipende troppo da come quello specifico modello interpreta istruzioni, tool, contesto e dati.

Questo crea un problema molto concreto. Se domani il provider cambia prezzo, modifica il comportamento del modello, depreca una versione, introduce limiti diversi o semplicemente un altro modello diventa più conveniente, l'applicazione potrebbe non essere pronta a cambiare.

Essere model-agnostic non significa semplicemente poter cambiare una chiave API o sostituire il nome del modello in una variabile di configurazione. Significa progettare l'intero sistema in modo che il modello sia sostituibile senza riscrivere il dominio applicativo.

Questo richiede una separazione netta tra tre livelli:

• il dominio aziendale, cioè processi, dati, regole, autorizzazioni e workflow;
• il layer di capability, cioè il modo in cui queste funzionalità vengono esposte all'AI;
• il layer LLM, cioè l'adapter specifico per OpenAI, Claude, Mistral, Gemini o un modello locale.

Quando questi livelli sono confusi, cambiare modello diventa costoso. Quando invece sono separati, il modello può cambiare senza compromettere la logica di business.

In questo senso MCP non rende automaticamente un'applicazione indipendente dal modello. Sarebbe un errore pensarlo. MCP può aiutare a standardizzare l'accesso alle capability, ma il vero disaccoppiamento nasce dall'architettura complessiva.

Il merito non è del protocollo in sé. Il merito è di un dominio applicativo stabile, di tool ben progettati, di validatori robusti, di policy di sicurezza e di adapter LLM separati dal resto del sistema.

MCP, CLI, REST API e function calling possono essere tutti modi diversi per invocare una capability. Ma se quella capability è mal progettata, troppo dipendente dal prompt o troppo legata a un singolo modello, nessun protocollo risolverà davvero il problema.

La domanda più importante quindi non è:

Stiamo usando MCP?

La domanda più importante è:

Il nostro dominio applicativo può sopravvivere al cambio del modello?

Se la risposta è sì, allora l'architettura è sulla strada giusta. Se la risposta è no, il sistema è ancora troppo dipendente dal modello, indipendentemente dal fatto che usi MCP, una CLI o un'API tradizionale.

Cosa abbiamo imparato costruendo Flowvenue

Quando abbiamo iniziato a progettare Flowvenue, il nostro obiettivo non era costruire un server MCP. Non era nemmeno costruire un framework per agenti AI. Il problema che stavamo cercando di risolvere era molto più concreto: permettere alle persone di interagire con processi aziendali complessi attraverso una conversazione naturale.

Fin dall'inizio era evidente che il modello AI sarebbe cambiato nel tempo. Nessuno può prevedere quale sarà il modello migliore tra sei mesi, un anno o tre anni. La velocità con cui il mercato sta evolvendo rende impossibile prendere decisioni architetturali basate su un singolo vendor.

Per questo motivo abbiamo cercato di evitare un errore molto comune nei progetti AI: costruire la logica applicativa all'interno del modello.

Molti sistemi affidano al prompt una quantità enorme di responsabilità. Il modello deve capire il processo, conoscere le regole di business, validare i dati, applicare autorizzazioni, decidere quali operazioni sono consentite e orchestrare le integrazioni esterne.

Questo approccio può funzionare nelle prime fasi di sviluppo, ma crea una forte dipendenza dal comportamento del modello. Ogni cambio di provider, ogni aggiornamento di versione e ogni differenza di interpretazione rischiano di modificare il comportamento dell'applicazione.

In Flowvenue abbiamo seguito una strada diversa. Abbiamo cercato di spostare il più possibile la logica nel dominio applicativo:

• i processi sono definiti nel database;
• gli step sono definiti nel database;
• le azioni sono definite nel database;
• le regole di validazione sono gestite dal backend;
• i permessi sono gestiti dal backend;
• le integrazioni sono gestite dal backend;
• gli audit e la governance sono gestiti dal backend.

Il ruolo del modello diventa quindi molto più semplice: comprendere l'intenzione dell'utente, scegliere la capability più appropriata e presentare il risultato in modo naturale.

Questa separazione ci ha insegnato una lezione importante: il vero asset non è il modello. Il vero asset è il dominio aziendale.

I processi, le regole, le autorizzazioni, le entità e le integrazioni rappresentano la conoscenza che differenzia un'applicazione da un'altra. Il modello è un componente estremamente importante, ma rimane comunque un componente sostituibile.

Grazie a questa architettura è possibile evolvere il layer AI senza dover riscrivere i processi. Cambiare provider diventa principalmente un problema di adapter e compatibilità del tool calling, non una riscrittura completa del sistema.

Questo non significa che il passaggio da OpenAI a Claude, da Claude a Mistral o da un provider cloud a un modello locale sia gratuito. Ogni modello ha peculiarità diverse, capacità diverse e modalità differenti di utilizzare gli strumenti.

Significa però che il cuore dell'applicazione rimane stabile. Le capability continuano a esistere. I processi continuano a esistere. Le regole continuano a esistere. Il dominio continua a esistere.

Col passare del tempo abbiamo capito che questa era probabilmente la decisione architetturale più importante presa nel progetto. Non perché ci abbia permesso di adottare un protocollo specifico, ma perché ci ha permesso di evitare che il dominio aziendale venisse assorbito dal modello.

In un settore che evolve alla velocità dell'intelligenza artificiale, questa separazione potrebbe rivelarsi molto più importante di qualsiasi scelta tecnologica specifica fatta oggi.

Da Tool a Capability: il salto che molti sottovalutano

Una delle lezioni più interessanti emerse negli ultimi anni riguarda la differenza tra un semplice tool e una vera capability aziendale.

Molte discussioni sull'AI agentica tendono a trattare questi due concetti come sinonimi. In realtà rappresentano livelli di astrazione profondamente diversi.

Un tool è generalmente un'operazione tecnica ben definita. Ha un input, produce un output e svolge una funzione specifica.

Alcuni esempi tipici sono:

git commit
docker deploy
send_email
create_calendar_event
query_database

Questi strumenti sono fondamentali e costituiscono i mattoni elementari di qualsiasi sistema moderno. Tuttavia raramente rappresentano il linguaggio con cui un'azienda descrive il proprio lavoro.

Un responsabile commerciale non pensa in termini di query SQL. Un responsabile amministrativo non pensa in termini di chiamate API. Un responsabile HR non pensa in termini di script bash.

Le organizzazioni ragionano in termini di processi, decisioni e obiettivi.

Ad esempio:

Apri una nuova opportunità commerciale
Approva una nota spese
Pubblica un processo
Genera il report delle performance trimestrali
Calcola il budget residuo
Avanza una pratica alla fase successiva

Ognuna di queste operazioni può coinvolgere decine di sistemi diversi, numerose validazioni, controlli autorizzativi, aggiornamenti di stato, notifiche e regole di business.

Dal punto di vista dell'utente, però, tutto questo rimane una singola capability.

Questo passaggio è fondamentale perché modifica completamente il ruolo dell'intelligenza artificiale all'interno dell'applicazione.

Se il modello deve orchestrare direttamente decine di tool elementari, aumenta il rischio di errore, cresce la complessità dei prompt e diventa più difficile garantire coerenza operativa.

Se invece il modello può lavorare a livello di capability, il sistema diventa più robusto. L'AI ragiona in termini di obiettivi aziendali mentre il backend si occupa della complessità tecnica necessaria per raggiungerli.

Questo principio è molto simile a ciò che è accaduto nell'evoluzione del software tradizionale.

I primi programmi interagivano direttamente con risorse di basso livello. Con il tempo sono emersi framework, librerie e servizi che hanno nascosto la complessità sottostante dietro astrazioni sempre più vicine al dominio di business.

Oggi stiamo osservando un fenomeno analogo nel mondo dell'AI.

La vera sfida non è dare al modello accesso a più strumenti possibile. La vera sfida è costruire capability sufficientemente ricche da rappresentare concetti aziendali significativi e sufficientemente stabili da rimanere valide indipendentemente dal modello utilizzato.

Da questo punto di vista, il numero di tool disponibili è spesso una metrica poco utile. Un sistema con cento tool elementari potrebbe essere molto più difficile da utilizzare rispetto a un sistema con dieci capability ben progettate.

L'obiettivo non dovrebbe essere esporre ogni singola funzione interna dell'applicazione all'AI. L'obiettivo dovrebbe essere esporre le capability che rappresentano realmente il linguaggio operativo dell'organizzazione.

Quando questo accade, il modello smette di comportarsi come un semplice orchestratore di API e inizia a operare a un livello molto più vicino al modo in cui le persone descrivono il proprio lavoro quotidiano.

Da Tool a Capability: il salto che molti sottovalutano

Una delle lezioni più interessanti emerse negli ultimi anni riguarda la differenza tra un semplice tool e una vera capability aziendale.

Molte discussioni sull'AI agentica tendono a trattare questi due concetti come sinonimi. In realtà rappresentano livelli di astrazione profondamente diversi.

Un tool è generalmente un'operazione tecnica ben definita. Ha un input, produce un output e svolge una funzione specifica.

Alcuni esempi tipici sono:

git commit
docker deploy
send_email
create_calendar_event
query_database

Questi strumenti sono fondamentali e costituiscono i mattoni elementari di qualsiasi sistema moderno. Tuttavia raramente rappresentano il linguaggio con cui un'azienda descrive il proprio lavoro.

Un responsabile commerciale non pensa in termini di query SQL. Un responsabile amministrativo non pensa in termini di chiamate API. Un responsabile HR non pensa in termini di script bash.

Le organizzazioni ragionano in termini di processi, decisioni e obiettivi.

Ad esempio:

Apri una nuova opportunità commerciale
Approva una nota spese
Pubblica un processo
Genera il report delle performance trimestrali
Calcola il budget residuo
Avanza una pratica alla fase successiva

Ognuna di queste operazioni può coinvolgere decine di sistemi diversi, numerose validazioni, controlli autorizzativi, aggiornamenti di stato, notifiche e regole di business.

Dal punto di vista dell'utente, però, tutto questo rimane una singola capability.

Questo passaggio è fondamentale perché modifica completamente il ruolo dell'intelligenza artificiale all'interno dell'applicazione.

Se il modello deve orchestrare direttamente decine di tool elementari, aumenta il rischio di errore, cresce la complessità dei prompt e diventa più difficile garantire coerenza operativa.

Se invece il modello può lavorare a livello di capability, il sistema diventa più robusto. L'AI ragiona in termini di obiettivi aziendali mentre il backend si occupa della complessità tecnica necessaria per raggiungerli.

Questo principio è molto simile a ciò che è accaduto nell'evoluzione del software tradizionale.

I primi programmi interagivano direttamente con risorse di basso livello. Con il tempo sono emersi framework, librerie e servizi che hanno nascosto la complessità sottostante dietro astrazioni sempre più vicine al dominio di business.

Oggi stiamo osservando un fenomeno analogo nel mondo dell'AI.

La vera sfida non è dare al modello accesso a più strumenti possibile. La vera sfida è costruire capability sufficientemente ricche da rappresentare concetti aziendali significativi e sufficientemente stabili da rimanere valide indipendentemente dal modello utilizzato.

Da questo punto di vista, il numero di tool disponibili è spesso una metrica poco utile. Un sistema con cento tool elementari potrebbe essere molto più difficile da utilizzare rispetto a un sistema con dieci capability ben progettate.

L'obiettivo non dovrebbe essere esporre ogni singola funzione interna dell'applicazione all'AI. L'obiettivo dovrebbe essere esporre le capability che rappresentano realmente il linguaggio operativo dell'organizzazione.

Quando questo accade, il modello smette di comportarsi come un semplice orchestratore di API e inizia a operare a un livello molto più vicino al modo in cui le persone descrivono il proprio lavoro quotidiano.

Cosa può essere sostituito e cosa no

Uno degli errori più comuni nelle discussioni tecnologiche consiste nel trattare ogni scelta architetturale come una decisione assoluta. In realtà quasi tutte le tecnologie moderne presentano ampie zone di sovrapposizione.

Anche nel caso di MCP, CLI, REST API e function calling esistono numerosi scenari in cui strumenti diversi possono produrre risultati molto simili.

Comprendere dove esiste una reale equivalenza e dove invece emergono differenze sostanziali è fondamentale per evitare valutazioni superficiali.

Quando una CLI è perfettamente sufficiente

Esistono moltissimi casi in cui una CLI rappresenta probabilmente la soluzione migliore.

Ad esempio:

• deployment infrastrutturali;
• amministrazione di sistemi;
• automazione batch;
• pipeline CI/CD;
• manutenzione operativa;
• esecuzione di task altamente deterministici.

In questi contesti il problema principale è eseguire operazioni tecniche in modo affidabile, prevedibile ed efficiente. Una CLI offre già tutto ciò che serve: comandi chiari, documentazione consolidata e un comportamento generalmente stabile nel tempo.

Se un agente AI deve semplicemente orchestrare questi strumenti, introdurre un ulteriore protocollo potrebbe non generare benefici proporzionati alla complessità aggiuntiva.

Quando una REST API è più naturale

Esistono anche situazioni in cui un'API tradizionale rappresenta l'interfaccia più appropriata.

Le classiche operazioni CRUD sono un esempio perfetto:

• creare un cliente;
• modificare un ordine;
• recuperare una fattura;
• elencare prodotti;
• aggiornare un'anagrafica.

Le API REST sono mature, ampiamente supportate e comprese da qualsiasi stack tecnologico. In moltissimi sistemi continueranno a rappresentare il principale meccanismo di integrazione per molti anni.

Quando il function calling interno è sufficiente

Se l'applicazione utilizza un singolo provider AI e non ha esigenze di interoperabilità esterna, anche il function calling nativo può essere una soluzione adeguata.

Molti prodotti oggi funzionano perfettamente utilizzando esclusivamente gli strumenti messi a disposizione dal provider scelto.

In questi casi introdurre un protocollo aggiuntivo potrebbe non essere necessario.

Dove iniziano a emergere le differenze

Le differenze diventano più evidenti quando l'obiettivo non è semplicemente eseguire un'operazione, ma costruire un ecosistema di capability accessibili da modelli e client differenti.

Immaginiamo una piattaforma che deve essere utilizzata da:

• Claude Desktop;
• OpenAI;
• Gemini;
• modelli locali;
• framework agentici differenti;
• client sviluppati da terze parti.

In questo scenario la sfida non è più l'invocazione della capability. La vera sfida diventa la standardizzazione della scoperta, della descrizione e dell'utilizzo delle capability stesse.

È qui che protocolli come MCP iniziano a mostrare il proprio valore. Non perché consentano di fare qualcosa di impossibile con altri strumenti, ma perché riducono il costo di integrazione tra attori diversi dell'ecosistema.

La capability è il vero asset

Alla fine, ciò che emerge da questa analisi è che il protocollo è raramente la componente più importante del sistema.

Il vero asset rimane sempre la capability.

Una capability ben progettata mantiene il proprio valore indipendentemente dal modo in cui viene esposta. Può essere consumata tramite API, CLI, MCP o qualsiasi altro meccanismo che emergerà nei prossimi anni.

Al contrario, una capability mal progettata continuerà a essere problematica indipendentemente dal protocollo utilizzato.

Per questo motivo le organizzazioni dovrebbero investire meno tempo nel dibattito tra tecnologie specifiche e più tempo nella progettazione di capability aziendali robuste, sicure, riutilizzabili e indipendenti dal modello.

Una volta costruito correttamente questo livello, la scelta del protocollo diventa un problema molto più semplice da affrontare.

Dove sta andando il mercato

Osservare il dibattito attuale tra MCP, CLI, agenti, modelli open-weight e modelli proprietari può dare l'impressione di trovarsi di fronte a una competizione tra tecnologie. In realtà ciò che sta accadendo è molto più simile a una fase di maturazione dell'intero settore.

Negli ultimi anni gran parte dell'attenzione si è concentrata sui modelli. Ogni nuova generazione di LLM ha portato miglioramenti significativi nelle capacità di ragionamento, comprensione e generazione del linguaggio naturale. Questo ha spinto molte organizzazioni a considerare il modello come l'elemento centrale della propria strategia AI.

Tuttavia, man mano che il mercato evolve, sta emergendo una realtà sempre più evidente: il modello è una componente fondamentale, ma raramente rappresenta il vero vantaggio competitivo di un'azienda.

Le aziende non costruiscono valore perché utilizzano un determinato LLM. Costruiscono valore perché possiedono dati, processi, competenze, regole operative e capacità distintive che altri non hanno.

Questo sta portando a un cambiamento di prospettiva.

Invece di chiedersi quale sia il modello migliore oggi, sempre più organizzazioni stanno iniziando a chiedersi come evitare di dipendere da un singolo modello domani.

L'ascesa dei modelli open-weight

Un fattore che sta accelerando questa trasformazione è la crescita dell'ecosistema open-weight.

Modelli come Mistral, Llama, Qwen e molte altre alternative stanno riducendo progressivamente il divario rispetto ai modelli proprietari. In alcuni contesti specifici riescono già a offrire prestazioni sufficienti per supportare applicazioni aziendali reali.

Questo non significa necessariamente che sostituiranno completamente i grandi provider cloud. Significa però che le organizzazioni avranno sempre più opzioni tra cui scegliere.

Quando il numero di opzioni aumenta, il valore dell'indipendenza architetturale cresce di conseguenza.

AI pubblica e AI privata convivranno

Per molti anni si è discusso dell'AI privata come possibile alternativa all'AI pubblica. Oggi appare sempre più probabile che il futuro sarà caratterizzato dalla coesistenza di entrambe.

I modelli pubblici continueranno a eccellere in termini di innovazione, qualità generale e velocità di evoluzione. Allo stesso tempo, i modelli privati e open-weight offriranno vantaggi importanti in termini di controllo, personalizzazione, governance e prevedibilità dei costi.

Alcune organizzazioni utilizzeranno modelli cloud per attività generali e modelli locali per processi critici. Altre adotteranno architetture ibride in cui il modello viene selezionato dinamicamente in base al tipo di attività da svolgere.

In tutti questi scenari emerge una necessità comune: mantenere stabile il dominio applicativo indipendentemente dal modello utilizzato.

Il nuovo Application Layer dell'AI

Se osserviamo l'evoluzione storica del software, emerge un pattern ricorrente.

Le tecnologie infrastrutturali cambiano rapidamente. I linguaggi di programmazione si evolvono. I database si trasformano. I framework nascono e scompaiono.

Ciò che tende a sopravvivere più a lungo è il livello applicativo che rappresenta il dominio aziendale.

Nel mondo dell'AI sta emergendo un fenomeno simile.

I modelli continueranno a migliorare. I protocolli continueranno a evolvere. Gli agent framework continueranno a moltiplicarsi. Ma le capability aziendali rimarranno il vero punto di contatto tra il business e la tecnologia.

È possibile immaginare un futuro in cui un'organizzazione possiede migliaia di capability esposte attraverso un layer applicativo stabile, mentre i modelli sottostanti vengono sostituiti, aggiornati o specializzati nel corso del tempo.

In questo scenario il valore non risiede più nell'LLM. Il valore risiede nella rappresentazione digitale del dominio aziendale.

Il futuro non sarà deciso da MCP o dalla CLI

Questo ci porta a una conclusione importante.

È improbabile che il futuro dell'AI venga deciso da una competizione tra MCP, CLI, REST API o qualsiasi altro protocollo specifico.

Questi strumenti continueranno a esistere e probabilmente coesisteranno per molto tempo, ciascuno nei contesti in cui offre il miglior rapporto tra semplicità e valore.

La vera trasformazione sarà un'altra: la progressiva separazione tra il dominio applicativo e il modello che lo utilizza.

Le organizzazioni che riusciranno a costruire capability indipendenti dal vendor, dal framework e dal modello avranno una flessibilità molto superiore rispetto a quelle che avranno incorporato la propria logica di business direttamente nei prompt o nelle peculiarità di una singola piattaforma AI.

In altre parole, il mercato si sta muovendo verso un mondo in cui i modelli diventano sostituibili, mentre le capability aziendali diventano sempre più strategiche.

E probabilmente sarà proprio questo il principale fattore di differenziazione delle applicazioni AI nei prossimi anni.

Conclusioni

Se c'è una lezione che emerge da tutto questo dibattito è che molte discussioni tecnologiche tendono a concentrarsi sugli strumenti invece che sui problemi che quegli strumenti stanno cercando di risolvere.

MCP e CLI ne sono un esempio perfetto.

Una CLI è uno strumento straordinario per automatizzare sistemi, orchestrare infrastrutture ed eseguire operazioni deterministiche. Continuerà a essere una componente fondamentale dell'ecosistema software moderno.

MCP rappresenta invece un tentativo di standardizzare il dialogo tra modelli AI e capability applicative. Non sostituisce le CLI, non sostituisce le API e non elimina la necessità di progettare correttamente il dominio aziendale.

In molti casi una CLI può ottenere risultati equivalenti. In altri casi un'API REST è probabilmente la soluzione più naturale. In altri ancora un protocollo come MCP può semplificare l'interoperabilità tra modelli, agenti e applicazioni differenti.

Ridurre il dibattito a una scelta tra tecnologie rischia però di nascondere il vero tema strategico.

Il problema più importante che le organizzazioni dovranno affrontare nei prossimi anni non sarà scegliere il protocollo corretto. Sarà evitare che la propria conoscenza aziendale diventi dipendente da uno specifico modello AI.

I modelli continueranno a cambiare. I prezzi continueranno a cambiare. Nuovi provider entreranno nel mercato. Modelli open-weight sempre più competitivi renderanno possibili scenari oggi impensabili. Alcune organizzazioni adotteranno modelli locali, altre utilizzeranno infrastrutture cloud, molte sceglieranno approcci ibridi.

In questo contesto il vero patrimonio di un'azienda non sarà il modello utilizzato, ma il modo in cui processi, regole, dati e capability saranno stati rappresentati e resi accessibili all'intelligenza artificiale.

Le organizzazioni che riusciranno a separare il dominio applicativo dal modello avranno la libertà di evolvere nel tempo senza dover ricostruire continuamente le proprie applicazioni.

Quelle che invece incorporeranno la logica di business direttamente nei prompt, nelle peculiarità di un singolo vendor o nelle caratteristiche di una specifica generazione di modelli rischieranno di accumulare una nuova forma di debito tecnologico.

Per questo motivo la domanda più importante non è:

"Dovrei usare MCP o una CLI?"

La domanda più importante è:

"Come posso costruire capability aziendali che rimangano utilizzabili indipendentemente dal modello che userò domani?"

Probabilmente è proprio lì che si giocherà la prossima grande evoluzione del software enterprise basato sull'intelligenza artificiale.