Fonte originale: Waterdrop Capital

Riassunto

I grandi modelli stanno evolvendo da strumenti che rispondono a domande in agenti intelligenti capaci di pianificare, invocare strumenti e fornire risultati. Nel frattempo, i regolamenti in stablecoin, i protocolli di pagamento nativi HTTP (HTTP 402) e i portafogli intelligenti stanno cominciando a integrarsi in un’infrastruttura di pagamento progettata per le macchine. Un programma può ricevere una quotazione in tempo reale, firmare un’autorizzazione e completare un micropagamento: qualcosa che fino a pochi anni fa era solo un concetto, ma che ora è un percorso tecnologico praticabile.

Tuttavia, «le macchine possono pagare» non equivale a «le macchine possono completare transazioni». Quando un agente intelligente deve acquistare servizi come ricerca, dati, potenza computazionale, generazione di contenuti o analisi professionale, incontra ancora sfide quali la scoperta di endpoint, il confronto tra quotazioni, i pagamenti cross-protocollo, il controllo dei budget, la verifica della consegna e la riconciliazione unificata. Le infrastrutture di pagamento risolvono come si muove il valore, ma non risolvono automaticamente come la domanda trovi l’offerta né se il servizio corretto sia stato effettivamente ricevuto dopo il pagamento.

Ciò significa che nella prossima fase dei pagamenti per agenti, il focus competitivo potrebbe non essere più esclusivamente sulla throughput del protocollo, sulla velocità di regolamento o sul numero di blockchain supportate, bensì sulla capacità di costruire una vera infrastruttura per acquirenti macchina. Questo articolo cerca di spiegare perché i pagamenti per agenti diventeranno un percorso autonomo—partendo dalla struttura della domanda, dall’evoluzione dei protocolli, dai collo di bottiglia reali e dalla divisione del lavoro di mercato—e quali collegamenti fondamentali mancano ancora per un’adozione su larga scala.

Introduzione: gli agenti intelligenti stanno acquisendo un «budget discrezionale» limitato

Negli ultimi due anni, le capacità degli agenti intelligenti sono migliorate rapidamente. Inizialmente i grandi modelli gestivano principalmente la generazione di informazioni: gli utenti ponevano domande e i modelli producevano testo. Successivamente, l’invocazione di strumenti ha permesso ai modelli di cercare pagine web, interrogare database, eseguire codice e operare software. Un ulteriore passo avanti ha visto gli agenti intelligenti suddividere obiettivi, formulare piani e adattare le azioni in base ai risultati esterni su più cicli di esecuzione.

Quando gli obiettivi di esecuzione erano limitati a strumenti gratuiti o sistemi aziendali interni, i permessi di invocazione potevano essere preconfigurati dagli sviluppatori. Ma le capacità di alta qualità offerte nei mercati aperti richiedono generalmente un pagamento: i dati finanziari in tempo reale hanno un costo per chiamata, lo scraping web consuma crediti, la potenza computazionale per inferenze e GPU è fatturata in base all’uso, e la generazione video e i database professionali hanno prezzi chiari. Perché un agente intelligente completi autonomamente un compito, deve inevitabilmente diventare un acquirente in tempo reale.

Il tradizionale modello commerciale API non è stato progettato per questo tipo di acquirente. Richiede che una persona visiti prima un sito web, registri un account, colleghi una carta bancaria, scelga un piano, protegga una chiave API e poi inserisca tale chiave nell’ambiente del programma. Le decisioni di acquisto e le invocazioni effettive sono separate in due momenti distinti: l’utente umano completa l’acquisto prima che il compito abbia inizio, mentre il software si occupa soltanto del consumo della quota già acquistata.

Un agente potrebbe non sapere di cosa ha bisogno finché non raggiunge un certo passo nell’esecuzione di un compito. Non può prevedere in anticipo quale fonte dati dovrà chiamare, né dovrebbe richiedere all’utente di aprire un account per ogni possibile servizio. La sua procedura di approvvigionamento è istantanea, di basso valore, multi-fornitore, ad alta frequenza e orientata al risultato. Per esso, l’esperienza più naturale non è «sottoscrivi prima, poi chiama», ma «scopri il servizio, ottieni una quotazione, autorizza il pagamento, ottieni il risultato».

I pagamenti per agenti non riguardano quindi semplicemente l’aggiunta di un pulsante di pagamento a un chatbot. Significa che il software acquisisce un’autorità di spesa limitata e sviluppa un processo di approvvigionamento appartenente alle macchine. Gli esseri umani definiscono obiettivi, budget e limiti di rischio, e gli agenti allocano fondi entro tali vincoli. Il pagamento passa così da un’azione di regolamento a parte integrante del sistema decisionale dell’agente.

1. Perché i pagamenti per agenti diventeranno un percorso autonomo

1.1 Da invocazione di strumenti ad azione economica

La differenza tra agenti e script di automazione ordinari non risiede solo nella capacità di ragionamento. Gli script eseguono processi predeterminati e le risorse e i fornitori necessari sono solitamente già codificati; gli agenti scelgono il percorso in base all’ambiente. Nello stesso compito di ricerca, potrebbero prima acquistare risultati di ricerca, quindi decidere, in base a questi, se occorre un database settoriale e infine chiamare un altro modello per una validazione incrociata. Ogni passo di approvvigionamento influenza le decisioni successive.

