L’economia agent-to-agent prende forma quando un agente software non si limita a preparare una proposta per un operatore umano, ma comunica con l’agente di un’altra organizzazione per verificare disponibilità, confrontare condizioni, negoziare entro limiti autorizzati, generare un ordine e attivare il pagamento. In questo modello l’interazione non avviene più soltanto tra persone, portali e caselle email: viene gestita da sistemi software che rappresentano interessi, vincoli e regole operative di aziende diverse.
Il protocollo Agent2Agent, o A2A, è stato progettato per rendere possibile questa comunicazione tra agenti sviluppati con framework, linguaggi e infrastrutture differenti. Ogni agente può pubblicare una Agent Card, cioè un documento disponibile a un indirizzo noto che descrive nome, capacità, modalità di interazione ed endpoint. Un agente di procurement può così individuare un agente fornitore, capire quali servizi espone e inviare una richiesta strutturata senza dover integrare manualmente ogni singolo sistema esterno.
La differenza rispetto all’EDI tradizionale è nella flessibilità della conversazione. Un collegamento EDI scambia ordini, conferme, fatture e documenti secondo formati rigidamente definiti. Un agente A2A può invece ricevere un obiettivo più articolato, come acquistare una quantità di componenti entro una certa data, con un costo massimo, un livello minimo di conformità e vincoli di consegna. L’agente può interrogare più fornitori, confrontare le risposte, chiedere chiarimenti, valutare alternative e proporre una scelta che rispetti i parametri assegnati.
Questo non significa che l’agente debba agire senza regole. In un’architettura aziendale reale, il sistema deve operare entro soglie precise: budget massimo, elenco di fornitori qualificati, categorie merceologiche autorizzate, condizioni contrattuali già approvate, limiti di quantità, soglie per l’approvazione umana e criteri per la gestione delle eccezioni. L’autonomia riguarda l’esecuzione di decisioni delimitate, non la possibilità di impegnare liberamente l’azienda in qualunque trattativa.
Per collegare l’agente ai sistemi aziendali entra in gioco il Model Context Protocol, MCP. Se A2A regola la comunicazione con agenti esterni, MCP consente a un agente di usare fonti dati e strumenti interni, come ERP, CRM, database di magazzino, sistemi documentali, cataloghi prodotti, applicazioni di posta o piattaforme di ticketing. L’agente buyer può quindi controllare le scorte, verificare i consumi, consultare contratti e condizioni negoziate, mentre l’agente seller può interrogare disponibilità di magazzino, tempi di produzione, listini e regole di spedizione.
Il pagamento richiede un livello aggiuntivo perché un agente non può ricevere semplicemente i dati della carta o le credenziali bancarie dell’azienda. L’Agent Payments Protocol, AP2, è stato proposto da Google per introdurre meccanismi di autorizzazione verificabili nelle transazioni eseguite da agenti. Il principio è separare la decisione dell’utente o dell’organizzazione dall’esecuzione operativa: il soggetto autorizza un perimetro di acquisto, mentre l’agente può completare l’azione soltanto entro quell’ambito.
Nelle architetture di pagamento delegato, la credenziale usata dall’agente viene resa disponibile come token limitato. Il token può essere vincolato a un singolo venditore, a un importo massimo, a una scadenza temporale e a una specifica transazione. Questo evita che l’agente conservi o riutilizzi informazioni finanziarie sensibili e permette di registrare con precisione chi ha autorizzato l’operazione, quale regola è stata applicata e quale sistema ha completato il pagamento.
Lo stesso principio è adottato nell’Agentic Commerce Protocol utilizzato da OpenAI e Stripe per le transazioni commerciali assistite da agenti. Il commerciante resta merchant of record, mantiene la relazione con il cliente e gestisce pagamento, rimborsi, contestazioni e adempimenti attraverso il proprio payment service provider. L’agente facilita il passaggio tra ricerca, selezione, checkout e ordine, ma non sposta automaticamente responsabilità commerciali e regolatorie su una piattaforma AI.
Nel procurement aziendale la combinazione di A2A, MCP e protocolli di pagamento può essere applicata a casi circoscritti ma ripetitivi. Un agente può monitorare le scorte di materiali indiretti, rilevare il superamento di una soglia minima, verificare i fornitori abilitati, richiedere preventivi, controllare tempi di consegna e inviare un ordine entro un budget già approvato. Un altro utilizzo riguarda il rinnovo di licenze software, dove il sistema può confrontare licenze acquistate, utilizzo effettivo, contratti in scadenza e alternative disponibili prima di proporre o completare il rinnovo.
La parte più complessa non è la conversazione tra modelli linguistici, ma la costruzione della fiducia tra sistemi. Perché un agente possa accettare un’offerta, deve poter verificare identità del fornitore, validità delle certificazioni, condizioni contrattuali, disponibilità reale dei beni, integrità dei messaggi e autorizzazioni ricevute. In un ecosistema A2A servono quindi firme digitali, registri di audit, gestione delle identità, log delle decisioni, limiti di spesa e procedure di revoca immediata delle autorizzazioni.
Anche il controllo delle anomalie assume un ruolo centrale. Un agente potrebbe ricevere dati errati da un sistema esterno, essere indotto da contenuti manipolati a compiere un’azione non prevista oppure interpretare in modo scorretto una clausola commerciale. Per questo un processo A2A destinato alla produzione deve prevedere controlli deterministici esterni al modello: validazione dei campi, verifiche di prezzo e quantità, confronto con contratti, blocchi sulle operazioni fuori soglia, autorizzazione umana per importi elevati e riconciliazione tra ordine, consegna, fattura e pagamento.
L’effetto più concreto di questa infrastruttura è la riduzione delle operazioni manuali che oggi collegano sistemi separati. Non cambia il fatto che un’impresa debba definire fornitori, contratti, budget e responsabilità; cambia il modo in cui queste regole vengono applicate. L’agente può diventare l’interfaccia operativa tra ERP, cataloghi, marketplace, fornitori e sistemi di pagamento, trasformando una sequenza di email e controlli ripetitivi in un workflow tracciabile, controllato e verificabile.