Chi bussa a chi
Questa guida l'ha scritta Federico Vitiello, che fa lavorare gli agenti ogni giorno e lo insegna nei suoi corsi. Io sono Chiara, una voce sintetica, e te la racconto. Un agente da solo non fa niente. Per lavorare deve parlare con gli strumenti che usi ogni giorno, il calendario, il sito, il programma che incassa i pagamenti. E per parlarci ha sei porte. La tesi sta in una frase. Prendi la porta più economica che copre il lavoro. In cinque porte è l'agente che bussa, e sono la CLI, l'API, MCP, il browser e lo schermo. Nella sesta bussa lo strumento, e si chiama webhook. Succede qualcosa dall'altra parte, e lui ti avvisa. Le cinque in cui bussa l'agente si dividono in due famiglie. Le porte da macchina, cioè CLI, API e MCP, parlano il linguaggio dello strumento. Costano poco, sbagliano poco, e fanno solo quello che lo strumento ha previsto. Le porte da persona, il browser e lo schermo, usano l'interfaccia fatta per te. Arrivano quasi ovunque, e pagano ogni passo in token, in tempo e in errori. I token sono i pezzi, di testo o d'immagine, con cui si misura il lavoro dell'intelligenza artificiale. Se paghi a consumo diventano euro, se hai un abbonamento sono il limite che finisce prima. Adesso le prendiamo una per una.
La CLI
CLI sta per Command Line Interface. È un programma senza finestre e senza bottoni, che si comanda scrivendo nel terminale, la finestra dove si danno i comandi al computer. Se usi Claude Code ne hai già una davanti, perché Claude Code è una CLI, e anche la sua app è un terminale abbellito. La porta di cui parliamo qui però è un'altra. Sono le CLI degli altri strumenti, quelle che il tuo agente apre per parlare con loro. Fra le porte in cui bussa l'agente è la più economica. Scrive una riga, legge una riga, ha finito. Un comando e la sua risposta stanno in una sessantina di token, cioè due righe di testo. Quasi sempre la CLI è un vestito comodo sopra l'API dello stesso servizio, con la documentazione dentro, e all'agente basta chiedere l'aiuto del comando per sapere tutto. Federico genera immagini e video con Higgsfield, che ha il suo sito, la sua API e anche un connettore, ma lui lo usa solo dalla CLI. Il punto debole è che esiste solo se chi fa il servizio l'ha scritta, e che va installata e autenticata su ogni computer, e i login scadono.
L'API
API sta per Application Programming Interface, ed è lo sportello che quasi ogni servizio tiene aperto per i programmi. Chiedi in una forma precisa, con una chiave che dice chi sei, e ti torna una risposta in una forma precisa. È la porta vera dietro quasi tutte le altre, perché le CLI e le prese MCP chiamano un'API. Il sito di Alleniamo Imprese ne usa parecchie, per esempio queste quattro. Le email partono con l'API di Resend, i video salgono con quella di Bunny, i messaggi che gli atleti dettano a voce li trascrive quella di ElevenLabs, e l'avviso che arriva a Federico quando qualcuno chiede di entrare in un corso è una chiamata sola all'API di Telegram. La chiave sta in un file del tuo computer che puoi aprire solo tu, e in chat non passa mai. Una chiave finita dentro una conversazione è bruciata. Il punto debole è che fai solo quello che il servizio ha deciso di aprire, e che la forma della risposta può cambiare senza avviso. Il due settembre Federico ha scoperto che Stripe, il servizio con cui incassa, aveva spostato il campo dello sconto, e la pagina di pagamento cadeva appena qualcuno usava un codice.
MCP
MCP sta per Model Context Protocol, ed è uno standard, cioè un accordo su come ci si parla. Un server MCP è il programma che fa da presa per un servizio. Espone un elenco di comandi, ognuno col suo nome, la sua descrizione e i suoi parametri, e qualunque agente che parla MCP quell'elenco se lo legge e chiama i comandi da solo. In Claude questi server si chiamano connettori, e li fa girare chi li offre. Non devi insegnargli niente, e l'autenticazione si fa una volta. MCP non è il contrario dell'API. Spesso è una presa messa davanti a lei, e dietro ci può essere anche un browser pilotato, un database, Telegram. Se dietro c'è un browser, le pagine che ti riporta le paghi come col browser. Nella scala passa davanti all'API per una ragione sola. Con un connettore ufficiale non leggi la documentazione. Il prezzo è l'elenco dei comandi, e quanto lo paghi dipende dal tuo agente. Claude Code oggi, quando apri una conversazione, legge solo i nomi, e la descrizione di un comando la va a cercare quando gli serve. Altri agenti leggono tutte le descrizioni appena apri, anche quelle che oggi non userai, e allora ogni presa in più si paga a ogni conversazione. Davanti alla pagina, sposta il cursore dello schema e guarda la differenza fra le due barre. Il guardiano del corso, un agente che lavora per Federico, usa questa porta. Ogni mezz'ora invita alle dirette chi ha pagato, e lo fa con il connettore di Google Calendar, che è un server MCP.
Il webhook
Fino a qui la prima mossa l'ha sempre fatta l'agente. Il webhook è il contrario. Dai allo strumento un indirizzo web tuo, e quando dall'altra parte succede qualcosa, un pagamento, un'email che arriva, è lui a bussare lì. L'alternativa si chiama giro di controllo. Passi a guardare ogni tanto se c'è qualcosa di nuovo, e quel giro lo paghi anche tutte le volte in cui non c'è niente. Davanti alla pagina, puoi provarli tutti e due e vedere quanto aspetti. Il webhook non passa dall'intelligenza artificiale. È un pezzo di codice che riceve e agisce, scritto una volta, quindi arriva subito e costa zero token a evento. Nel lavoro di Federico, il webhook di Stripe è il grilletto di tutto quello che succede quando qualcuno compra. Salva il pagamento, manda l'email giusta, avvisa Federico. Se la risposta è un errore, Stripe ritenta per giorni, quindi ogni evento ha il suo numero unico e alla seconda consegna non si scrive a nessuno. Il prezzo è un server sempre acceso. E c'è la firma, una sigla che prova che a bussare è davvero Stripe. Va verificata, o suona chiunque.
Il browser
Quando uno strumento non ha né CLI né API né MCP, oppure le ha ma non arrivano dove ti serve, resta l'interfaccia fatta per le persone. Con l'estensione del browser l'agente apre le pagine nel tuo Chrome, coi siti in cui sei già entrato. Niente chiavi da creare, niente documentazione da leggere. Vede quello che vedresti tu. Poi però comincia un ciclo, e il ciclo è il costo. Legge la pagina, decide, clicca o scrive, la pagina cambia, e la rilegge. Una schermata di Google Ads letta per intero pesa quanto un capitolo di libro, e lui la rilegge a ogni passo. Federico crea e modifica le campagne su Meta e Google Ads proprio così, con l'estensione del browser. L'agente prepara e non pubblica. Federico rilegge, controlla e pubblica, e ci risparmia ore ogni giorno. Su Google Ads un'altra strada non c'è, perché il connettore ufficiale legge e non scrive, e l'API non fa tutto quello che Federico fa nell'interfaccia. Su Meta invece ad aprile sono nati una CLI e un connettore ufficiali, ancora in beta, ed è il corollario della scala. La porta buona nel frattempo è nata, ed è ora di ricontrollare. Il browser va sorvegliato. Su una campagna pubblicitaria un click sbagliato non è un refuso, sono soldi.
Lo schermo
L'ultima porta, e la più bruta. Qui l'agente non entra nel browser. Guarda una foto di tutto lo schermo, decide dove cliccare in coordinate, clicca, e riguarda per vedere com'è andata. Così arriva dove il browser non arriva, a un programma installato sul computer, a una finestra di sistema, alla finestrella con cui si sceglie un file. La libertà è massima, perché tutto quello che vedi tu lo vede lui. Ma ogni passo è una foto, e una foto pesa. Uno screenshot normale costa circa milletrecento token, più il ragionamento, e i passi raddoppiano, perché dopo ogni azione riguarda per verificare. È la più cara, la più lenta e la più fragile. Dieci pixel fuori, e il click va da un'altra parte. E intanto il mouse è suo, quindi finché lavora il computer non lo usi tu. Nel lavoro di Federico non c'è nessun compito quotidiano che passi da qui. È il ripiego del ripiego, la porta che si apre quando le altre cinque sono chiuse.
WordPress
Le porte non si escludono, e non si sceglie una volta per tutte. Si sceglie lavoro per lavoro. Linus è una skill, cioè le istruzioni scritte che l'agente segue per un lavoro, e Federico ci costruisce e migra i siti. Su un sito WordPress usa quattro porte. Il terminale del server su cui il sito vive, che si chiama SSH, lo sportello dell'API, la presa MCP e il browser. La regola che ha scritta dentro è parente di quella di questa guida. Fra le porte che coprono il lavoro si usa quella che si automatizza meglio, che di solito è anche quella che costa meno, e una porta si dichiara buona solo dopo una prova in sola lettura riuscita. Davanti alla pagina, prova a toccare i lavori nello schema. Per leggere com'è fatto il sito vince il terminale, perché un comando risponde con l'elenco intero. Per caricare duecento foto vince l'API, perché il caricatore delle immagini, oltre il centinaio, fallisce in silenzio. Per un pannello senza API vince il browser. E a volte si mescolano. Per cambiare un testo dentro una pagina pesante, Linus lavora dentro il browser ma da lì chiama l'API, così la pagina nel contesto non entra mai.
Il conto
Due cose che da fuori non si vedono. La prima è che i token si sommano, passo dopo passo, e una porta da persona paga ogni passo decine di volte più di una porta da macchina. Con le ipotesi del grafico, che sono ordini di grandezza e non misure, lo stesso compito da otto passi dal terminale costa milleduecento token, e dal browser quarantamila. La seconda è che gli errori si moltiplicano. Se ogni passo ha il cinque per cento di probabilità di andare storto, su venti passi la probabilità che almeno uno vada storto è del sessantaquattro per cento. Non è un po' più rischioso. Due volte su tre qualcosa va storto, e per questo un lavoro lungo dentro una porta fragile si spezza in pezzi corti e si sorveglia. Davanti alla pagina, sposta il cursore dei passi e guarda se le porte da persona scendono sotto quelle da macchina. Non succede, ed è esattamente quello il punto. Il webhook qui non c'è, perché non passa dall'intelligenza artificiale. Se sbaglia, è perché è sbagliato il codice.
La scala
Come si sceglie, in dieci secondi. Prima domanda. Chi fa la prima mossa? Se l'evento nasce dall'altra parte è webhook, e non c'è altro da discutere. Se la mossa la fai tu, scendi la scala. La CLI se c'è. Se no MCP, quando lo strumento ha un connettore ufficiale. Costa qualche token più dell'API, e le passa davanti per una ragione sola. Non leggi documentazione. È l'unica eccezione alla regola. Se no l'API. Se no il browser. Se no lo schermo. Poi c'è il corollario. A volte prendi quello che lo strumento ti dà. Sarebbe meglio la CLI, c'è solo l'API, ti adatti. Non c'è nemmeno l'API e c'è solo il sito, allora browser, sapendo cosa stai pagando. E ogni tanto torni a controllare, perché gli strumenti cambiano e la porta buona magari nel frattempo è nata. Ogni porta si paga in tre monete. Quanta libertà ti dà, quanti token ti costa, quanti errori ti fa. Davanti alla pagina, spunta quello che il tuo strumento offre, o prendi uno degli esempi, e guarda quale gradino si accende.
La regola
La regola, per intero, sta in una riga. La porta più economica che copre il lavoro. E il corollario conta quanto la regola. A volte prendi quello che lo strumento ti dà, e allora usi la porta cara sapendo cosa paghi. L'esercizio sono venti minuti, e si fa oggi. Prendi tre strumenti che usi ogni giorno, quelli veri, il gestionale, il calendario, il programma con cui mandi le email. Per ognuno chiedi al tuo agente quali porte offre. Poi scegli la più economica che copre il lavoro, e se ti tocca una porta cara scriviti in una riga perché. È quella riga che fra tre mesi ti fa ricontrollare se nel frattempo è uscita la CLI. Nell'ultima slide trovi la frase da incollare al tuo agente, prima di farlo lavorare su uno strumento nuovo. E se vuoi la risposta sul tuo caso, in fondo alla pagina puoi mandare a Federico i tuoi tre strumenti, e ti risponde lui, gratis. Una porta cara non è una sconfitta. È una scelta, e adesso sai di averla fatta.