Questo modello «esegui mentre approvvigioni» introduce la scelta economica nel runtime del software. Un agente deve non solo valutare se uno strumento è disponibile, ma anche se vale la pena acquistarlo: se il prezzo supera il budget, se la velocità di risposta soddisfa i requisiti del compito, se l’affidabilità storica è adeguata e se un servizio alternativo è più adatto. Il routing tradizionale degli strumenti si concentra sull’allineamento delle capacità, mentre l’approvvigionamento macchina deve gestire contemporaneamente prezzo e rischio di controparte. In tali transazioni, la parte che sopporta il rischio è l’agente stesso: il pagamento potrebbe andare a buon fine, ma il servizio potrebbe non essere erogato.

Pertanto, il bisogno principale dei pagamenti per agenti non è un pagamento automatico incondizionato, ma la delega controllata del potere d’acquisto al software. Gli utenti non cederanno facilmente l’intero portafoglio a un agente, ma saranno disposti a impostare un budget di pochi dollari per un compito chiaro, consentendogli di effettuare diversi acquisti di pochi centesimi. Autorizzazioni elevate potrebbero richiedere ancora un lungo processo di costruzione della fiducia, ma quelle piccole possono già creare un valore reale.

1.2 Micropagamenti, alta frequenza e multipli commercianti trasformano l’economia dei pagamenti

L’infrastruttura di pagamento dell’Internet umano è ottimizzata per transazioni relativamente infrequenti e ad alto valore. Le reti di carte di credito, i gateway di pagamento e i sistemi di abbonamento comportano costi fissi, quindi i commercianti spesso raggruppano numerose richieste in pacchetti mensili. Per richieste API del valore di pochi centesimi ciascuna, le commissioni, il rischio di contestazioni e i costi di gestione del conto nei pagamenti tradizionali possono superare il valore stesso dei beni.

Il consumo da parte delle macchine è esattamente l’opposto. Un agente può avviare diversi acquisti presso più commercianti entro pochi minuti per completare un singolo risultato. L’importo per transazione è molto basso, ma la frequenza è elevata e il numero totale di transazioni può superare di molto quello dei consumatori umani. Le stablecoin e il regolamento programmabile on-chain offrono una nuova base economica per questi scenari: i fondi possono circolare 24/7, le autorizzazioni di pagamento possono essere firmate da software e i servizi possono essere tariffati direttamente per singola chiamata.

Ancora più importante, l’approvvigionamento da più commercianti trasformerà il funzionamento della concorrenza nel mercato delle API. I modelli di abbonamento incentivano gli utenti a rimanere legati a un fornitore per lunghi periodi, mentre il pagamento per utilizzo consente agli agenti di scegliere dinamicamente il fornitore per ogni singolo compito. I fornitori di servizi non competono più soltanto per contratti annuali, ma anche per una necessità momentanea. Prezzo, prestazioni e storico di erogazione potrebbero influenzare in tempo reale i risultati del routing.

1.3 Le stablecoin stanno passando da mezzo di scambio a infrastruttura di regolamento

Nel primo mercato crittografico, la domanda di stablecoin proveniva principalmente da operazioni di trading e da spostamenti di capitale verso asset sicuri. Con la progressiva maturazione di emissione, custodia, conformità e infrastrutture cross-chain, le stablecoin stanno entrando nei settori del regolamento transfrontaliero, della gestione del tesoro aziendale e dei pagamenti nativi per Internet. Per i pagamenti tra macchine, le stablecoin offrono un ulteriore vantaggio specifico: sono sia valuta che asset digitale direttamente manipolabile dai programmi.

I pagamenti con carta di credito dipendono dall’identità del titolare, dai conti bancari e dalle reti geografiche. Gli agenti non possiedono l’identità di una persona fisica e non possono autonomamente completare i processi tradizionali di apertura conto. Un wallet vincolato da policy, invece, può fungere da interfaccia finanziaria per l’agente: l’operatore vi immette un saldo limitato, definisce massimali per transazione e per sessione e conserva i diritti di blocco e revoca; l’agente firma solo pagamenti entro i limiti autorizzati.

Ciò non significa che i pagamenti on-chain siano intrinsecamente superiori a tutti i pagamenti tradizionali. Protezione del consumatore, meccanismi di rimborso, privacy, gestione delle chiavi e responsabilità normativa devono ancora essere affrontati. Tuttavia, nei pagamenti machine-to-machine, nei micro-pagamenti per utilizzo e nell’approvvigionamento globale di servizi, le stablecoin programmabili offrono una chiara compatibilità. Per la prima volta, consentono di comprimere in un’unica interazione di rete sia «l’invocazione di un’interfaccia» che «il pagamento per tale interfaccia».

2. Le infrastrutture di pagamento sono già emerse: x402, MPP e transazioni native HTTP

2.1 Trasformare il codice di stato 402 in un’interfaccia commerciale

HTTP ha riservato da tempo il codice di stato 402 «Payment Required», ma per quasi 30 anni non si è sviluppato alcun flusso di lavoro generale. I protocolli di pagamento per macchine hanno riattivato questo significato: il client richiede un endpoint a pagamento, il server restituisce 402 con termini di pagamento leggibili da macchina; il client seleziona un’opzione accettabile, completa la firma o il pagamento e riprova la richiesta includendo le credenziali.

L’importanza di questo processo sta nel fatto che elimina la pagina di registrazione umana. La scoperta del prezzo, i requisiti di pagamento e la consegna dei contenuti avvengono tutti al livello di protocollo interpretabile dai programmi. Per gli sviluppatori, le API a pagamento non necessitano più di costruire un portale SaaS completo intorno ad account, piani e chiavi; per gli agenti, i servizi possono essere individuati come pagine web ordinarie e acquistati solo quando effettivamente necessari.

