Un esempio concreto arriva da Salesforce: invece di presentare migliaia di operazioni direttamente al modello, Headless 360 usa Discover, Describe e due modalità di Dispatch. Salesforce spiega che l’obiettivo è evitare di consumare inutilmente contesto, token e tempo nella ricerca del tool corretto (Salesforce Developers Blog).
MCP sta diventando uno dei mattoni più importanti dell’AI applicata al software enterprise. Ma c’è un equivoco da evitare: collegare un LLM a molti tool non equivale a costruire un agente affidabile.
MCP risolve una parte fondamentale del problema: offre un modo comune per descrivere, scoprire e invocare capability. Non decide però quali operazioni siano sicure, quale stato sia valido, cosa fare dopo un errore o quando sia necessaria un’approvazione umana.
Il protocollo è l’inizio, non l’architettura
Un modello è probabilistico. Un processo aziendale, invece, contiene numerosi elementi che devono rimanere deterministici: permessi, transizioni di stato, vincoli, versioni, approvazioni e operazioni irreversibili.
Per questo l’architettura enterprise non può ridursi a LLM → tool call.
Serve un livello intermedio capace di trasformare il reasoning del modello in azioni governate. È qui che entra in gioco l’harness.
Cosa deve fare un buon harness
Un harness enterprise dovrebbe almeno sapere quali capability rendere disponibili, verificare l’identità e i permessi, validare gli input, controllare lo stato persistente, distinguere letture e mutazioni, applicare approval gate dove necessario, registrare ciò che è accaduto e recuperare da un fallimento senza duplicare azioni già completate.
Questa infrastruttura non rende il modello meno importante. Gli permette di concentrarsi su ciò che sa fare meglio: comprendere intenzioni, interpretare contesto, scegliere strategie e comporre capability.
Più autonomia richiede più determinismo
Può sembrare un paradosso: più autonomo diventa l’agente, più robusti devono essere i confini deterministici che lo circondano.
Se un agente legge informazioni, un errore può essere relativamente innocuo. Se modifica un processo, emette un documento o cambia uno stato operativo, diventa essenziale sapere con certezza cosa sia già successo.
La domanda quindi non è soltanto “il modello sa fare questa cosa?”, ma “il sistema può garantire che venga fatta entro le regole previste e che sappia recuperare se qualcosa va storto?”.
Human-in-the-loop come parte del processo
Mettere un pulsante “Conferma” davanti a ogni tool call non è governance: è attrito.
Un buon harness distingue rischio e reversibilità. Alcune operazioni possono essere automatiche entro policy definite; altre richiedono un gate umano. L’approvazione deve essere una proprietà del processo e non una soluzione generica all’incertezza del modello.
Dall’orchestrazione alla costruzione del software
Per capire il passaggio architetturale a monte, vedi anche Cos’è davvero Headless 360 e perché cambia il software enterprise.
Questo tema diventa ancora più importante quando l’AI non si limita a usare software esistente ma può costruire o modificare processi persistenti.
Ne parliamo nel pillar Dopo Headless 360: se l’AI sostituisce l’interfaccia, cosa succede al software enterprise?: il passaggio da applicazioni a capability apre naturalmente la domanda su come quelle capability e quei processi vengano creati.
Il vantaggio competitivo si sposta
I modelli continueranno a migliorare e, in molti casi, saranno intercambiabili. Una parte crescente del vantaggio competitivo si sposterà quindi su ciò che sta intorno al modello.
Discovery, policy, stato, audit, versioning, approval e recoverability non sono dettagli di implementazione. Sono ciò che trasforma una demo di agentic AI in infrastruttura utilizzabile da un’azienda.
Quando l’output non è una singola azione ma un processo persistente, il tema diventa ancora più evidente: Business Vibe Coding: quando l’AI costruisce processi, non codice.
MCP può diventare il linguaggio comune. Ma è l’harness a decidere se quel linguaggio produce semplicemente tool call o lavoro realmente completato.
Domande frequenti
No. MCP standardizza l’accesso a strumenti e capability, ma affidabilità, autorizzazioni, validazione, stato e recupero dagli errori dipendono dall’architettura che circonda il modello.
È l’insieme di runtime, regole, controlli, stato, autorizzazioni e meccanismi di esecuzione che delimitano e governano ciò che un modello può fare.
Perché un agente può fallire dopo aver già completato alcune operazioni. Il sistema deve conoscere lo stato persistente e consentire di riprendere senza duplicare o corrompere il lavoro.