x402 è uno dei protocolli aperti più seguiti su questo percorso. Organizza le sfide di pagamento e le credenziali attorno all’HTTP 402, permettendo ai fornitori di servizi di riscuotere pagamenti per ogni singola richiesta. MPP, invece, parte da un ecosistema diverso ed esplora metodi di pagamento orientati alle macchine, come addebito e sessione. I due differiscono nei dettagli progettuali, ma insieme confermano una direzione: i pagamenti tra macchine possono diventare parte integrante del protocollo applicativo, senza dover ricorrere a un processo manuale di regolamento esterno all’applicazione.

2.2 La natura duratura della diversificazione delle infrastrutture di pagamento

Spesso si ritiene che, alla fine, rimarrà un unico protocollo standard, una sola rete di regolamento e uno schema di pagamento. Ma dal punto di vista del commerciante, la diversificazione ha una sua logica a lungo termine. Le query dati occasionali si adattano bene al pagamento per chiamata, mentre servizi di inferenza continua o streaming potrebbero conviene meglio con fatturazione basata su sessione; i servizi ad alto valore richiedono garanzie e strumenti di contestazione più robusti, mentre quelli a basso valore privilegiano velocità e costo; diverse regioni e aziende sceglieranno inoltre reti di conformità e regolamento differenti.

Il livello di protocollo continuerà a innovare. I commercianti potranno adottare addebiti diretti, autorizzazioni preventive, escrow, pagamenti in streaming o regolamenti batch; le reti potranno fare scelte diverse in termini di costo, definitività, liquidità e strumenti dell’ecosistema. Per i venditori, ciò rappresenta libertà di scelta. Per gli acquirenti, ogni nuova combinazione aggiunge un’ulteriore superficie di integrazione.

La matrice di configurazione nella figura seguente rappresenta una sezione trasversale di questa diversificazione: i protocolli/schemi di pagamento formano le colonne, le blockchain le righe e ogni scelta corrisponde a una configurazione di pagamento che richiede un’integrazione separata; questa tabella si sta tuttora allargando.

Figura 1: Matrice di configurazione delle infrastrutture di pagamento in un contesto di frammentazione

Pertanto, la frammentazione non scomparirà necessariamente in modo naturale con la maturazione del mercato. Il mercato delle carte bancarie non ha portato a un’unica organizzazione di carte dopo decenni di sviluppo, né il cloud computing si è concentrato su un unico fornitore. I mercati maturi di solito non eliminano le differenze, bensì creano strati aggregativi, di routing e di clearing sopra di esse. È molto probabile che i pagamenti per agenti seguano lo stesso percorso evolutivo. Questa divisione è già misurabile. I dati raccolti negli ultimi 30 giorni (al 3 settembre 2026) da due explorer pubblici (x402scan e mppscan) mostrano che: il protocollo MPP conta 65.591 wallet acquirenti attivi sulla blockchain Tempo, x402 ne conta 19.472 sulla blockchain Base, e soltanto 365 wallet appaiono su entrambe le infrastrutture, meno dello 0,6% degli acquirenti MPP e del 2% degli acquirenti Base x402; tra questi, soltanto 112 hanno completato più di dieci transazioni su ciascuna infrastruttura, e una porzione consistente sono aggregatori dual-rail che pagano per conto di utenti con la stessa chiave, anziché acquirenti che adottino autonomamente una seconda infrastruttura di pagamento. Gli acquirenti non migrano tra infrastrutture: ciascuna accumula una propria base indipendente di acquirenti.

2.3 L’onboarding del venditore rappresenta solo metà della transazione

I protocolli di pagamento abbassano innanzitutto la soglia per i commercianti che accettano pagamenti. Non appena un endpoint può pubblicare preventivi, verificare credenziali e restituire servizi, soddisfa le condizioni minime per il commercio rivolto alle macchine. Un numero crescente di strumenti per sviluppatori, servizi dati e interfacce di contenuto diventa così acquistabile automaticamente.

Tuttavia, una fornitura pagabile non implica che la domanda ne conseguirà automaticamente. I commercianti risolvono il problema «Come ricevo pagamenti dalle macchine?», ma gli agenti devono ancora rispondere a domande come «Da chi devo acquistare?», «Quale metodo di pagamento devo usare?» e «Come confermo la consegna dopo il pagamento?». Se ogni acquirente dovesse integrare separatamente ciascun protocollo, preparare fondi su reti diverse e gestire registri indipendenti, i pagamenti automatici ripeterebbero la complessità delle prime integrazioni API—sostituendo semplicemente le chiavi API con portafogli e adattatori di protocollo.

L’adozione reale dipende dall’attrito totale della transazione, non solo da quello relativo al passaggio di regolamento.

3. Il vero collo di bottiglia del settore: le transazioni non hanno un ciclo chiuso

Figura 2: Processo completo di approvvigionamento automatico

3.1 Primo ostacolo: individuare servizi acquistabili

Gli agenti necessitano di directory di servizi leggibili dalle macchine. Una directory efficace non può contenere solo nomi e URL; deve descrivere anche le capacità dell’endpoint, gli input e output, le unità di prezzo, i protocolli disponibili, la latenza, le restrizioni geografiche e lo stato di aggiornamento. È inoltre necessario un mapping tra l’intento espresso in linguaggio naturale e i parametri API; altrimenti, un agente sa di «aver bisogno di dati macroeconomici», ma non riesce a identificare quale endpoint soddisfi tale esigenza.

Le directory nei mercati aperti affrontano inoltre problemi di duplicazione, scadenza e false affermazioni. Qualsiasi commerciante può dichiarare di fornire dati di alta qualità, ma gli agenti non possono dedicare giorni a verifiche approfondite come farebbe uno staff umano addetto agli approvvigionamenti. Il livello di scoperta deve quindi verificare continuamente se gli endpoint sono invocabili, se i preventivi sono reali e se le descrizioni corrispondono ai contenuti restituiti.

Ciò rende la scoperta di servizi diversa dalla ricerca tradizionale. I motori di ricerca ottimizzano la pertinenza informativa, mentre le directory per l’approvvigionamento automatico devono ottimizzare anche la negoziazione: compatibilità delle capacità, accettabilità dei prezzi, compatibilità dei pagamenti e capacità di consegna da parte dei commercianti.

3.2 Secondo ostacolo: comprendere e confrontare i preventivi

In superficie, API simili possono tutti essere tariffati a chiamata, ma nella pratica i preventivi sono scarsamente comparabili. Uno addebita per richiesta, un altro per elemento risultante; uno include l’inferenza del modello nel prezzo, un altro richiede un pagamento aggiuntivo; altri servizi fatturano dinamicamente in base alla lunghezza dell’input, al tempo di esecuzione o ai risultati ottenuti.

Un agente non può semplicemente scegliere l’endpoint col prezzo nominale più basso. Deve considerare costo totale, probabilità di consegna, latenza e qualità del risultato. Se un’interfaccia economica fallisce ripetutamente, i costi di ripetizione e i ritardi nel compito potrebbero renderne il prezzo effettivo più alto. I preventivi vanno quindi valutati insieme al livello di servizio, alle prestazioni storiche e al contesto del compito.

I preventivi leggibili dalle macchine devono inoltre specificare periodi di validità e importi finali. In un ambiente di pricing dinamico, ciò che l’agente firma deve essere un impegno vincolante, non una semplice fascia di prezzo. Gli operatori devono inoltre conoscere la composizione delle tariffe—commissioni di servizio, costi di rete e commissioni di instradamento—per definire budget attendibili.

3.3 Terza barriera: distribuzione dei fondi e liquidità cross-chain

Se un agente deve acquistare servizi su più blockchain e più protocolli contemporaneamente, l’approccio più immediato è pre-caricare fondi su ciascuna rete. Ciò però frammenta un piccolo capitale in tanti piccoli importi. I fondi rimangono inutilizzati sulle reti non attualmente utilizzate, mentre quelle popolari potrebbero esaurire il saldo; ricaricare comporta operazioni di bridging, swap, gas e sicurezza.

Per un singolo utente, ciò è già oneroso. Per un’impresa che gestisce molti agenti, il problema si amplifica ulteriormente: quanto saldo deve detenere ciascun agente? Chi è responsabile delle ricariche? Come si evita un uso improprio dei fondi? E come si aggregano asset e commissioni su reti diverse? Senza un livello unificato di finanziamento, maggiore è il numero di canali di pagamento, maggiore sarà la complessità finanziaria.

Idealmente, ciò che un agente vede è un unico budget utilizzabile, non diversi saldi di rete. Il sistema sottostante gestisce la selezione dei percorsi di regolamento, la gestione della liquidità e la fornitura di preventivi trasparenti. Il principio è analogo a quello di un viaggiatore che usa una sola carta per spendere in paesi diversi: l’utente si interessa al limite di credito totale e al tasso di cambio, senza dover aprire preventivamente un conto locale per ogni destinazione.

3.4 Quarta barriera: autorizzazione basata su policy

La preoccupazione più facilmente suscitata dai pagamenti autonomi è che un agente possa spendere senza controllo. La soluzione non è semplicemente scegliere tra «divieto assoluto» e «autorizzazione completa», ma stabilire policy multilivello.

Limiti per transazione riducono le perdite derivanti da un singolo errore, budget per sessione limitano la spesa totale di un compito, liste bianche o nere di commercianti controllano i controparti, regole per categoria restringono gli acquisti consentiti e limiti di frequenza prevengono chiamate anomale in breve tempo. Transazioni ad alto rischio o ad alto valore possono inoltre richiedere conferma manuale. Le policy devono essere impostate dagli operatori, e gli agenti possono agire solo entro tali limiti—non possono aumentarli autonomamente.

Un wallet non deve semplicemente gestire le firme. Deve integrarsi con attività, identità e registri di audit per rispondere a domande come: «Quale agente ha approvato questo pagamento, per quale attività e in base a quale politica?». Altrimenti, l’impresa ottiene solo una sequenza di hash di transazioni on-chain, insufficiente a soddisfare i requisiti di controllo interno e attribuzione dei costi.

3.5 Fase cinque: il regolamento riuscito non equivale alla consegna del servizio

La blockchain eccelle nel dimostrare che i fondi sono passati da un indirizzo a un altro, ma non può provare intrinsecamente che un’API abbia restituito il contenuto corretto. Una transazione può completare il regolamento, ma il server potrebbe andare in timeout, restituire uno stato d’errore o fornire dati non conformi a quanto dichiarato. Per gli agenti, questo non è un caso limite: è il nocciolo del rischio di approvvigionamento.

Il commercio elettronico tradizionale collega pagamento e consegna tramite logistica, recensioni e rimborsi; i servizi macchina non hanno logistica fisica — la consegna può essere semplicemente una risposta HTTP transitoria. Se i sistemi di pagamento registrano solo il percorso dei fondi e i venditori registrano solo le proprie risposte, il mercato manca di una visione unificata dell’adempimento che copra sia venditori che protocolli.

Occorre cautela: registrare una risposta non equivale a dimostrarne la qualità. Tuttavia, correlare pagamento e risposta permette almeno di distinguere stati fondamentali come «pagato e risultato ricevuto», «pagato ma servizio fallito» e «non regolato». Questo è il primo livello di fatto per costruire la credibilità delle transazioni macchina.

3.6 Fase sei: riconciliazione unificata e definizione delle responsabilità

Un’unica attività può includere dozzine di microacquisti. Se ogni transazione è dispersa tra diversi wallet, protocolli e backend dei venditori, è difficile per gli utenti capire perché il prodotto finale abbia quel costo. Le imprese devono inoltre attribuire le spese a progetti, team, clienti e centri di costo, conservando prove verificabili.

Un ledger unificato dovrebbe registrare simultaneamente intento di acquisto, venditori, preventivi, politiche di autorizzazione, esiti del regolamento, stato della risposta e motivi di fallimento. Non serve solo alla finanza, ma anche all’ottimizzazione degli agenti: il sistema può analizzare quali fonti dati falliscono più spesso, quali percorsi sono più costosi e quali siano le combinazioni tipiche di acquisto per un dato tipo di attività.

Quando il pagamento è integrato nella catena decisionale, il costo diventa un segnale di feedback per le scelte del modello. Senza riconciliazione unificata, gli agenti possono ottimizzare solo le risposte, non il processo economico per ottenerle. Buona parte del valore a lungo termine dei pagamenti per agenti deriva proprio da questa osservabilità.

4. Dal protocollo di pagamento allo strato di approvvigionamento macchina

4.1 L’astrazione fondamentale del futuro non è «pagare», ma «acquistare»

Pagare è un’azione che segue la definizione chiara dell’oggetto e del prezzo, mentre l’approvvigionamento copre l’intero processo, dalla domanda all’accettazione. Esporre una funzione pay() a un agente gli consente solo di trasferire fondi a un indirizzo noto; esplicitare una capacità buy() significa che il sistema può ricevere la domanda, individuare servizi, confrontare opzioni, eseguire il pagamento e restituire risultati verificabili.

Questa distinzione determina la ripartizione dei compiti nell’industria. I protocolli forniscono messaggi di pagamento standardizzati, i wallet gestiscono firme e asset, le reti di regolamento trasferiscono valore, le directory aggregano l’offerta e lo strato di approvvigionamento coordina questi componenti in un’unica attività. Ogni singolo componente è importante, ma nessuno da solo rappresenta una transazione completa.

Lo strato di approvvigionamento macchina deve rimanere aperto: non deve richiedere che tutti i venditori migrino allo stesso protocollo, né imporre una directory chiusa per decidere chi possa essere acquistato. Un modello più sostenibile è la compatibilità con più canali di pagamento, la trasparenza sui costi di instradamento nei preventivi e la possibilità per gli agenti di scegliere autonomamente in base alle politiche.

4.2 L’aggregazione degli acquirenti potrebbe essere più importante di quella dei venditori

Le piattaforme internet aggregano tipicamente prima l’offerta, poi attraggono i consumatori. Nei mercati macchina, l’offerta esiste già ampiamente sotto forma di API; ciò che manca è un acquirente standardizzato in grado di acquistare in modo continuativo. Un agente equipaggiato può trasformare una domanda frammentata e occasionale in un flusso transazionale stabile.

L’aggregazione degli acquirenti migliora anche la visibilità dei servizi di nicchia. Gli sviluppatori umani tendono a usare grandi marchi noti perché il costo temporale della valutazione di nuovi fornitori è elevato; se gli agenti possono leggere segnali standardizzati su capacità, prezzo e adempimento, possono scegliere il servizio più adatto a ogni attività. Ciò potrebbe ridurre i costi di acquisizione clienti per nuovi venditori e spingere quelli consolidati a competere sulla reale prestazione.

Tuttavia, i punti di ingresso per gli acquirenti possono creare nuovi poteri di piattaforma. Chi controlla la directory predefinita, il ranking e i percorsi di pagamento può influenzare l’allocazione del traffico. L’industria ha quindi bisogno di regole di ranking trasparenti, commissioni spiegabili e record transazionali portabili. L’aggregazione può ridurre le frizioni, ma non deve trasformare protocolli aperti in canali chiusi.

4.3 Costruire la reputazione sui dati reali delle transazioni

Gli acquirenti macchina decidono molto rapidamente e non possono basarsi su lunghi processi di due diligence. Hanno bisogno di segnali sul controparte già al momento della visualizzazione del preventivo. Valutazioni e recensioni tradizionali offrono un riferimento, ma sono facilmente manipolabili tramite volumi fittizi, account Sybil e parti correlate. Se le recensioni non richiedono un vero pagamento, il costo dell’attacco è particolarmente basso. Una recente ricerca empirica su ERC-8004 — il primo layer di trust on-chain permissionless per agenti — conferma questo [6]. La specifica del protocollo afferma testualmente che «I pagamenti sono ortogonali a questo protocollo»: le recensioni non devono necessariamente essere legate a una transazione effettivamente pagata, e la prova del pagamento è solo un campo opzionale. Il risultato è che, su Ethereum, BSC e Base (al 13 maggio 2026), rispettivamente il 73,5%, il 59,2% e il 90,6% dei recensori hanno mostrato comportamenti coordinati da Sybil.

Una base più affidabile è costituita dai record di risultato legati a chiamate effettivamente pagate: quanti pagamenti un endpoint di servizio ha completato, qual è il tasso di successo delle risposte, quale la latenza media e quanto sia elevata la percentuale di mancata risposta dopo il pagamento. Queste metriche non rappresentano ancora pienamente la qualità dei contenuti, ma si avvicinano di più a fatti verificabili rispetto alle autodichiarazioni.

Con l’accumulo di dati, il mercato potrebbe sviluppare una reputazione articolata in livelli: il primo livello riguarda lo stato oggettivo delle transazioni, il secondo i parametri di servizio riproducibili e il terzo la valutazione della qualità per compiti specifici. Gli agenti potranno scegliere la robustezza delle prove richieste in base all’importo e al rischio: pochi centesimi per una query dati potranno basarsi su segnali statistici, mentre acquisti di alto valore richiederanno garanzie, audit o procedure di risoluzione delle controversie.

4.4 La strategia di budget diventerà una capacità fondamentale per gli agenti

Oggi gli agenti sono valutati principalmente sulla qualità delle risposte, sul tasso di completamento dei compiti e sull’accuratezza delle chiamate agli strumenti. Una volta entrati in ambienti a pagamento, vanno aggiunte metriche economiche: quanto si spende per ottenere la stessa qualità, se il compito è completato entro il budget, quando conviene acquistare dati più costosi e come bilanciare velocità, costo e affidabilità.

Ciò creerà nuove direzioni per addestramento e valutazione. Gli agenti dovranno apprendere non solo «quale strumento risponde alla domanda», ma anche «se acquistare questo strumento è conveniente, dato il valore del compito corrente». Potrebbero prima usare servizi a basso costo per filtrare, poi acquistare verifiche di alta qualità per conclusioni chiave; oppure ridurre la frequenza delle chiamate quando il budget è quasi esaurito o richiedere ulteriore autorizzazione all’utente.

In questo senso, il pagamento degli agenti non è un semplice plug-in finanziario esterno alle capacità del modello, ma parte integrante dell’intelligenza decisionale. Un agente davvero maturo non deve solo utilizzare risorse, ma anche valutarne il costo.

5. Possibili percorsi evolutivi per il pagamento degli agenti

5.1 Fase uno: strumenti per sviluppatori e servizi digitali in prima linea

Gli scenari su larga scala più precoci saranno probabilmente quelli puramente digitali: ricerca, dati, scraping tramite proxy, inferenza di modelli, esecuzione di codice, archiviazione e generazione di contenuti. Questi servizi sono già erogati tramite API, hanno costi marginali di consegna molto bassi, permettono pagamento e risposta nella stessa sessione di rete e non richiedono logistica complessa.

Gli importi tipici in questa fase sono molto piccoli e gli utenti privilegiano comodità di sviluppo e tasso di completamento dei compiti. Il mercato convaliderà rapidamente i protocolli, ma i volumi di transazione potrebbero essere fortemente frammentati. Molte chiamate continueranno a essere gestite tramite chiavi API tradizionali e abbonamenti, mentre i pagamenti automatici verranno usati soprattutto per esigenze temporanee, acquisti cross-merchant e servizi di nicchia non preconfigurabili come account.

5.2 Fase due: budget aziendali e collaborazione tra agenti

Quando le aziende inizieranno a distribuire più agenti, la gestione dei fondi passerà da portafogli personali a sistemi contabili organizzativi. Le aziende dovranno allocare budget a ruoli diversi, controllare le categorie acquistabili, impostare soglie di approvazione e registrare le spese nei sistemi finanziari. Potrebbe anche nascere una contabilità interna tra agenti: agenti di ricerca acquistano dati, agenti di analisi comprano potenza computazionale e agenti di esecuzione chiamano servizi esterni.

A questo punto, sicurezza e conformità diventano più importanti della novità del pagamento. Le aziende tengono alla custodia delle chiavi, all’isolamento dei permessi, al monitoraggio delle transazioni, alla verifica dei fornitori e alle tracce di audit. Solo le infrastrutture in grado di integrarsi con i processi finanziari esistenti potranno passare dalla fase sperimentale a quella produttiva.

5.3 Fase tre: dall’ambito digitale all’economia reale

Biglietti aerei, hotel, logistica, pubblicità e servizi professionali potrebbero tutti diventare obiettivi di acquisto per gli agenti, ma le transazioni nel mondo reale richiedono gestioni più complesse di identità, rimborsi, tassazione e controversie. Le stablecoin risolvono solo parzialmente il problema del regolamento: non possono sostituire i diritti dei consumatori né i contratti commerciali.

L’industria non deve quindi interpretare male il «pagamento autonomo» come eliminazione di tutti gli intermediari. Al contrario, con l’aumento del valore delle transazioni, garanzie, assicurazioni, credito e arbitrato torneranno in auge — devono però trasformarsi in servizi invocabili dalle macchine. Lo stack futuro del pagamento degli agenti potrebbe includere contemporaneamente protocolli di pagamento aperti e connettività finanziaria tradizionale, anziché un percorso che ne sostituisca l’altro.

5.4 Fase quattro: dal routing cross-protocollo all’esecuzione cross-market

A lungo termine, ciò che gli agenti acquistano non è solo una risposta API, ma un risultato. Un utente potrebbe richiedere «generare un rapporto settoriale attendibile», e il sistema combinerebbe autonomamente ricerca, database, traduzione, modelli e servizi di verifica. A livello sottostante avvengono molteplici transazioni, mentre l’utente vede soltanto il budget totale, le fonti delle prove e la consegna finale.

Ciò trasformerà il routing dei pagamenti in un’esecuzione di mercato. Il sistema dovrà suddividere obiettivi complessi in portafogli di acquisto, sostituire dinamicamente i fornitori falliti e ottimizzare tra costo totale e qualità. La compatibilità dei protocolli è solo la base; il vero vantaggio competitivo deriva dalla comprensione della domanda, dai dati transazionali e dal feedback sull’esecuzione.

6. Rischi e domande aperte

I pagamenti tramite agenti hanno un enorme potenziale creativo, ma non si possono ignorare i vincoli del mondo reale. Il primo è la sicurezza. L’injecting di prompt potrebbe indurre gli agenti ad acquistare servizi dannosi; attacchi alla catena di approvvigionamento potrebbero sostituire gli indirizzi di ricezione; politiche difettose potrebbero causare duplicazioni massicce di pagamenti. Le azioni di pagamento devono essere isolate da contenuti non attendibili e dotate di limiti, simulazione, revoca e rilevamento delle anomalie.

Il secondo è la privacy. I registri degli acquisti rivelano quali attività sta svolgendo un agente, e i dati pubblici su blockchain potrebbero collegare l’identità dell’utente all’intenzione commerciale. I sistemi devono ridurre al minimo la fuoriuscita di metadati sensibili, bilanciando requisiti di audit e tutela della privacy.

Il terzo è la responsabilità legale. Quando un agente effettua un acquisto errato, un venditore non consegna o un protocollo di conversione fallisce, chi deve sopportare la perdita? Per transazioni di basso valore si può accettare un rischio automatizzato, ma per quelle di alto valore servono confini di responsabilità chiari. Una rete di pagamenti senza meccanismo di contestazione avrà difficoltà a entrare direttamente nel commercio ad alto valore.

Il quarto è la regolamentazione. Emissione di stablecoin, controlli sui portafogli, trasferimenti transfrontalieri e pagamenti ai merchant sono soggetti a normative diverse a seconda delle giurisdizioni. Le macchine sono esecutori, non soggetti di responsabilità legale. L’infrastruttura deve poter risalire ogni transazione autonoma a un operatore identificabile, a una politica di autorizzazione chiara e a una fonte di fondi verificabile.

Il quinto è la sostenibilità commerciale. I ricavi da micropagamenti vengono facilmente erosi dai costi di rete, dalla liquidità e dalle commissioni per il controllo del rischio. Se le piattaforme sovvenzionano l’esperienza tramite maggiorazioni nascoste, minano la fiducia degli acquirenti. Le commissioni devono essere trasparenti e un solido modello di business va costruito attraverso scala, efficienza del routing e servizi aggiuntivi.

Queste problematiche non invalidano il settore, ma dimostrano che i pagamenti tramite agenti non saranno realizzati tramite un singolo protocollo. Diventeranno invece un’infrastruttura composita per pagamenti, identità, permessi, discovery, reputazione e riconciliazione.

7. SELAT: Abilitare il lato acquisto per il commercio nativo per macchina

«SELAT» deriva dalla parola malese per «stretto», come lo Stretto di Malacca (Selat Melaka). Per secoli, indipendentemente dalla provenienza delle merci o dalla destinazione finale, il flusso principale del commercio Est-Ovest ha attraversato questa via marittima. SELAT mira a diventare tale stretto nel commercio nativo per macchina: indipendentemente dal «binario» scelto dal venditore, la domanda degli agenti potrà fluire attraverso di esso.

SELAT è un’azienda nativa per l’IA che sceglie di entrare nel campo dei pagamenti per macchina partendo dal lato acquisto. SELAT è il livello lato acquisto per il commercio nativo per macchina. Il suo obiettivo principale non è creare un altro binario di pagamento che richieda ai venditori di migrare, bensì abilitare gli agenti a completare gli acquisti attraverso i binari esistenti. Si concentra su due problemi fondamentali: primo, la frammentazione delle configurazioni di pagamento, dove binari, protocolli, blockchain e credenziali differiscono tutti, richiedendo una nuova integrazione per ogni venditore; secondo, la mancanza di misurazione del rischio della controparte, poiché una regolazione andata a buon fine non implica necessariamente la consegna del servizio.

Figura 3: Diagramma schematico del livello lato acquisto SELAT

Per affrontare la frammentazione, l’interfaccia a riga di comando (CLI) di SELAT isola le differenze tra protocolli, schemi di pagamento e reti di regolamento al livello infrastrutturale, consentendo agli agenti di completare acquisti cross-binario con un singolo comando. Discovery, quotazione, autorizzazione, pagamento, registrazione dello stato di consegna e riconciliazione sono tutti integrati nello stesso processo di approvvigionamento, e ogni chiamata viene registrata nello stesso registro.

• Un unico tesoro, utilizzando N binari di pagamento

Gli agenti detengono un saldo USDC in custodia autonoma, senza dover pre-finanziare per blockchain né mantenere client diversi per protocolli differenti.

• Catalogo aggregato di endpoint

La CLI di SELAT integra quattro registry di servizi di terze parti — Circle, MPP, Apify e pay.sh — oltre al catalogo interno di SELAT, permettendo agli agenti di individuare e confrontare oltre 4.000 endpoint di servizio sulla base dell’intento in tempo reale.

• Limiti fissi di spesa

Gli operatori possono impostare limiti per transazione e budget per sessione, e bloccare in qualunque momento le autorizzazioni di spesa; gli agenti non possono aumentare tali limiti autonomamente.

• Nessuna migrazione richiesta per i venditori

I venditori possono mantenere i propri binari di pagamento preferiti ed essere individuati e acquistati dagli agenti senza doversi registrare nuovamente presso SELAT.

Sul fronte finanziario, SELAT opera con qualsiasi portafoglio per agenti, inclusi i portafogli Circle e MetaMask. SELAT instrada ogni acquisto attraverso binari di pagamento come x402 e MPP, sulla base di quotazioni in tempo reale.

7.1 ERC-8004: Primitivi corretti, segnali discutibili

ERC-8004 definisce tre tipi di registri—identità, reputazione e validazione—e consente agli acquirenti di inviare recensioni ai venditori. La direzione è corretta, ma separa esplicitamente pagamento e reputazione: i feedback non devono provenire da transazioni reali e l’allegazione della prova di pagamento è opzionale.

Ricerche empiriche sull’ecosistema in produzione mostrano che su Base il 93,8% dei revisori non aveva mai effettuato un pagamento x402, pur fornendo il 94,9% dei feedback; gran parte di questi presenta inoltre comportamenti coordinati da sybil [6]. I registri registrano affermazioni, ma ciò di cui gli acquirenti hanno davvero bisogno sono i risultati.

7.2 Una reputazione legata ai dati reali delle transazioni è ciò di cui gli acquirenti hanno bisogno

Le infrastrutture di pagamento possono confermare se i fondi sono stati regolati, ma non vedono cosa ha restituito il servizio; i merchant vedono le proprie risposte, ma non l’intero mercato; i registri elencano endpoint, ma non provano che i feedback provengano da acquisti reali.

Il livello acquirente che esegue gli acquisti è meglio posizionato per collegare entrambe le estremità di una transazione: ogni acquisto completato tramite SELAT registra quale endpoint è stato pagato, quanto è stato regolato e i metadati sullo stato di consegna post-pagamento (2xx, 4xx, 5xx). Questi record si accumulano continuamente per merchant e infrastruttura di pagamento, costituendo la base dati del «Grafo Regolazione–Consegna».

È necessaria una distinzione precisa: i record che collegano pagamento e stato di consegna non equivalgono a una prova indipendente della qualità della consegna o dell’accuratezza del preventivo. Forniscono però la base che la reputazione basata su registri non possiede: dati sui risultati legati a invocazioni realmente pagate.

7.3 Ottenere la credibilità della controparte prima delle transazioni

Mentre su X si discuteva su come progettare un meccanismo di fiducia simile a Google PageRank per il web di quarta generazione, SELAT aveva già lanciato l’«Indice di Transazionabilità» basato sul suo grafo regolazione-consegna, per offrire agli agenti, in tempo reale, dati sulla credibilità della controparte supportati da esiti reali di transazioni.

L’indice viene restituito insieme ai preventivi, senza richiedere agli agenti di interrompere i propri compiti per indagare separatamente sui merchant. Segnala il rischio senza creare barriere al mercato: gli endpoint possono comunque essere individuati e acquistati, e gli agenti decidono in base a budget, importanza del compito e tolleranza al rischio.

Gli agenti non hanno tempo per leggere storie di marca. Devono sapere, prima di pagare: come si comporta questo endpoint nelle transazioni reali? Nell’economia macchina-native, la credibilità non deve derivare da affermazioni, ma da risultati.

Figura 3: Segnali di transazionabilità nella fase di preventivo

Attualmente, la CLI di SELAT è stata adattata per ambienti di runtime per agenti, tra cui Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Hermes e Grok Bot.

8. Riepilogo: L’economia macchina ha bisogno di più che semplici infrastrutture di pagamento più veloci

I pagamenti per agenti sono in una fase in cui è facile sopravvalutarli o sottovalutarli. Sono facilmente sopravvalutati perché completare tecnicamente un pagamento in stablecoin non significa che un agente abbia maturato autonomia commerciale; sono facilmente sottovalutati perché, una volta che il software può acquistare capacità esterne entro vincoli chiari, i metodi organizzativi, i modelli di prezzo e i confini competitivi dell’economia macchina cambieranno tutti.

I protocolli di pagamento hanno già dimostrato che le macchine possono ricevere preventivi ed effettuare regolamenti. Il passo successivo cruciale è ampliare un pagamento isolato in un processo completo di approvvigionamento: consentire agli agenti di trovare servizi adeguati, comprendere i costi effettivi, pagare su diverse infrastrutture nel proprio budget, confermare la consegna e trasformare ogni transazione in un record verificabile e apprendibile.

Il futuro dell’economia macchina non avrà una sola blockchain, un solo protocollo o un solo wallet. L’approvvigionamento multiplo persiste a lungo termine e le infrastrutture davvero preziose aiuteranno gli acquirenti a navigare questa complessità. I pagamenti per agenti devono integrare infrastrutture, offerta, pagamenti predefiniti e meccanismi di fiducia per trasformare la capacità tecnica in domanda reale.

Quando il software inizia ad agire come acquirente, il pagamento è solo il primo passo che compie. La domanda più importante rimane sempre: può completare una transazione realmente utile in modo controllabile, trasparente e verificabile?

Riferimenti

[1] Circle, «Costruire l’economia aperta degli agenti», 2026. https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT, «Rischio controparte nei pagamenti agenziali: la metà non misurata», 2026. https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud, «Potenziare il commercio AI con il nuovo Protocollo Agent Payments (AP2)», 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] Fondazione x402, «x402: uno standard aperto per pagamenti nativo di Internet». https://github.com/x402-foundation/x402

[5] Protocollo Pagamenti Macchina, «MPP: un protocollo per pagamenti macchina basato su HTTP 402». https://mpp.dev/

[6] Xiong et al., «Gli agenti senza fiducia possono essere considerati affidabili? Uno studio empirico sull’ecosistema decentralizzato di agenti IA ERC-8004», arXiv, 2026. https://arxiv.org/abs/2606.26028

[7] Sito ufficiale SELAT: https://www.selat.ai

Questo articolo è un contributo esterno e non rappresenta le opinioni di BlockBeats.