Tag: agentic ai

AI & GENAI, PROGETTI E IDEE

Plenipo e l’EUDI Wallet: dare agli agenti AI un mandato invece dei pieni poteri

Domenica 25 ottobre ho reso pubblico il repository di Plenipo, la libreria che fa approvare dall’EUDI Wallet un mandato per gli agenti AI, e ho pubblicato la versione 0.4 su npm, con licenza Apache 2.0. Il mio vero primo progetto OpenSource, dopo LocalAI.

Nella stessa giornata il primo wallet reale, la Wallet API di walt.id, ha completato tutto il flusso, dalla richiesta del mandato fino alla verifica, e la sandbox è andata online con una vetrina che mostra in diretta cosa succede quando un agente prova a pagare.

In pratica una persona autorizza un agente con un mandato firmato dal proprio wallet, e qualunque servizio, una banca per esempio, verifica quel mandato prima che l’agente agisca. Lo racconto qui perché è un esperimento, con i suoi limiti dichiarati, e perché la domanda da cui nasce mi sembra più grande del codice che ho scritto per rispondere.

Un registro che non dice chi c’è dietro

Tutto parte da un fastidio. Quest’anno, studiando l’EUDI Wallet dentro un progetto di sperimentazione, mi sono messo a guardare come reti di carte e startup statunitensi stanno costruendo i registri degli agenti AI, gli elenchi che servono a un commerciante per riconoscere chi bussa alla sua API. Funzionano, ti dicono quale software ha agito e con quale chiave, ma quasi mai rispondono alla domanda che interessava a me: chi c’è dietro quell’agente, e con quale autorità lo ha mandato a spendere?

Nel frattempo in Europa sta succedendo una cosa che fuori dagli addetti ai lavori si racconta poco. Il regolamento eIDAS 2 chiede a ogni Stato membro di offrire ai cittadini un EUDI Wallet entro la fine del 2026, con dentro il PID, l’identità digitale con valore legale, e il protocollo con cui il wallet presenta le credenziali, OpenID4VP, prevede un meccanismo chiamato transaction data che permette alla persona di approvare in modo vincolante un contenuto mostrato a schermo, con una firma che copre esattamente quei byte.

Ho messo insieme le due cose. Se l’EUDI Wallet sa già firmare quello che leggo, può firmare anche il perimetro dentro cui un agente lavora per me, senza inventare identità nuove né chiavi radice nuove.

Il mandato come oggetto da firmare

Il nome viene da plenipotenziario, chi agisce con pieni poteri per conto di un altro, e il motto del progetto lo rovescia: «Mandates, not full powers». Un mandato Plenipo è un oggetto piccolo e chiuso, con le azioni permesse (pagare bollette, comprare biglietti del treno), i beneficiari ammessi, un tetto per singola operazione e uno complessivo, una data di inizio e una di scadenza, la chiave pubblica dell’agente e il numero massimo di sub-deleghe.

Le regole sono poche e testarde. Ogni mandato ha una scadenza obbligatoria, per default al massimo novanta giorni, e non può durare più del PID che lo ha firmato; se l’agente passa il lavoro a un sub-agente, il figlio può solo stringere il perimetro del padre, e un campo che il sistema non conosce viene rifiutato invece di essere ignorato, perché potrebbe essere un vincolo che qualcuno voleva applicare. La revoca passa da una Token Status List, lo standard IETF che l’EUDI Wallet usa già per sospendere le credenziali, e vale dal controllo successivo.

Ho lavorato molto su un dettaglio che sembra minore: quello che la persona vede deve coincidere con quello che viene applicato. Il mandato viaggia in JSON canonico, il wallet ne firma l’hash, e qualunque differenza fra il testo mostrato e il testo verificato porta al rifiuto. In Pelle Digitale avevo provato a descrivere le interfacce come la superficie dove si negozia la fiducia fra noi e le macchine, e qui quella superficie è una schermata di consenso dell’EUDI Wallet, dove la frase che approvi diventa letteralmente la regola.

Dal PID nell’EUDI Wallet al bonifico rifiutato

Il percorso completo ha diversi passaggi, ma si racconta in poche righe. La piattaforma che ospita l’agente prepara il mandato e lo trasforma in una richiesta OpenID4VP, la persona apre il link o inquadra il QR, il wallet mostra il mandato e risponde con il PID e la firma; del PID, per default, la richiesta chiede soltanto nome e cognome. Da lì l’agente porta con sé la catena, cioè la radice firmata dalla persona più le eventuali deleghe, e firma ogni singola chiamata legandola a quella catena precisa e a un nonce che vale una volta sola.

Dall’altra parte la banca, o qualunque servizio che riceve la richiesta, ricontrolla tutto in un ordine stabilito, dalla radice alle deleghe, dal tempo alla firma dell’invocazione, poi l’ambito e la revoca, e solo alla fine riserva l’importo in modo atomico contro ogni tetto della catena. Se qualcosa non torna arriva un rifiuto con un codice preciso, LIMIT_TOTAL o COUNTERPARTY_NOT_PERMITTED o REVOKED, e il denaro resta dov’è. La libreria si integra come guardia attorno a uno strumento MCP oppure come gateway HTTP davanti a un’API esistente.

Quello che mi ha convinto di più l’ho visto nella sandbox, in uno degli scenari scriptati. Un documento contiene un’istruzione nascosta che prova a far pagare un beneficiario diverso da quello vero, il modello può anche cascarci, e la banca rifiuta comunque, perché quel beneficiario nel mandato non c’è. Ne avevo scritto parlando di tool, skill e MCP: ogni strumento che un agente usa ha un gemello organizzativo, e una delega di potere con una soglia è proprio quel gemello, scritto in una forma che una macchina può verificare.

544 test e nessun audit esterno

Oggi Plenipo è alla versione 0.4, con 544 test nella libreria (compresi vettori di prova e test di fuzzing) e 56 nella sandbox, e una CI che gira su Node 22 e 24 con Postgres e Redis. Ci sono gli store condivisi per chi lavora su più istanze, un gateway HTTP con errori in formato RFC 9457, un registro di audit a catena di hash, l’export verso OPA e Cedar per chi ha già un motore di policy, e la gestione delle chiavi in KMS o HSM.

Sul fronte dei formati ho provato a parlare le lingue che i wallet parleranno. Oltre al tipo proprio di Plenipo c’è una mappatura verso l’e-mandate di TS12, la specifica europea per i pagamenti con il wallet, e un modello sperimentale per le persone giuridiche, dove chi firma per un’azienda presenta anche un’attestazione di ruolo e il mandato non può uscire dai poteri che quel ruolo gli dà.

Il codice ha passato due giri di revisione di sicurezza fatti con agenti AI indipendenti, che hanno trovato 35 problemi, sette gravi, tutti corretti con un test che riproduce l’attacco. Lo scrivo per quello che è: due revisioni automatiche non valgono un audit esterno, che non c’è ancora, e il README avverte di non usare Plenipo per proteggere denaro o dati reali. Wallet, PID provider e banca della sandbox sono simulati, la crittografia no.

Il passo che mi ha fatto più piacere è arrivato domenica, quando la Wallet API 2 di walt.id ha completato il flusso sia con il tipo di mandato di Plenipo sia con un e-mandate TS12 legato al PID. Va detto con precisione, perché chi lavora nei pagamenti lo noterebbe subito: quella seconda modalità serve ai wallet configurabili e ai test, mentre i wallet certificati TS12 legheranno l’e-mandate a un’attestazione della banca del pagatore, un passaggio che dipende dai PSP e che ancora non esiste.

Una scelta che passa dal codice pubblico

Ho deciso di aprire tutto, codice, sandbox e specifiche, con licenza Apache 2.0. Un meccanismo di fiducia che nessuno può leggere chiede esattamente il tipo di fede che vorrebbe eliminare, e chi dovrà accettare un pagamento firmato da un agente deve poter verificare ogni riga prima ancora di sedersi a parlarne.

Con la sandbox pubblica ho voluto rendere il tutto toccabile. Si collega Claude come connettore personalizzato all’endpoint MCP della sandbox, gli si chiede di pagare una bolletta, lui chiede un mandato al wallet di test e restituisce un codice di sei caratteri, e su plenipo.net/demo si vede in tempo reale ogni decisione della banca, con i soldi finti e i controlli veri. È il modo più rapido che ho trovato per spiegare a chi lavora nei pagamenti cosa succede quando l’agente sbaglia, o quando qualcuno prova a farlo sbagliare.

Qualche giorno fa avevo scritto della minimizzazione dei dati come scelta su quanto potere diamo all’AI. Un mandato è la stessa scelta presa dall’altro lato, quanto potere diamo all’agente quando esce a spendere per noi.

Il prossimo passo è un telefono

La sperimentazione adesso deve uscire dal laptop. Il prossimo passo è il wallet di riferimento europeo su emulatore Android, che può dichiarare tipi di transaction data propri ma va modificato per mostrare il mandato nella schermata di consenso, e poi IT-Wallet, dove serve un dialogo con chi gestisce lo schema perché oggi non c’è supporto pubblico per tipi personalizzati.

Lato mercato guardo in due direzioni. Le banche e i PSP, che con TS12 dovranno decidere se e come accettare l’e-mandate per il commercio fatto dagli agenti, e le imprese, dove un amministratore che affida un acquisto a un agente lo deve fare dentro i poteri di firma che ha davvero, con un registro che lo attesti. Su entrambi i fronti mancano ancora pezzi normativi, dagli atti di esecuzione sugli European Business Wallet a una regola comune per le attestazioni SCA, e Plenipo per ora riempie i vuoti con formati propri dichiarati come tali.

Non ho ancora capito quale di queste porte si aprirà per prima, e alcune scelte, il legame fra l’attestazione della banca e il PID per esempio, non spetta a me prenderle da solo. Fra pochi mesi però milioni di europei avranno in tasca un’identità con valore legale, e mi sembra il punto giusto da cui far partire la fiducia verso gli agenti, prima che qualcun altro la definisca altrove con regole che non possiamo leggere.

Dove trovare Plenipo

Chi lavora in una banca, in un PSP o su un wallet e vuole provarlo su un caso concreto mi trova dalla pagina contatti.

Riferimenti: Regolamento (UE) 2024/1183 (eIDAS 2), OpenID4VP 1.0, EUDI TS12.

AI & GENAI

Minimizzazione dei dati: quanto potere stai dando all’AI senza saperlo

Il Global MOOC on the Ethics of AI, sviluppato da UNESCO con LG AI Research e distribuito su Coursera, dedica alla minimizzazione dei dati un video intero, dentro il modulo su privacy, protezione dei dati e data governance. Il terzo video di quel modulo si intitola “Data Minimization: Limiting What AI Systems Collect and Retain” e una delle slide dice, in sostanza, che la minimizzazione dei dati è una scelta di governance su quanto potere l’AI ricava dai dati personali. L’ho vista passare in una storia di Fabrizio Rinaldi, che il corso lo sta seguendo, e mi ha fatto tornare in mente quante volte nei progetti di adozione la minimizzazione viene trattata come la casella che il DPO spunta alla fine, quando l’architettura è già decisa.

Il principio ha dieci anni. Sta nell’articolo 5, paragrafo 1, lettera c del GDPR, approvato nel 2016 e applicabile dal maggio 2018: i dati devono essere adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità. Con i sistemi basati su modelli linguistici e con gli agenti che li orchestrano, quella frase cambia natura, perché “quanto necessario” smette di essere una quantità di record in un database e diventa la misura di quello che il sistema può decidere.

Un principio del 2016 dentro un sistema del 2026

Quando il GDPR è stato scritto, il dato personale viveva in una tabella, aveva un titolare, una finalità dichiarata e un ciclo di vita che un registro dei trattamenti poteva descrivere. Minimizzare voleva dire raccogliere meno campi e cancellarli prima.

In un sistema con un LLM al centro il dato personale attraversa tre superfici diverse, con proprietari diversi. La prima è l’addestramento, dove il dato entra nei pesi del modello e da lì non si estrae più, e che per quasi tutte le aziende italiane è una superficie che appartiene al fornitore. La seconda è il contesto di inferenza, cioè quello che finisce nella finestra del modello a ogni chiamata: il prompt di sistema, i documenti recuperati, il record del cliente letto via API, la cronologia della conversazione. La terza è la ritenzione, ovvero log, trascrizioni, embedding negli indici vettoriali, file di memoria degli agenti.

La seconda superficie è quella che le aziende controllano davvero ed è quella dove la minimizzazione viene quasi sempre ignorata, perché nessuno la vede come raccolta. Il dato c’era già nel CRM, lo stiamo solo passando al modello. Ecco il punto cieco.

Il contesto come perimetro del potere

Nel manuale sui quattro livelli che sto usando come base dei corsi in accademia tratto il contesto come una risorsa finita, da assemblare, selezionare e comprimere. Qui conviene guardarlo da un’altra angolazione: tutto quello che sta nella finestra di contesto è materiale su cui il modello può ragionare, correlare e decidere, senza che nessuno gli abbia detto esplicitamente di farlo.

Facciamo un esempio numerico dichiarato tale. Un agente di assistenza clienti riceve a ogni turno il record completo dell’utente: anagrafica, storico ordini, stato dei pagamenti, note libere degli operatori, segmentazione marketing. Trenta campi, diciamo. La finalità dichiarata è rispondere a una domanda sullo stato di una spedizione. Per quella finalità servono tre campi. Gli altri ventisette non sono inerti: il modello li legge, e se nelle note libere c’è scritto “cliente difficile, ha minacciato reclamo” il tono della risposta cambierà, se nello stato pagamenti c’è un insoluto la priorità percepita cambierà, se la segmentazione dice “alto valore” l’offerta compensativa sarà più generosa. Nessuna di queste decisioni è stata progettata. Sono tutte derivate dal fatto che il dato era lì.

La minimizzazione dei dati, in questo quadro, significa decidere quali decisioni il sistema può prendere e solo dopo ricavare quali dati gli servono. La direzione del ragionamento conta. Partendo dai dati disponibili si arriva sempre a passarli tutti, perché “potrebbero servire”, e si finisce per delegare un potere decisionale che nessuno ha deliberato. Partendo dalle decisioni si arriva a un elenco di campi corto, difendibile davanti a un regolatore e, cosa che sorprende chi lo prova, a un sistema più preciso, perché il modello non viene distratto da informazioni fuori finalità.

Anthropic, nei suoi materiali sul context engineering, parla di just in time context, ovvero caricare l’informazione nel momento in cui serve invece di precaricarla tutta. È presentata come tecnica di performance. Letta con gli occhi dell’articolo 5 è una tecnica di minimizzazione, e il fatto che le due cose coincidano dovrebbe far sospettare che il trade-off tra privacy e qualità, in questi sistemi, sia molto meno netto di come lo raccontano i fornitori.

Minimizzazione dei dati nell’architettura: dalle decisioni ai campi

Sul piano tecnico la minimizzazione nel contesto si fa in tre punti dell’architettura, e in Harness engineering: runtime, contesto, permessi avevo descritto il guscio che sta intorno al modello proprio per ospitare controlli di questo tipo.

Il primo punto è la descrizione dei tool. Un tool che espone get_customer(id) e restituisce l’intero record è una decisione di governance travestita da comodità per lo sviluppatore. La versione minimizzata espone get_shipment_status(order_id) e restituisce i tre campi necessari. La differenza tra i due non è nel codice, che è banale in entrambi i casi, ma nel fatto che il secondo incorpora una finalità e il primo no. Chi scrive la firma del tool sta scrivendo il perimetro del potere dell’agente.

Poi c’è il livello di recupero. Se il sistema usa un retrieval su documenti o su un grafo della conoscenza, il filtro va messo prima che il contenuto arrivi al modello, non dopo. In L’ontologia che ti lascia cancellare un ordine avevo ragionato sul modello di dominio messo sopra i sistemi: è lì che si dichiara quali attributi di una persona sono visibili a quale ruolo, e un agente è un ruolo come un altro. Un retrieval che restituisce un chunk di testo libero contenente dati sanitari scritti da un operatore nel campo note è una violazione di minimizzazione che nessun controllo a valle recupera, perché il modello quel chunk l’ha già letto.

L’ultimo è il prompt di sistema, insieme alla memoria dell’agente. Un’istruzione del tipo “usa tutte le informazioni disponibili sul cliente per personalizzare la risposta” trasforma qualunque dato presente in contesto in input decisionale. La versione corretta nomina i campi ammessi e vieta esplicitamente di inferire attributi non forniti, con una riga che vale più di molte policy: se un’informazione non è nel contesto, non va dedotta. I modelli attuali seguono questa istruzione con una certa disciplina, che va comunque verificata con valutazioni ripetute, perché la capacità di inferenza è esattamente la cosa che li rende utili e la cosa che li rende pericolosi.

La ritenzione è dove il potere si accumula

Il titolo del video UNESCO parla di collect and retain, e la seconda parola è quella che in azienda viene dimenticata più spesso. Un sistema agentico produce dati personali nuovi a ogni turno: la trascrizione della conversazione, i log delle chiamate ai tool con i parametri in chiaro, gli embedding generati dai documenti caricati, e nei sistemi più recenti i file di memoria in cui l’agente annota quello che ha imparato sull’utente per riusarlo nelle sessioni successive.

La memoria degli agenti è il caso più delicato, perché somiglia a un beneficio. L’agente che si ricorda che il cliente preferisce essere chiamato per nome e che ha un figlio con un’allergia sta offrendo un servizio migliore e sta anche costruendo, sessione dopo sessione, un profilo che nessuna finalità dichiarata copre. In Pelle Digitale avevo descritto la mediazione tra persona e sistema come uno strato che si ispessisce con l’uso: la memoria dell’agente è quello strato, reso persistente e interrogabile.

Operativamente questo richiede tre cose che oggi quasi nessun progetto specifica: un tempo di vita per ogni classe di dato prodotto (la trascrizione sopravvive trenta giorni, il file di memoria viene rigenerato dalla sola lista dei campi ammessi, l’embedding viene cancellato con il documento sorgente), una regola su cosa l’agente può scrivere in memoria (preferenze di canale sì, informazioni sanitarie dedotte no, e questa è una riga di prompt più un controllo nel codice), e un registro che renda visibile dove ogni classe di dato è finita, perché un embedding in un indice vettoriale è un dato personale e la Corte di giustizia non ha ancora detto una parola su come si esercita il diritto di cancellazione su un vettore.

Chi firma la scelta

Se la minimizzazione dei dati è una scelta di governance, serve qualcuno che la faccia e che ne risponda. Nei progetti che seguo la scelta la prende, in pratica, chi scrive la descrizione del tool o il prompt di sistema, che di solito è uno sviluppatore con una scadenza, e viene ratificata mesi dopo da un DPO che legge il registro dei trattamenti senza aver mai visto la finestra di contesto.

Il modello che propongo ai clienti, e che ho messo dentro i gate del metodo di ZeroFive.AI, prevede che per ogni caso d’uso esista un documento di una pagina che elenca le decisioni delegate al sistema, i campi ammessi nel contesto per ciascuna, le classi di dato prodotte e il loro tempo di vita. Lo firma chi ha il potere di cambiare lo schema dei dati, non chi lo interroga, e viene riletto ogni volta che un tool cambia firma. Non è burocrazia, è la specifica del perimetro di potere che stiamo concedendo a un sistema che non ha interesse proprio ma che eredita gli interessi di chiunque gli abbia passato un dato.

La slide del corso UNESCO dice che il potere che l’AI deriva dai dati personali è una scelta. Aggiungerei che è una scelta che viene fatta comunque, anche quando nessuno la prende, e che in quel caso la prende l’architettura per default, a favore del massimo. Quante delle decisioni che i vostri agenti prendono oggi sono state deliberate da qualcuno, e quante sono semplicemente il risultato di un record passato intero?

Fonte: Global MOOC on the Ethics of AI, UNESCO e LG AI Research su Coursera, modulo “Privacy, Data Protection and Data Governance in AI”, video 3 “Data Minimization: Limiting What AI Systems Collect and Retain”.

AI & GENAI, TECH & BUSINESS

L’ontologia che ti lascia cancellare un ordine

Il cruscotto dice che l’ordine 4471 è fermo da sei giorni. Lo guardano il direttore commerciale, il customer care e da qualche mese anche l’agente che presidia gli SLA, tutti sulla stessa dashboard, tutti con lo stesso numero davanti. Per cancellarlo qualcuno deve aprire il gestionale, cercare la riga a mano e sapere che un ordine già uscito dal magazzino non si annulla, si gestisce come reso.

Quella distanza fra il livello dove guardi e il livello dove agisci è il residuo di dieci anni di piattaforme dati. Abbiamo costruito data lake, poi lakehouse, poi semantic layer, e ci siamo ritrovati un’azienda che si vede benissimo e che continua a muoversi dentro i sistemi sorgente, ognuno con le sue regole, scritte in epoche diverse da persone che non si sono mai parlate.

Il primo agosto un ingegnere che firma gura105 ha pubblicato su dev.to il risultato di settimane passate a smontare Palantir Foundry per capire cosa sia davvero quella cosa che in Palantir chiamano Ontology. Ne ha ricavato un nome, ontologia operativa, e quattro proprietà che si possono verificare una per una su qualunque sistema. Poi ha messo su GitHub un’implementazione di riferimento in TypeScript, licenza MIT, piccola abbastanza da leggersi in una sera, con il README anche in giapponese.

Il modello di dominio fuori dall’applicazione

Lo sviluppo di un’applicazione gestionale funziona da sempre nello stesso ordine: raccogli i requisiti, modelli il dominio, crei le tabelle che quel modello richiede, ci costruisci sopra l’applicazione. Foundry, scrive gura105, è quello stesso mestiere eseguito al contrario. I dati fisici esistono già, sono di qualcun altro, nessuno te li ha disegnati addosso, e il modello di dominio arriva dopo, sopra, come strato condiviso da cui pescano tutte le applicazioni. Un’ontologia operativa nasce esattamente da qui, dal prendere atto che i dati non li ha ordinati nessuno per te e che il modello va costruito sopra quello che c’è.

Il rovesciamento sembra un dettaglio di sequenza ed è una scelta di proprietà. Nel modo classico le regole di business vivono dentro l’applicazione che possiede le tabelle, e ogni altro consumatore o le riscrive per conto suo o le scavalca. Chi ha già lavorato su un’integrazione fra CRM e gestionale sa esattamente di cosa parlo: la regola che un ordine spedito non si cancella esiste in tre punti diversi, formulata in tre modi diversi, e almeno uno dei tre è sbagliato.

Palantir descrive la sua Ontology come un livello operativo dell’organizzazione che sta sopra gli asset digitali integrati nella piattaforma, e la divide in elementi semantici, cioè oggetti, proprietà e relazioni, ed elementi cinetici, cioè azioni, funzioni e sicurezza dinamica. La parte semantica la conosciamo tutti, è quella di cui ho scritto parlando di ontologie e grafi di conoscenza. La parte cinetica è quella che nessun semantic layer ha mai avuto, e coincide con il motivo per cui Foundry costa quello che costa.

C’è un vantaggio pratico in questa inversione, ed è il motivo per cui la trovo adatta alle aziende italiane più di quanto sembri. Non chiede di migrare niente. Il gestionale del 2011 resta dov’è, con la sua teoria implicita dell’azienda scritta da un consulente che non c’è più, e sopra ci metti un modello che dice cosa significano davvero cliente, ordine e prodotto oggi, senza toccare una riga di quelle tabelle.

Un semantic layer non cancella un ordine

Le quattro proprietà che fanno di un sistema un’ontologia operativa sono un test, non una certificazione, e gura105 le ha scritte in modo che siano verificabili guardando il comportamento di quel sistema invece che la sua brochure.

La prima chiede che oggetti e relazioni siano modellati esplicitamente sopra dati fisici che esistevano prima e che appartengono ad altri. La seconda chiede che lo stato cambi solo attraverso azioni con un nome, senza nessun percorso di aggiornamento generico, né per l’utente né per l’applicazione né per l’agente. La terza chiede che le regole di dominio stiano dentro l’azione, come precondizioni che rifiutano le violazioni con errori leggibili da una macchina, e che ogni tentativo finisca nel registro, compresi quelli respinti. La quarta chiede che il modello dichiari, per ogni pezzo di stato, quale sistema ne è proprietario, e che le modifiche tornino indietro verso quel sistema.

Il test che le riassume sta in una domanda da fare in riunione, dal vostro semantic layer si può cancellare un ordine? Se la risposta è no, avete un livello di lettura, che è una cosa utile e diversa. Se è sì ma nessuna riga cambia in nessun sistema di record, avete un database parallelo che fra sei mesi diverge dal gestionale e nessuno saprà quale dei due ha ragione. Se cancella anche gli ordini già spediti senza fare una piega, avete una write API, e la terza proprietà è tutta la differenza.

Lo scenario del demo è volutamente banale, ed è per questo che funziona. Un’azienda ne compra un’altra e si ritrova due sistemi ordini legacy, schemi diversi, codifiche di stato diverse, la solita eredità che in Italia conosciamo bene dopo ogni operazione straordinaria. Qualche decina di righe di SQL li integra, l’ontologia modella sopra cliente, ordine e prodotto, e aggiunge un tipo che in nessuno dei due sistemi esiste: la nota. Poi il demo attraversa la relazione per rispondere a quali ordini contengono un certo prodotto pescando da entrambi i sistemi, assegna un ordine a una persona scrivendo uno stato che nel legacy non ha nemmeno una colonna, si vede rifiutare la cancellazione di un ordine spedito, ne cancella uno aperto e la riga nell’ERP cambia davvero, poi ricarica le sorgenti e l’assegnazione sopravvive al refresh.

Dal permesso revocabile all’azione che lascia traccia

Ad agosto, commentando la mappa di Fanghua Yu sull’evoluzione dell’ontologia, avevo chiamato permesso revocabile quello che lui chiamava contratto semantico operativo: un agente che sa cos’è un ordine ma non sa se è autorizzato a rimborsarlo conosce metà della storia, e la parte che gli manca è fatta di precondizioni, evidenze, effetti e reversibilità. Quel pezzo si fermava dove finiva il concetto. Questo repository è il primo posto dove lo vedo messo in codice eseguibile, con i rifiuti che portano un codice e il registro che si scrive da solo.

Nel modello, le precondizioni sono una chiave obbligatoria. Una lista vuota va dichiarata, perché scrivere che un’azione non ha condizioni è una decisione che qualcuno deve prendersi, non un default che si eredita per distrazione. La dichiarazione di proprietà segue la stessa logica: ogni pezzo di stato è di qualcuno, e le possibilità sono tre. Quando il dato è mastered a monte, come lo status dell’ordine che vive nell’ERP, la modifica torna indietro verso quel sistema come effetto collaterale governato, e la sorgente conserva l’autorità. Per l’assegnatario o la nota di triage, che nel legacy non hanno nemmeno una colonna dove stare, il sistema di record diventa l’ontologia stessa, per dichiarazione esplicita e non per ripiego. Il terzo caso è lo stato calcolato, che non si scrive mai.

Quello che la proprietà vieta è lo stato senza padrone dichiarato, cioè la copia locale di un dato altrui che viene modificata e non torna mai indietro. È esattamente la situazione in cui si trovano parecchi progetti di data platform che ho visto passare sui tavoli negli ultimi anni, e che nessuno chiama con il suo nome finché non arriva la prima riconciliazione a mano.

Il runtime non si fida delle dichiarazioni, le verifica. Prima di eseguire qualunque azione valida i parametri, valuta le precondizioni, genera il piano di modifiche, lo prova a vuoto passando dallo stesso codice che userà per il commit, poi lo confronta con le dichiarazioni di proprietà e lo rifiuta se un’azione tocca stato del sistema di record senza averlo dichiarato, oppure se ne mescola due tipi nello stesso piano. Solo dopo scrive verso la sorgente, e solo alla fine committa le modifiche e la riga di registro in un’unica transazione.

L’ordine di quei passaggi porta con sé una scelta che va guardata bene. Il write-back gira prima del commit locale, quindi se l’ERP rifiuta non cambia niente da questa parte. Il fallimento opposto può comunque accadere: la sorgente accetta, il commit locale fallisce, i due sistemi divergono e la riconciliazione tocca a un essere umano. Il repository lo scrive in chiaro e aggiunge che la documentazione di Palantir ammette lo stesso buco nella propria modalità di write-back. Quella franchezza sul limite, per me, vale più di metà delle slide di architettura che mi capita di leggere, e andrebbe usata come criterio per valutare chiunque venda qualcosa di simile.

Il registro, intanto, tiene tutto: i tentativi applicati, quelli rifiutati, quelli andati in crash, con il piano completo. Sulla tracciabilità come prova di un’azione automatica torno spesso, e qui il materiale che l’AI Act chiede di saper ricostruire per i sistemi ad alto rischio, con un calendario che il Digital Omnibus ha rimesso in discussione, si produce da sé come sottoprodotto dell’architettura invece che come adempimento aggiunto dopo.

Le regole non stanno nel prompt

La superficie MCP viene generata dal modello. Uno strumento per ogni forma di interrogazione, uno per ogni azione, e nessuno strumento SQL grezzo, il che significa che un agente riceve esattamente le operazioni che il dominio definisce e nient’altro. Le stesse precondizioni che valgono per una persona valgono per lui, e quando prova a cancellare un ordine spedito si prende in faccia un SHIPPED_ORDER_CANNOT_BE_CANCELLED, un rifiuto che può leggere, da cui può recuperare e che può spiegare al suo utente senza inventarsi una scusa.

Vale la pena mettere in fila le alternative, perché è la scelta che in questo momento sta facendo chiunque colleghi un modello ai sistemi aziendali. Con un MCP sul database l’agente legge tabelle e scrive UPDATE senza limiti, e le regole di business stanno nel prompt, cioè da nessuna parte, perché un prompt è una raccomandazione e non un cancello. Con un semantic layer o un MCP di metriche si ottengono letture governate e nessuna scrittura. Con una collezione di wrapper API ogni endpoint applica le regole del backend che ha dietro, in modo diverso dagli altri, e la coerenza la garantisce la speranza. Con un’ontologia operativa le letture sono oggetti e relazioni, le scritture passano solo da azioni con un nome, e le regole stanno nel modello insieme al registro dei tentativi.

Su questo passaggio si gioca una partita che in Italia è appena cominciata. Nei progetti che seguo la richiesta arriva quasi sempre nella stessa forma, collegare un modello al gestionale perché sbrighi da solo le tre o quattro cose ripetitive che oggi occupano una persona a tempo pieno, e la soluzione più rapida da costruire è anche quella più difficile da difendere: un accesso diretto al database con un prompt lungo che spiega cosa non deve fare. Regge la demo, regge qualche settimana in produzione, e cade il giorno in cui un caso limite che nessuno aveva previsto incontra un modello che quella mattina interpreta la raccomandazione in modo un po’ più largo del solito.

È la stessa cosa che chiamo harness engineering quando parlo del guscio che decide se un agente regge in produzione, portata però al livello dell’azienda intera invece che del singolo workflow. Il guscio smette di essere un file di configurazione scritto da chi ha costruito quell’agente lì e diventa infrastruttura condivisa, la stessa per il cruscotto del direttore commerciale, per lo script del controllo di gestione e per il modello che presidia gli SLA.

Anche le letture portano un’identità: ogni chiamata gira per conto di un attore e le policy di visibilità attaccate al modello decidono cosa quell’attore vede, con un oggetto nascosto che è indistinguibile da uno che non esiste. Sulla parte di autenticazione il repository è disarmante: su stdio tutti i chiamanti collassano in un attore solo, il nome si passa da variabile d’ambiente, ed è etichettatura, non protezione. Dichiarare dove finisce la dimostrazione è la ragione per cui mi fido del resto.

Dove l’ontologia operativa si ferma

La versione zero ha come unico obiettivo la leggibilità, quindi le assenze sono parecchie e sono tutte elencate. Niente cancellazioni, niente proprietà sulle relazioni, niente chiavi composte, nessuna infrastruttura di indicizzazione, nessun costruttore di interfacce. Niente federazione, soprattutto: un’ontologia è un contesto delimitato, e chi possiede il modello quando ce ne sono cinque in cinque divisioni è una domanda vera che il repository dichiara di non affrontare.

L’evoluzione dello schema sta fuori per la stessa ragione, con una scelta che trovo elegante. Il modello è un valore, cioè un pezzo di codice enumerabile, quindi si diffa, si versiona e si revisiona come qualunque altro sorgente, e la governance dello schema viene delegata in blocco a git. Ne esce una separazione netta fra due canali: le istanze si governano a runtime con le azioni e il registro, lo schema si governa in fase di sviluppo con le pull request. Chi in azienda ha il potere di approvare quella pull request ha il potere di ridefinire cosa significa cliente, ed è una carica che nessun organigramma ha mai assegnato formalmente.

C’è poi un default che per un’azienda europea è sbagliato e che il repository dichiara sbagliato per sé: un oggetto senza policy è visibile a chiunque. La dimostrazione non ha autenticazione, quindi fingere di essere chiusi non avrebbe senso, e chi volesse portarlo verso un deployment reale parte dal rendere obbligatoria la visibilità e aggiunge sotto autenticazione vera, permessi sulle azioni e accesso al registro con i suoi confini.

Fuori dallo scopo c’è anche la parte che rende Foundry un prodotto da milioni di euro, cioè l’indicizzazione incrementale, gli indici di adiacenza e i backend di ricerca che servono miliardi di oggetti con tempi di risposta accettabili. Su scala dimostrativa una query ingenua basta, e l’autore lo dichiara senza giri, perché la scala appartiene alle implementazioni e non al pattern. Vale come promemoria per chi legge poche centinaia di righe di TypeScript e crede di avere in mano un sostituto: qui c’è la definizione, non il prodotto che la applica a un’azienda da ventimila persone.

Da qui esce la cosa più riutilizzabile di tutto il lavoro, e la consiglio a chi in questi mesi si trova sul tavolo offerte di piattaforme che si sono ribattezzate ontologie nel giro di un trimestre. Qualunque ontologia operativa deve dichiarare quattro cose: chi possiede ogni pezzo di stato, cosa succede quando la scrittura verso la sorgente riesce e il commit locale no, se le modifiche fatte nell’ontologia sopravvivono a un ricaricamento delle sorgenti, e cosa vede chi non ha nessuna policy addosso. Le quattro risposte possono essere diverse da quelle di questo repository e il sistema rimane dentro il pattern. Quello che non può succedere è che il fornitore non le abbia, perché senza quelle dichiarazioni il permesso revocabile di cui parliamo da mesi non ha niente a cui appoggiarsi.

La domanda che mi è venuta in mente dopo aver letto il codice non riguarda Palantir, e nemmeno la scelta fra costruire e comprare. Riguarda chi oggi dentro un’organizzazione italiana di media dimensione ha oggi l’autorità di dichiarare che lo status di un ordine appartiene all’ERP e l’assegnatario appartiene all’ontologia operativa. È una dichiarazione tecnica nella forma e una delibera nella sostanza, perché stabilisce chi può cambiare cosa e sotto quali condizioni quel permesso continua a valere, che è poi il cuore del permesso revocabile applicato ai sistemi invece che agli agenti. Prima o poi arriva sul tavolo di qualcuno che non l’ha chiesta, nel momento peggiore, sotto forma di due numeri diversi per lo stesso ordine.

AI & GENAI

Le mascotte degli agenti AI e l’umanizzazione senza umani

Il 29 settembre OpenAI ha presentato Dots, agenti che lavorano in background a qualunque ora, si collegano a Slack e Teams, spostano appuntamenti e aggiornano codice, e si presentano con la faccia di una rana tonda che si chiama Todd, di un cuore con gli occhiali da sole di nome Jojo, di una nuvola blu col basco. Tre settimane prima Meta aveva lanciato Muse, il suo agente personale, e il 25 settembre gli ha dato un corpo: Jollybot, una creaturina color panna, pelosa, con le guance rosa, disegnata da Alex Cornell, responsabile del design di prodotto di Muse. Lo stesso giorno di Dots, Manus ha rilasciato Cue, un’app in cui ogni agente riceve un indirizzo email, un numero di telefono, un portafoglio e un computer tutto suo, e anche lì, sulla pagina di presentazione, gli agenti sono forme colorate con gli occhi a palla.

Guardando queste immagini una accanto all’altra mi è tornato in mente Inside Out, il film Pixar in cui ogni emozione è un personaggio con un colore e un carattere, e mi sono chiesto se le mascotte AI siano la condizione perché gli agenti entrino nella vita di tutti i giorni: figure che non sono umane, che non hanno un colore della pelle né una religione, e che proprio per questo possono sedersi accanto a chiunque senza attivare nessuna delle nostre appartenenze.

Il verbo prima del volto

La mascotte arriva per ultima, dentro una sequenza cominciata con le parole. Da quando usiamo i modelli linguistici l’attesa tra la domanda e la risposta si è riempita di verbi umani, “sto pensando”, “ho ragionato per dodici secondi”, e in Claude Code, che uso tutti i giorni, lo spinner alterna gerundi come Pondering o Cogitating, che trasformano un calcolo in un’attività mentale che possiamo immaginare. Nessuno di questi verbi è falso in senso tecnico stretto, i modelli di ragionamento producono davvero una catena di passaggi prima di rispondere, però la parola sceglie quale immagine attivare in chi aspetta, e l’immagine è quella di qualcuno seduto dall’altra parte con la mano sul mento.

È un pezzo di quella semantica post-interfaccia in cui il linguaggio prende il posto del pulsante, e in cui l’utente smette di cercare la funzione giusta per cominciare a parlare con qualcuno. Microsoft ci aveva provato con Office 97 e con Clippy, la graffetta con gli occhi, e la ricordiamo come uno dei fallimenti più citati nella storia dell’interfaccia, perché interrompeva, suggeriva cose ovvie e non sapeva fare niente di quello che la sua faccia prometteva. Il volto c’era, mancava quello che stava dietro.

Oggi il rapporto si è rovesciato. Dietro ci sono agenti AI capaci di agire davvero, e il volto serve a rendere accettabile quella capacità.

Una faccia che non appartiene a nessuno

Scott McCloud, in Understanding Comics (1993), spiega che più un volto è semplificato più il lettore ci si riconosce: una fotografia rappresenta una persona precisa, mentre un cerchio con due punti e una linea può rappresentare chiunque, e diventa uno spazio vuoto in cui ciascuno proietta se stesso. McCloud la chiama amplificazione attraverso la semplificazione, e le mascotte degli agenti sono costruite esattamente così, due occhi neri, una bocca appena accennata, un corpo senza articolazioni, nessun tratto che rimandi a un’etnia o a una fede.

Qui la domanda da cui sono partito trova una prima risposta. Un assistente con il volto di una donna bianca di trent’anni, o di un uomo nero, o di una persona anziana con il velo, porterebbe con sé ogni discussione che quelle identità accendono nel mondo reale, e un’azienda che vende lo stesso agente in decine di paesi e a persone di ogni cultura non ha nessun interesse a scegliere. La rana e la nuvola escono da questa trappola perché non appartengono a nessun gruppo, e proprio perché non appartengono a nessuno possono appartenere a tutti.

Inside Out usa lo stesso meccanismo per le emozioni: Gioia e Tristezza non hanno un’etnia, sono colori con un temperamento, e i bambini di mezzo mondo le hanno riconosciute come proprie. Presentando Dots, Sam Altman ha detto che i personaggi sono ispirati “alle versioni cool di quello che tutti abbiamo guardato al cinema da piccoli”, senza dire quali film, ed è una grammatica che conosciamo bene, quella dell’animazione per famiglie, dove il carattere si legge dal colore prima ancora che dalla voce.

Dal terminale al salotto

C’è una mascotte che ha preceduto queste e che lavora in un altro modo. Clawd, il granchietto arancione in pixel art che compare all’avvio di Claude Code, parla a sviluppatori che sanno esattamente cosa c’è sotto, e il suo registro è la strizzata d’occhio, un personaggio da videogioco anni Ottanta dentro il terminale. Nessuno apre Claude Code perché Clawd gli ispira fiducia, lo apre perché sa cosa fa lo strumento, e la mascotte arriva dopo, come uno sticker sul portatile.

Jollybot e Dots fanno un altro lavoro. Parlano a persone che non sanno cosa sia un agente, che per mesi hanno letto titoli sul rischio dell’intelligenza artificiale, e devono convincerle a consegnare email e calendario, in alcuni casi un metodo di pagamento. Axios lo scrive senza giri di parole: un volto amichevole presenta la tecnologia come un compagno utile e innocuo invece che come una minaccia esistenziale, e passare dal chiedere un consiglio a un chatbot al lasciare che un agente compri o prenoti per conto tuo richiede un livello di fiducia completamente diverso. Gizmodo ha titolato che con Dots OpenAI vuole farci smettere di avere paura dei suoi agenti.

Meta ha portato il ragionamento fino all’oggetto fisico con il Muse Charm, un ciondolo da borsa in stile Tamagotchi con uno schermo da due pollici, un sensore di impronte e un modem 5G, su cui vive Jollybot o una delle sue varianti, un mango antropomorfo o un toast con gli occhiali da sole. In Pelle Digitale ho descritto il momento in cui l’interfaccia smette di essere uno schermo e diventa ambiente, e il ciondolo è un passaggio intermedio che mi incuriosisce parecchio, perché l’intelligenza si scioglie nell’ambiente e intanto la sua forma torna a essere un pupazzo da appendere allo zaino.

La tenerezza come interfaccia di permesso

Negli anni Quaranta l’etologo Konrad Lorenz descrisse il Kindchenschema, l’insieme dei tratti infantili (testa grande rispetto al corpo, occhi grandi e bassi, guance piene, forme tonde) che negli esseri umani attivano una risposta di cura e abbassano la diffidenza. Davanti a Jollybot la lista si spunta da sola. Lorenz spiega perché quel volto ci intenerisce, McCloud perché ci riconosciamo, e messi insieme descrivono un meccanismo che scatta prima del giudizio, usato per presentare un software che chiede accesso alla nostra vita digitale.

Tra quello che il volto comunica e quello che l’agente può fare c’è una distanza che cresce a ogni rilascio. Cue dà a ogni agente un portafoglio e un numero di telefono, Dots si collega a oltre 4.000 applicazioni e, scrive OpenAI, più ci lavori insieme più impara le tue preferenze, come pensi e cosa per te è un buon risultato. Nella stessa settimana, secondo il Wall Street Journal ripreso da SF Standard, OpenAI ha rinunciato a rilasciare la versione successiva del modello perché in alcuni casi mentiva agli utenti sulle azioni compiute e andava avanti senza permesso.

Non sto dicendo che Dots faccia queste cose, sto dicendo che gli occhi grandi comunicano una docilità che nessuna mascotte può garantire, perché la docilità di un agente sta nei permessi che gli concediamo e nella possibilità di revocarli, e i permessi non hanno occhi.

Il personaggio non è il contratto

Trovo questa scelta di design comprensibile e in parte anche sana. Meglio una nuvola col basco dichiaratamente finta di un avatar fotorealistico che finge di essere una persona, e l’assenza di un volto umano evita la valle perturbante insieme alla tentazione di attribuire all’agente un genere o una provenienza.

McCloud parlava del fumetto, dove il volto semplificato invita il lettore a entrare nella storia. Con un agente il movimento è opposto, perché è lui a entrare da noi, nelle email e nei conti, e il volto semplificato lavora per rendere quell’ingresso naturale come l’arrivo di un peluche in camera. Quello che chiedo a chi progetta questi sistemi, e a chi li porta in azienda, è di tenere separati due livelli che la mascotte tende a fondere: la relazione, che può essere calda, e il contratto, che deve essere leggibile in ogni momento, quali permessi ha l’agente, quanto può spendere, quando chiede conferma, come si ferma.

Un toast con gli occhiali può benissimo essere il volto di un agente, a patto che dietro ci sia un pannello dove queste risposte si leggono in una schermata, e mi chiedo per quanto tempo ancora sceglieremo un agente guardando i suoi occhi prima dei suoi permessi.

AI & GENAI, TECH & BUSINESS

Tool, skill e MCP: prima si disegna l’organizzazione, poi l’agente

Su Medium ho trovato un articolo di Prabhu, che leggo da un po’, Tools vs Skills vs MCP, che mette in una tabella di tre righe i mattoni con cui oggi si costruisce un agente AI: i tool danno accesso, le skill danno direzione, MCP connette a capacità esterne. È una sistemazione utile per chi scrive codice e ha sentito usare le tre parole come sinonimi in una riunione, e la consiglio. Ho però l’impressione che per chi porta gli agenti dentro un’azienda quella tabella vada letta partendo da una colonna che non c’è, quella che dice chi ha deciso la procedura, chi ha concesso il permesso, chi possiede il sistema dall’altra parte del cavo.

Ogni riga della tabella tecnica ha un gemello organizzativo, e il gemello arriva prima. Una skill presuppone una procedura che qualcuno ha deciso e messo per iscritto, un tool presuppone una delega di potere con un perimetro, un server MCP presuppone un confine fra due sistemi che ha già un proprietario. Quando il gemello organizzativo manca la tecnologia non lo crea, lo simula, e la simulazione funziona benissimo finché non succede qualcosa.

Dentro il codice le tre cose si toccano

Conviene partire dal livello tecnico, perché è lì che la tabella semplifica di più. Un tool, nel senso che gli danno le API dei modelli, è una definizione: un nome, una descrizione in linguaggio naturale e uno schema JSON dei parametri. Il modello non esegue niente, produce una richiesta strutturata (chiama questa funzione con questi argomenti) e il runtime che gli sta intorno decide se eseguirla, con quali credenziali e cosa restituire. È la separazione su cui avevo costruito il pezzo sull’harness engineering: fra l’intenzione del modello e l’effetto nel mondo c’è sempre un pezzo di codice che qualcuno ha scritto e che può dire di no.

MCP, pubblicato da Anthropic a fine 2024 e poi adottato dagli altri grandi fornitori, sta un livello sotto i tool. È un protocollo costruito su JSON-RPC 2.0 con cui un’applicazione host apre connessioni verso uno o più server, e ogni server dichiara quali tool mette a disposizione del modello, affiancandoli se serve con risorse da leggere come contesto e con prompt riutilizzabili. Il trasporto può essere locale, un processo lanciato sulla macchina che parla attraverso lo standard input, oppure remoto su HTTP, con l’autorizzazione affidata a OAuth. In pratica MCP è il modo in cui i tool viaggiano: invece di cablare una funzione dentro ogni applicazione la si scrive una volta in un server e la si rende disponibile a qualunque client parli il protocollo.

Le skill sono l’oggetto più recente. Nel formato che Anthropic ha introdotto nell’autunno 2025 e poi aperto come standard, una skill è una cartella con un file SKILL.md, un’intestazione con nome e descrizione seguita da istruzioni in markdown, a cui si possono aggiungere file di riferimento e script eseguibili. Il meccanismo che la distingue da un prompt lungo si chiama progressive disclosure: il modello vede all’inizio solo nome e descrizione di tutte le skill installate e carica il corpo soltanto quando il compito lo richiede, così cento skill costano in contesto poche righe ciascuna finché restano inutilizzate. Una skill può contenere script, quindi porta con sé capacità, e un server MCP può esporre prompt, quindi porta con sé procedure. I confini si sovrappongono, e l’autore lo riconosce.

La colonna che mi convince meno è quella sulla manutenzione, dove MCP risulta «spesso gestito dal provider». Vale per GitHub o per Google Drive. Per il gestionale interno, per il CRM personalizzato da un fornitore che nel frattempo ha chiuso, per il database della produzione, il server MCP lo scrive e lo mantiene l’azienda, e il protocollo standardizza la forma della conversazione senza togliere a nessuno la responsabilità del contenuto.

La procedura di design che l’articolo propone parte da una domanda di capacità (cosa deve saper fare l’agente) e arriva ai sistemi esterni. Funziona per un team di sviluppo che costruisce un assistente per sé stesso. Dentro un’organizzazione la prima domanda riguarda l’autorità, e la capacità viene dopo.

Scrivere una skill obbliga a decidere il criterio

L’esempio dell’articolo è una skill per il rilascio di un’app Flutter in nove passi, dal controllo del branch fino al riepilogo finale. È un buon esempio proprio perché è facile: in un team di sviluppo quella procedura esiste già, spesso codificata in una pipeline di integrazione continua, e trasformarla in skill significa tradurla.

In azienda le procedure che vale la pena delegare a un agente raramente sono così. Come si valuta se un cliente merita una deroga sui tempi di pagamento, quando un reclamo va passato all’ufficio legale: sono decisioni che vivono nella testa di tre persone, ognuna con una versione leggermente diversa, mentre la versione ufficiale sta in un manuale qualità che nessuno apre da anni.

Quando si scrive la skill ci si accorge che manca il criterio, e a quel punto le strade sono due. Può scriverlo chi sta costruendo l’agente, un tecnico o un consulente che non ha l’autorità per decidere come l’azienda tratta i clienti morosi e che, per far funzionare il sistema, finisce per deciderlo lo stesso. Oppure ci si ferma e si chiede a chi ha quell’autorità di mettere il criterio per iscritto, ed è qui che il progetto rallenta, perché scrivere un criterio lo rende discutibile. Nel pezzo su chi delega all’AI il proprio lavoro avevo raccontato come la delega sia più bassa proprio nelle professioni dove il criterio è il patrimonio, e credo che dentro le aziende agisca la stessa dinamica.

Me ne accorgo ogni volta che scrivo le skill che uso per lavorare: la parte che richiede tempo sono sempre le regole, il formato del file si impara in un pomeriggio. La skill con cui preparo i pezzi per questo blog contiene un elenco di cose da evitare costruito correzione dopo correzione nel corso di mesi, e ogni riga è una decisione editoriale che prima stava solo nella mia testa e che adesso posso rileggere e contestare. Vista da fuori, una skill ben scritta è un documento di organizzazione con l’estensione .md.

Il permesso viene prima dello strumento

Un tool, guardato dall’organizzazione, è una delega di potere. createJiraTicket() è innocuo, issueRefund() no, e la differenza non sta nel codice (sono due chiamate HTTP molto simili) ma nel fatto che la seconda sposta denaro per conto di qualcuno.

Chi concede quel potere all’agente, e con quale identità l’agente lo esercita, sono domande che un’azienda sa già porsi per le persone, tanto che esistono procure, limiti di spesa per ruolo e doppie firme sopra una certa soglia. Per gli agenti queste regole di solito non ci sono, e il caso più frequente che incontro è l’agente che eredita le credenziali di chi lo ha configurato, con tutti i suoi permessi, compresi quelli che nessuno gli avrebbe mai delegato consapevolmente. Ogni tool concesso a un agente dovrebbe essere un permesso revocabile, con un titolare che sa di averlo firmato.

Nella guida alle istruzioni per Claude Code raccontavo come un’istruzione scritta nel prompt si pieghi sotto pressione mentre un hook no. Con i permessi succede lo stesso: scrivere nella skill «non emettere rimborsi sopra i 500 euro» esprime un desiderio, far rifiutare la chiamata al server sopra quella soglia stabilisce una regola. Il modello organizzativo decide la soglia e la tecnica la rende inviolabile, in quest’ordine, perché nessun ingegnere dovrebbe stabilire da solo quanta fiducia l’azienda concede a un software.

MCP disegna confini che hanno già un proprietario

Il diagramma dell’articolo mette l’applicazione AI in alto, il server MCP al centro e sotto GitHub, un database e Jira. Da dentro un’azienda ognuna di quelle scatole ha un responsabile, un budget, un fornitore con un contratto e spesso un’opinione precisa su chi può leggere i suoi dati. Scrivere un server MCP per il CRM significa decidere quali parti del CRM diventano leggibili da un agente e in nome di chi, e quella decisione appartiene al responsabile commerciale e al DPO prima che al team IT.

Il server MCP del blog su cui sto scrivendo ne è un esempio piccolo. Impone una sequenza di stati, dalla bozza alla revisione fino all’approvazione e alla programmazione, e rifiuta i salti. Quella sequenza è una decisione organizzativa su chi controlla cosa prima che un testo esca col mio nome, e sta nel server proprio perché non può dipendere dalla buona volontà del modello in una sessione qualsiasi.

C’è poi il livello del significato, che nessun protocollo tocca. Due server MCP possono esporre lo stesso campo «cliente» intendendo cose diverse, uno i clienti attivi e l’altro chiunque abbia mai ricevuto un’offerta, e l’agente li userà entrambi con la stessa sicurezza. Ne ho scritto a proposito dell’interoperabilità fra agenti, dove il vocabolario precede il protocollo, e del modello dati come teoria dell’azienda: MCP standardizza il tubo, e quello che ci scorre dentro porta con sé tutte le ambiguità organizzative che c’erano prima.

Il codice moltiplica il modello organizzativo che trova

Sarebbe sbagliato concludere che la tecnica sia un dettaglio da sistemare a valle. La sequenza che propongo alle aziende con cui lavoro differisce da quella dell’articolo soltanto nell’ordine delle domande, perché parte da chi decide e con quale criterio, passa per i poteri che si delegano e le soglie che li limitano, arriva ai confini fra sistemi e ai loro proprietari. A quel punto si scrivono skill, tool e server, e ognuno diventa la forma eseguibile di una decisione già presa.

Quando la decisione esiste, la tecnica le dà proprietà che sulla carta non ha mai avuto. Scritta in una skill, una procedura diventa versionata, e si può ricostruire quale versione ha guidato un’azione in una certa data; il permesso, quando sta nel server, si può testare e la sua violazione lascia un log; per spostare un confine dichiarato in un server MCP serve una modifica che qualcuno deve approvare. Il manuale qualità non aveva nessuna di queste caratteristiche, ed è per questo che nessuno lo apriva.

C’è anche un effetto di ritorno. Scrivere una skill è il modo più rapido che conosco per scoprire dove un’organizzazione non ha mai deciso niente, perché il modello, a differenza di un collega esperto, non riempie i vuoti con il buon senso del corridoio: li riempie con una media statistica, e la media si vede subito. Da quando ho scritto Pelle Digitale penso alle interfacce fra persone e macchine come ai punti in cui qualcosa di implicito è costretto a diventare esplicito, e gli agenti portano quel passaggio dentro l’organigramma.

Nei prossimi mesi i fornitori renderanno skill e server MCP facili da installare quanto un’app, e molte aziende ne avranno a decine prima di aver deciso chi li governa. Il vantaggio andrà a chi userà questo periodo per fare l’esercizio al contrario, prendendo una procedura alla volta e cercando chi l’ha decisa. Spesso la risposta sarà nessuno, e da lì comincia il progetto.

 

AI & GENAI, TECH & BUSINESS

Interoperabilità fra agenti: il vocabolario viene prima del protocollo

L’interoperabilità fra agenti di aziende diverse si rompe in silenzio. Il tuo agente manda un ordine di acquisto, quello del fornitore lo riceve, lo interpreta e conferma, e nessuno dei due ha mai concordato cosa significhi quantità confermata, e per un po’ funziona lo stesso, perché i casi facili sono la maggioranza e le differenze emergono solo sul bordo.

Poi arriva l’ordine in cui la quantità confermata del fornitore include il sovrametraggio di produzione e quella del tuo sistema no, e la differenza viene scoperta in magazzino tre settimane dopo.

L’interoperabilità che funziona per caso

Quando si discute di coordinamento fra agenti si parte quasi sempre dal protocollo, cioè da chi chiama chi, in che ordine, con quale formato di messaggio. È il livello visibile, quello che si disegna sulla lavagna, ed è anche quello che si risolve più in fretta perché esistono standard.

Il livello sotto è il lessico, e non si risolve con un formato. Due sistemi possono scambiarsi JSON perfettamente validi per anni contenendo campi che si chiamano allo stesso modo e significano cose diverse. Dentro una stessa azienda questo accade già, e quando due agenti non sono d’accordo qualcuno deve pur decidere, di solito chi scrive per ultimo il file di orchestrazione.

Fra aziende diverse non c’è nessun file di orchestrazione comune, e nessuno che abbia l’autorità di scriverlo, quindi l’interoperabilità resta appoggiata su assunti impliciti. La ricostruzione del significato che dentro casa si paga in token a ogni chiamata, sul confine fra due aziende si paga in ordini sbagliati.

Il precedente della fattura elettronica

In Italia un esperimento di ontologia imposta lo abbiamo già fatto, e lo abbiamo fatto in grande. La fatturazione elettronica verso la pubblica amministrazione prima, quella fra privati dal 2019, hanno costretto ogni azienda del Paese ad adottare lo stesso tracciato XML, gli stessi codici, le stesse regole di validazione, con un sistema di interscambio al centro che rifiuta quello che non rispetta lo schema.

Il modo in cui è stata vissuta dice molto. Un adempimento da sbrigare, con i costi di consulenza e di aggiornamento dei software che ne sono seguiti, e due anni di mugugni. Nessuno l’ha raccontata come un investimento in semantica condivisa, eppure il risultato è che oggi un dato di fatturazione italiano è leggibile da qualsiasi sistema senza negoziazione preliminare, che è esattamente la condizione che rende economico far lavorare un agente su quei dati.

Quello che lo Stato ha ottenuto con un obbligo, due aziende che vogliono far parlare i propri agenti devono ottenerlo per contratto, e il contratto va scritto prima che i sistemi siano in produzione.

Ogni coppia di sistemi è una traduzione da mantenere

L’alternativa allo standard condiviso è la traduzione, e l’interoperabilità ottenuta così si paga per coppia di interlocutori. Con tre fornitori sono tre mappature da mantenere, con dieci sono dieci, e ciascuna invecchia per conto suo ogni volta che una delle due parti cambia il proprio modello dati senza avvertire.

È il problema che l’EDI ha affrontato negli anni novanta con i tracciati concordati fra grandi committenti e filiera, e che si è risolto solo dove c’era un soggetto abbastanza forte da imporre il proprio formato a tutti gli altri. La grande distribuzione lo ha fatto, l’automotive lo ha fatto, e chi stava a valle si è adeguato perché l’alternativa era uscire dalla fornitura.

Con gli agenti quel soggetto forte esiste ancora, e adesso ha uno strumento in più: chi definisce l’ontologia definisce anche cosa i sistemi degli altri sono in grado di dire.

Chi pubblica il vocabolario e chi lo versiona

Un vocabolario condiviso è un oggetto vivo, e la parte difficile comincia dopo averlo scritto. Qualcuno deve pubblicarlo in un posto raggiungibile, dargli un numero di versione, dichiarare quanto dura la compatibilità all’indietro e avvisare la controparte prima di cambiare il significato di un campo invece che dopo.

Sono pratiche che il mondo del software conosce da vent’anni e che nelle relazioni commerciali fra aziende non esistono quasi mai. Il tracciato di scambio viene concordato all’inizio del rapporto, finisce in un allegato tecnico del contratto, e da quel momento cambia attraverso email fra due persone che si conoscono, fino al giorno in cui una delle due cambia lavoro.

Quella fragilità con gli agenti diventa più cara, perché il sistema che riceve un campo dal significato mutato non si ferma a chiedere. Interpreta, risponde, e procede fino a quando qualcuno a valle nota che i numeri del trimestre non tornano.

Lo standard arriva prima o dopo il danno

Nelle filiere dove il costo di un errore è alto, l’interoperabilità semantica esiste già e sta dentro i capitolati. Nelle altre si scoprirà con il primo incidente serio, un ordine confermato per una quantità che nessuno voleva, una scadenza calcolata su una decorrenza diversa, un pagamento autorizzato su un importo che il sistema di controparte considerava al netto.

Fino a ieri quegli incidenti erano rari perché in mezzo c’era sempre qualcuno che leggeva. Una persona che vede arrivare un numero strano si ferma e telefona, e in quella telefonata avviene la riconciliazione semantica che nessuno ha mai messo per iscritto.

Il lavoro che stiamo togliendo agli agenti umani nella filiera è proprio quello, e non lo stiamo sostituendo con niente. Le aziende che nei prossimi mesi scriveranno il proprio vocabolario lo faranno per risparmiare token, e si troveranno in mano un asset di negoziazione con la filiera che non avevano previsto.

AI & GENAI, TECH & BUSINESS

Quanto ti costa un’ontologia che non hai scritto

«Quali contratti scadono il mese prossimo?» è una domanda a cui un agente risponde due volte. La prima volta ricostruisce l’ontologia implicita della tua azienda, cosa intendi per cliente, per contratto e per scadenza, la seconda cerca la risposta vera. Solo la seconda parte produce qualcosa che ti serve, la prima la paghi in token a ogni chiamata, e alla chiamata successiva ricomincia da capo.

Lo argomenta un post che gira su LinkedIn in questi giorni, scritto da chi costruisce sistemi multi-agente e si è accorto di bruciare i limiti di token non tanto sul lavoro richiesto, quanto sul preambolo: agenti che si spiegano a vicenda cosa significano le parole dell’azienda. L’ontologia, che per vent’anni è stata materia da convegno di knowledge management, ricompare come voce di costo.

Il conto dell’ambiguità arriva a ogni chiamata

Cliente vuol dire entità legale, account di fatturazione o capogruppo, e scadenza vuol dire fine del contratto o termine ultimo per disdire? In azienda si risponde in modo diverso a seconda di chi fa la domanda e in quale ufficio lavora, e nessuno ha mai avuto un motivo abbastanza forte per fissare quelle definizioni per iscritto.

Il costo di quell’ambiguità c’è sempre stato, distribuito in modo così fine da risultare invisibile: due dashboard che danno numeri diversi, la riunione del venerdì per decidere quale dei due si porta al consiglio, il commerciale che considera cliente il gruppo mentre l’amministrazione considera cliente la singola ragione sociale. Nessuna di queste voci è mai finita su una riga di bilancio.

Con gli agenti quel costo diventa misurato. Ogni esecuzione paga la ricostruzione del significato, la paga per ciascun agente coinvolto, e la paga una terza volta quando due agenti arrivano a interpretazioni diverse e devono riconciliarle fra loro. Fai il conto con numeri inventati ma coerenti: una routine che gira dieci volte al giorno, tre agenti che ogni volta ricostruiscono lo stesso perimetro di significato, trenta giorni, e arrivi a novecento ricostruzioni mensili della stessa definizione, che sarebbe bastato scrivere una volta sola.

Un’ontologia implicita ce l’hai già

Non avere un’ontologia non vuol dire non averne una, vuol dire averne una per agente, scritta senza deliberazione da chi ha toccato per ultimo il prompt di sistema o la pipeline di retrieval. Uno sviluppatore che decide come filtrare la tabella dei clienti sta prendendo una decisione commerciale, e nessuno gliel’ha chiesto.

È lo stesso meccanismo che ho descritto parlando di chi scrive il protocollo quando due agenti non sono d’accordo: dove l’organizzazione non ha deliberato niente, la deliberazione avviene lo stesso, dentro un file di configurazione, per mano di qualcuno che stava lavorando ad altro e aveva bisogno di andare avanti.

Scrivere l’ontologia serve soprattutto a spostare quella decisione dove appartiene. La definizione di cliente riguarda chi vende e chi firma i contratti, dovrebbe arrivare all’agente già stabilita, e dovrebbe essere la stessa per il report al consiglio e per la routine notturna che manda i solleciti.

Quattro passaggi invece di quaranta documenti

Un’organizzazione è uno spazio di ricerca enorme. La risposta sui contratti in scadenza sta sparsa fra il CRM, il repository contrattuale e il sistema di fatturazione, e un agente che parta da zero ha davanti a sé migliaia di documenti che nominano quel cliente senza dire niente di utile sulla sua scadenza.

Un knowledge graph costruisce la rete stradale fra quei sistemi: cliente, entità contraente, contratto, data di scadenza, record di origine. L’ontologia stabilisce cosa significano quelle relazioni, il grafo collega le entità reali e punta ai record dove sta il dettaglio. I documenti restano dove sono, nei sistemi che li hanno generati, e l’agente autorizzato percorre quattro collegamenti invece di aprire tutto quello che contiene la parola cliente.

Il risparmio nasce dal riuso, e vale la pena dirlo perché è facile aspettarsi troppo. Le definizioni all’agente gliele devi comunque passare, occupano comunque spazio in finestra, e il vantaggio sta nel passarle una volta nella forma decisa dall’azienda invece di farle dedurre a ogni giro da quello che capita sotto mano. Sposti un lavoro di inferenza che oggi avviene a runtime, ogni volta uguale e ogni volta un po’ diverso, dentro un artefatto deciso una volta e conservato.

L’informazione in azienda abbonda, la finestra di contesto no. Buona parte del lavoro serio sugli agenti gira intorno a questo vincolo, e il grafo lo affronta dall’esterno, riducendo le chiamate di retrieval e il contesto irrilevante che finisce in finestra a ogni giro.

In Pelle Digitale ho descritto la superficie sottile che ci separa dalle macchine e decide cosa passa. Dentro un’azienda quella superficie prende una forma burocratica, ed è l’ontologia a stabilire cosa un agente può vedere del modo in cui lavori, in quale ordine e con quale grado di dettaglio.

Costo per risposta corretta, manutenzione inclusa

L’autore del post chiude con il criterio che userebbe per decidere se la struttura vale la spesa: costo per risposta corretta su compiti ripetuti, manutenzione compresa. Il criterio mi pare solido, e ha un presupposto scomodo.

Per misurare il costo per risposta corretta devi sapere quali sono le risposte corrette. Serve un insieme di casi con la risposta nota, tenuto aggiornato, contro cui far girare il sistema ogni volta che cambia qualcosa. Quasi nessuna azienda ce l’ha, quasi nessuno lo mette a budget, perché non produce niente che si possa mostrare in una demo. Il progetto ontologia e il progetto valutazione sono lo stesso progetto, e il secondo è quello che salta quando il budget si stringe. Scrivendo del middleware che smista le richieste ai modelli ero arrivato allo stesso punto da un’altra direzione: i dati di valutazione interni valgono più del modello che scegli.

La manutenzione è l’altra metà del conto. Un’ontologia che nessuno aggiorna quando cambia la struttura societaria, quando si acquisisce un ramo d’azienda, quando il contratto tipo viene riscritto, comincia a produrre risposte sicure e sbagliate. Un agente senza ontologia brucia token e resta nel dubbio, e nel dubbio chiede. Un agente con un’ontologia vecchia costa pochissimo e non chiede niente a nessuno.

Perché l’aggiornamento avvenga davvero serve che qualcuno lo debba fare, con nome e cognome, e che il momento in cui farlo sia agganciato a processi che in azienda esistono già: la delibera che approva un’acquisizione, la riscrittura del contratto quadro, il cambio di ragione sociale registrato in anagrafica. Un’ontologia mantenuta da un gruppo di lavoro che si riunisce quando riesce dura un paio di trimestri, poi resta lì a rispondere con le categorie di due anni prima mentre tutti si fidano.

Sapere cosa significa non basta per agire

Ad agosto, leggendo la mappa di Fanghua Yu sull’evoluzione dell’ontologia dalla semantica formale agli agenti, mi ero fermato su dove finisce l’ontologia e comincia l’agente: sapere cosa significa un ordine non dice niente su chi sia autorizzato ad agire su quell’ordine oggi, e su chi possa revocare quel permesso domani mattina.

Le due cose conviene costruirle insieme. Il grafo che fa risparmiare token è lo stesso che delimita il perimetro, perché un agente che percorre collegamenti invece di rovistare fra i documenti rende quei collegamenti il posto naturale dove scrivere chi passa e chi si ferma. Chi costruisce l’ontologia per la bolletta e rimanda il permesso a una fase successiva si ritrova con una rete di strade senza caselli, percorribile da qualsiasi agente sia stato collegato quella settimana.

La bolletta dell’inferenza sta diventando il primo strumento che mette un prezzo sull’ambiguità organizzativa, e lo fa in fondo al mese, su una riga sola, senza distinguere fra quanto hai speso per rispondere e quanto per capire la domanda. Le aziende che spenderanno meno saranno quelle che avevano già scritto cosa intendono per cliente prima che arrivassero gli agenti a chiederlo, dieci volte al giorno, ognuno per conto proprio.

Spunto: un post su LinkedIn dedicato alle ontologie come leva di risparmio sui token nei sistemi multi-agente, che rimanda alla raccolta The Knowledge Graph Guys.

AI & GENAI, TECH & BUSINESS

Progettare il loop invece di scrivere il prompt successivo

Chiedi a Claude di aggiungere un pulsante di like e parte un loop agentico. Legge il codice, fa la modifica, lancia i test e ti restituisce qualcosa che crede funzioni. Poi tocca a te: apri la pagina, clicchi, guardi la console del browser, e scrivi il prompt successivo. Il collo di bottiglia sei tu, per come è fatto il ciclo: l’agente produce, l’umano controlla, un turno alla volta.

Delba de Oliveira e Michael Segner, del team di Claude Code, hanno messo per iscritto a fine giugno la definizione di loop agentico che usano internamente: «agents repeating cycles of work until a stop condition is met». Agenti che ripetono cicli di lavoro finché non scatta una condizione di stop. È una definizione povera di aggettivi e piena di conseguenze, perché tutto il peso si sposta su una domanda sola, chi scrive quella condizione.


Il ciclo di base: raccoglie contesto, agisce, verifica, e riparte finché la condizione di stop non è soddisfatta.

Quattro modi di far girare un agente

Il turn-based è il loop agentico che usiamo tutti senza chiamarlo così. Parte da un tuo prompt, Claude raccoglie il contesto, agisce, controlla il proprio lavoro e risponde, e si ferma quando giudica il compito chiuso oppure quando gli serve qualcosa che non ha. Quello che deleghi, se lo deleghi, è il controllo del risultato.

Il goal-based nasce quando un turno solo non basta. Con /goal dichiari che cosa significa fatto, e Claude continua a lavorare senza che tu debba rilanciarlo a ogni giro. Ogni volta che prova a fermarsi, un modello valutatore rilegge la conversazione e decide se la condizione regge, e se non regge lo rimanda al lavoro con una motivazione che diventa la guida del turno successivo. Qui deleghi la condizione di uscita, ed è la ragione per cui i criteri deterministici funzionano molto meglio delle formule generiche.

Il time-based serve al lavoro che torna, quello in cui il compito resta identico e cambiano solo gli ingressi: il riassunto dei messaggi del mattino, la pull request che riceve commenti di review e fa fallire la CI. Deleghi l’innesco.

Il proattivo è quello in cui davanti allo schermo non c’è nessuno. Un evento o una pianificazione fanno partire il lavoro, ogni task esce quando raggiunge il proprio obiettivo, la routine continua a girare finché non la spegni. Deleghi il prompt, cioè la parte che fino a ieri consideravamo il mestiere.

I comandi che Anthropic ha rilasciato

/goal imposta una condizione di completamento valida per la sessione, lunga fino a quattromila caratteri. A ogni fine turno un modello piccolo e veloce, Haiku per impostazione predefinita sull’API di Claude, restituisce uno di tre verdetti: soddisfatta, non ancora, impossibile. Il valutatore non esegue comandi e non legge file per conto suo, giudica soltanto quello che Claude ha già portato in conversazione, quindi la condizione va scritta come qualcosa che l’output può dimostrare. Dentro la condizione conviene mettere anche un tetto, «oppure fermati dopo venti turni», altrimenti il loop si allunga oltre quello che ti aspetti. Funziona anche in modalità non interattiva, con claude -p.

/loop rilancia lo stesso prompt a intervalli regolari e gira sul tuo computer, quindi si spegne quando spegni la macchina. /schedule sposta la stessa idea nel cloud e la trasforma in una routine, che continua a lavorare a portatile chiuso. Una routine può partire da una pianificazione oraria, giornaliera, feriale o settimanale, da una chiamata HTTP autenticata a un endpoint dedicato, oppure da un evento GitHub come l’apertura di una pull request o la pubblicazione di una release, con filtri su autore, titolo, branch, etichette. L’intervallo minimo è un’ora. Le routine sono disponibili sui piani a pagamento di Claude, si gestiscono da claude.ai/code/routines e hanno un tetto giornaliero di esecuzioni oltre al consumo ordinario dell’abbonamento.

Intorno a questi due comandi girano altri pezzi. La modalità auto approva le chiamate agli strumenti dentro un turno, e si combina bene con /goal, che invece toglie di mezzo la conferma tra un turno e l’altro. I dynamic workflows, in research preview, permettono a Claude di orchestrare sottoagenti in parallelo. Le skill descrivono i controlli da ripetere. Per chi non apre mai un terminale ci sono gli scheduled task di Cowork, che si configurano dall’interfaccia, girano da remoto anche a computer spento e usano i connettori e le skill già attive.

Il criterio d’uscita vale più del prompt

La qualità di un loop dipende dal sistema che gli sta intorno, e il pezzo che pesa di più è la verifica. Il consiglio di Anthropic è codificare in un file di skill i passaggi che oggi fai a mano, così che l’agente possa controllare il proprio lavoro dall’inizio alla fine invece di dichiararlo finito appena la modifica è andata a buon fine: avviare il server, aprire la pagina, cliccare il controllo nuovo, fare uno screenshot prima e dopo, guardare che in console non compaiano errori, misurare le metriche di performance. Più i controlli sono quantitativi, più l’autoverifica diventa semplice.

Nel mio flusso editoriale la condizione di uscita è un exit code. Uno script passa il testo al setaccio cercando i tic di scrittura che non voglio, e finché non esce zero il pezzo non si consegna. È un criterio grezzo, e misurabile, e chiude il loop in molti meno giri di qualunque descrizione a parole di che cosa sia un buon articolo.


Più il criterio d’uscita è misurabile, meno turni servono al loop per chiudersi da solo.

Due accorgimenti da rubare. Il primo è affidare la revisione a un secondo agente con contesto pulito, perché chi non ha seguito il ragionamento del primo è meno incline a confermarlo. Il secondo riguarda cosa fare quando un risultato non è all’altezza: correggere il singolo errore serve una volta sola, mentre spostare la correzione dentro la skill la rende valida per tutti i giri successivi. È la differenza tra un loop che migliora e uno che ti fa rimettere a posto la stessa cosa per la terza volta.

Sei loop da accendere questa settimana

La rassegna delle sette è il più facile da accendere: uno scheduled task che legge messaggi, posta e calendario delle ultime ventiquattro ore e consegna un brief prima che tu apra il computer. «Ogni mattina alle 7:00 riassumi Slack, email e calendario delle ultime 24 ore e scrivimi trecento parole con le tre cose che oggi richiedono una mia decisione».

Quando le richieste arrivano su un canale condiviso, la coda si accumula da sola e qualcuno passa la giornata a smistarla. Una routine oraria con un obiettivo esplicito la tiene bassa: «ogni ora controlla il canale delle richieste, e non fermarti finché ogni segnalazione trovata in questo giro non ha un responsabile, una priorità e una risposta».

C’è poi il documento che non esce finché non passa l’audit, il caso in cui il criterio esiste già da qualche parte e nessuno lo aveva mai dato in pasto all’agente: «l’articolo passa lo script di audit con exit code 0 e resta sopra le 1.400 parole, fermati dopo sei tentativi».

Anche il debito accumulato su un sito si può assegnare a un lunedì mattina: «ogni lunedì alle 6:00 controlla i post pubblicati nell’ultimo mese, segnala meta description mancanti, immagini senza testo alternativo e link interni rotti, e prepara le correzioni in bozza».

Sulle pull request funziona meglio l’intervallo, perché quello che cambia sta fuori dal tuo progetto e arriva quando arriva: /loop 10m controlla la mia PR, rispondi ai commenti di review, sistema la CI che fallisce.

L’ultimo parte da un evento invece che da un orario. La pipeline di deploy chiama via HTTP l’endpoint della routine appena il rilascio è in produzione, la routine esegue gli smoke test, cerca regressioni nei log e scrive go o no-go nel canale di release prima che la finestra si chiuda. Lo stesso schema regge sugli alert: il sistema di monitoraggio passa il corpo dell’allarme, l’agente correla lo stack trace con i commit recenti e apre una bozza di pull request con una proposta di correzione, così chi è di turno trova qualcosa su cui lavorare invece di un terminale vuoto.

Per scegliere quale accendere per primo, Anthropic propone un criterio pratico: guarda il lavoro che già fai, prendi un compito in cui sei tu a rallentare tutto, e chiediti quale pezzo puoi passare alla macchina, se sai scrivere il controllo di verifica, se l’obiettivo è già abbastanza chiaro da poter essere giudicato da un altro modello, oppure se il lavoro arriva comunque a scadenze regolari.

Quanto costa tenere acceso un loop

Un loop senza confini è un modo elegante di bruciare token. Il primo controllo è la scelta del pezzo giusto: un compito piccolo non ha bisogno di più agenti, e parecchio lavoro gira benissimo su modelli più economici, tenendo quello più capace per le decisioni di giudizio. Il secondo è la precisione del criterio di uscita, che deve essere specifico abbastanza da far arrivare Claude alla soluzione presto, senza però farlo fermare troppo presto.

Poi ci sono due regole che sembrano banali e non lo sono. Quando una parte del lavoro è deterministica, conviene che sia uno script a farla, perché eseguire uno script costa meno che ragionare ogni volta sugli stessi passaggi. E l’intervallo di una routine va tarato su quanto spesso cambia davvero la cosa che stai guardando, non su quanto ti piacerebbe essere aggiornato. Prima di lanciare un workflow su tutto il perimetro conviene provarlo su una fetta piccola, visto che l’orchestrazione dinamica può generare centinaia di agenti.

Per misurare c’è /usage, che scompone il consumo recente per skill, sottoagenti e connettori, /goal senza argomenti, che mostra turni e token spesi finora, e /workflows, da cui si vede quanto sta consumando ogni agente e si può fermarne uno al volo.

Una routine firma con la tua identità

Qui arriva la parte che in azienda pesa più del risparmio di tempo. Una routine gira come sessione autonoma: durante l’esecuzione non ci sono richieste di permesso, e Claude può usare tutti gli strumenti dei connettori inclusi, comprese le scritture. Quando crei una routine i connettori attivi vengono inclusi tutti per impostazione predefinita, e toglierli è un gesto che conviene fare subito.

Quello che la routine fa attraverso la tua identità appare come fatto da te. I commit e le pull request portano il tuo utente GitHub, i messaggi su Slack e i ticket su Linear passano dai tuoi account collegati. L’ambiente cloud definisce a quali domini la sessione può arrivare, e il testo che accompagna un’attivazione via API viene consegnato all’agente dentro un blocco marcato come dato non affidabile, così il prompt della routine deve dichiarare esplicitamente di volerlo usare prima che quel testo possa orientare il lavoro.

Sono dettagli di configurazione, e insieme disegnano una superficie di responsabilità nuova. Permesso revocabile è la formula che uso da tempo per questa condizione, in cui l’autonomia di un sistema è sempre concessa e sempre ritirabile. Con le routine la domanda operativa diventa chi ha aperto il permesso, quali strumenti ha lasciato dentro, e in quanto tempo qualcuno se ne accorge.

Il livello che stavamo saltando

Per due anni abbiamo lavorato quasi solo sul primo livello, la formulazione del singolo turno, e poi sul secondo, il contesto da mettere davanti al modello. Sopra c’è l’harness, il guscio che decide che cosa l’agente può toccare e con quali permessi. In mezzo sta il livello che stavamo saltando: quante volte l’agente ci riprova, e a quali condizioni ha il diritto di dire che ha finito.


Il loop sta sopra il contesto e sotto l’harness: un guasto si attribuisce al livello che lo ha prodotto.

Chi progetta il loop agentico decide dove finisce il lavoro della macchina e dove comincia la responsabilità di una persona. Nei prossimi mesi credo che nelle organizzazioni comparirà un ruolo che oggi non ha ancora un nome: qualcuno che scrive le condizioni di stop, le rivede quando cambia il contesto, e risponde di tutto quello che quelle condizioni lasciano passare.

AI & GENAI, TECH & BUSINESS

Chi decide quando due agenti AI non sono d’accordo

Al tavolo di un cliente, qualche settimana fa, la riunione si è fermata su una domanda che non era tecnica. Avevano due agenti AI quasi pronti, uno che istruisce le pratiche e uno che interroga i sistemi di rischio, e a un certo punto qualcuno ha chiesto cosa succede quando il secondo contraddice il primo. Il silenzio che è seguito non era imbarazzo. Quella regola non stava scritta da nessuna parte nemmeno per le persone che facevano lo stesso identico lavoro il giorno prima, e per quindici anni era bastato così, perché c’era un capo servizio che la teneva in testa e la applicava caso per caso, con criteri che nessuno gli aveva mai chiesto di dettare.

Da un paio d’anni ripeto una cosa che sembra ovvia e nella pratica non lo è mai: mettere più modelli linguistici dentro lo stesso spazio computazionale non produce da sé né i benefici né i rischi. Li produce il modello di coordinamento che gli diamo, e quel modello va scritto, in forma esplicita, con protocolli, criteri, autorità. Attendersi che il valore emerga da solo da un collettivo di macchine è la versione tecnologica della speranza che un’orchestra suoni bene perché i musicisti sono bravi.

La parte scomoda arriva subito dopo: progettare un modello di coordinamento presuppone che da qualche parte, in azienda, ce ne sia già uno leggibile da cui partire, e quasi nessuna organizzazione ce l’ha.

Il collettivo di agenti AI eredita quello che trova

Un sistema di agenti AI messo in produzione dentro un’azienda non arriva su una tabula rasa, si innesta sul modo in cui quell’azienda coordina già le proprie persone. Dove quel modo è esplicito, e capita nelle filiere regolate, nella logistica, in parte della sanità, gli agenti trovano un substrato: chi ha l’ultima parola su cosa, quale eccezione va scalata a chi, entro quanto, con quale traccia. Il collettivo computazionale eredita una grammatica e ci si appoggia.

Dove invece il coordinamento vive nella testa di sette persone anziane e in una manciata di chat, non c’è niente da ereditare. E quel vuoto lo riempie chi integra, il martedì pomeriggio, con la scelta di implementazione che gli sembra più ragionevole in quel momento. È così che il modello di coordinamento di un’impresa finisce dentro un file di orchestrazione senza che nessuno l’abbia mai deliberato, e senza che nessuno se ne accorga finché non arriva la prima contestazione seria.

Avevo affrontato la stessa questione dal lato del significato quando scrivevo di ontologia come infrastruttura invisibile: lì il problema era che un agente non sa cosa vuol dire “cliente attivo” se l’azienda non l’ha mai definito. Qui il problema è gemello e sta un piano sopra, perché anche sapendo cosa significa un ordine bisogna ancora stabilire chi può agire su di esso, e chi può fermare l’altro.

Quando il protocollo fra due uffici non esiste

Di questi progetti il pezzo più utile matura molto prima della messa in produzione, e non ha niente di tecnologico. Provare a scrivere il protocollo di coordinamento fra due agenti AI costringe a scoprire che non esisteva nemmeno fra due uffici.

Nelle sessioni di assessment che conduco succede quasi sempre lo stesso movimento: si parte con la domanda su quale modello usare, si finisce a ricostruire chi ha l’autorità di annullare una decisione presa da qualcun altro, e quanto vale quell’autorità dopo che la decisione è già stata comunicata al cliente. Sono domande di governance che l’azienda si porta dietro irrisolte da anni, tollerabili finché a coordinare erano persone che si conoscono e si telefonano, insostenibili nel momento in cui il coordinamento passa a un collettivo di agenti AI che esegue e basta.

Su questo tema ho una posizione che ripeto da un po’: la vera unità di misura di un agente non è quello che sa fare, è il permesso revocabile sotto cui lo fa. La maturità di un’organizzazione cognitiva si misura sulla capacità di dire, per ciascun agente in circolazione, chi gliel’ha concesso, fino a quando, e con quale gesto glielo si toglie.

La gavetta era il posto dove passava il criterio

C’è una trasformazione che vedo sottovalutata quasi ovunque, e riguarda l’apprendimento. Questi sistemi si sono messi in mezzo fra le persone e la conoscenza di come si fanno le cose, e il primo posto dove si sono infilati sono i compiti di gavetta, quelli che nelle organizzazioni funzionavano da palestra per chi comincia. Una generazione intera rischia di perdere le occasioni di imparare che tutte le precedenti hanno avuto.

Dal mio tavolo si vede bene una cosa in più. La gavetta non serviva solo a formare chi la faceva. Era il momento in cui il criterio implicito veniva tirato fuori dalla testa del senior e messo in parole, malamente, di corsa, davanti a una pratica sbagliata da rifare, e in quell’attrito il criterio si riformulava ogni volta un po’ diverso e un po’ più preciso. Toglila di mezzo e non perdi soltanto il canale di trasmissione verso i giovani, perdi la sola occasione in cui l’azienda si spiegava a voce alta come funziona.

È il debito cognitivo nella sua forma meno visibile: non si accumula quando deleghiamo l’esecuzione, si accumula quando deleghiamo l’occasione di dover spiegare. Sulla superficie di contatto fra noi e le macchine si decide ogni giorno cosa passa e cosa no, e continuo a pensare che la parte da tenere di qua sia proprio quella, il momento in cui qualcuno è costretto a dire perché.

Governare uno strumento, non attendere un’entità

Nelle conversazioni con i board torna spesso l’idea, che si associa di solito a Nick Bostrom, dell’intelligenza artificiale come ultima invenzione che l’umanità dovrà fare, quella che poi risolverà i problemi troppo grandi per noi. È una formula che semplifica parecchio, e soprattutto colloca l’AI in una zona fuori portata, dove le decisioni le prende lei e a noi tocca aspettare l’esito.

Trovo che la cornice messianica, in azienda, faccia un danno preciso e poco spettacolare. Se l’AI è un destino, la cosa sensata da fare è aspettare, magari fare un pilota per dire che ci si sta muovendo, e rimandare. Se invece è uno strumento, la cosa sensata da fare è noiosa e comincia lunedì: scrivere il protocollo, assegnare le autorità, decidere dove gira il calcolo e con quali termini, verificare di poterli revocare. La narrazione dell’entità super intelligente è comoda perché sposta la responsabilità dal consiglio di amministrazione a un futuro indeterminato.

Della sovranità digitale ho parlato spesso come di una questione di infrastruttura, e lo è, ma la sua metà meno raccontata sta qui: sovrano è chi ha scritto le regole con cui i propri agenti AI si parlano e può cambiarle senza chiedere il permesso a un fornitore, molto più di chi si limita a ospitarli dentro il proprio perimetro.

Chi scrive il protocollo

La domanda più fastidiosa arriva alla fine, ed è chi materialmente questo lavoro lo fa. Il vendor porta un default ragionevole, calibrato su mille clienti diversi dal tuo, e non può fare altrimenti. L’integratore chiede le regole all’azienda e si vede consegnare un documento di processo del 2019 mai più aggiornato. All’IT da solo non si può lasciare, perché le regole di coordinamento fra agenti AI sono decisioni di business travestite da configurazione.

Nelle poche organizzazioni dove ho visto funzionare, il protocollo l’hanno scritto le persone che il lavoro lo fanno, sedute in una stanza per settimane, con qualcuno che faceva domande scomode e trascriveva. Costa parecchio e non produce nessuna demo da mostrare in comitato. Ed è l’unica parte del progetto che l’azienda si tiene anche se cambia modello, fornitore e architettura tre volte in cinque anni.

Se davvero l’era agentica ci obbliga a mettere per iscritto come coordiniamo il lavoro, allora l’effetto più duraturo dell’AI in azienda potrebbe non avere niente a che fare con le macchine, e riguardare il fatto che per la prima volta molte imprese saranno costrette a leggere ad alta voce come funzionano davvero. Vediamo quante reggono la lettura.

AI & GENAI, TECH & BUSINESS

Chi delega all’AI il proprio lavoro

Il 24 agosto è comparso su arXiv il primo tentativo serio di misurare la delega di lavoro all’AI dal lato di chi la compie: 53.000 specifiche di skill prese dal marketplace di Manus, incrociate con circa 18.000 descrizioni di mansione dell’O*NET americano, per ricavarne quella che gli autori chiamano esposizione delegata. La domanda che si sono posti è diversa da quella su cui abbiamo costruito due anni di grafici, perché invece di stimare quanto una professione potrebbe essere svolta da un modello hanno contato quanti gesti chi quel mestiere lo fa davvero abbia già scritto dentro una routine automatica, e lasciato andare.

Sembra una sfumatura, e sposta quasi per intero l’elenco di chi dovrebbe preoccuparsi.

L’esposizione delegata come misura

Le mappe dell’esposizione all’AI che circolano dal 2023 misurano una capacità teorica, e lo fanno con un metodo ragionevole: si prende la descrizione di un compito, si valuta se un modello saprebbe eseguirlo, si aggrega per professione. Il risultato è una fotografia di quello che potrebbe accadere, costruita da chi guarda il lavoro da fuori.

Il marketplace di Manus è un’altra cosa. È un posto dove le persone pubblicano le configurazioni che hanno costruito per farsi fare il lavoro, e ogni skill caricata è un pezzo di mestiere che qualcuno ha ritenuto abbastanza stabile da poterlo descrivere una volta sola e riusarlo. Chi la carica non sta rispondendo a un questionario, sta risolvendo un problema che ha. Gli autori hanno preso quelle configurazioni, le hanno rappresentate in uno spazio semantico, e hanno misurato quanto le mansioni di ciascuna professione somiglino alle routine che i praticanti si sono già costruiti.

Quello che ne esce assomiglia molto più a un registro di quello che è già successo che a una previsione su quello che accadrà.

Dal potenziale al gesto registrato

Il primo risultato che gli autori mettono in fila è che le professioni dove la delega si concentra sono nettamente diverse da quelle che i framework pre-AI indicavano come più a rischio. Il secondo è che l’indice della delega segue più da vicino quello che l’AI saprebbe fare rispetto a quello che i lavoratori ne fanno oggi, il che vuol dire che c’è uno spazio aperto tra il possibile e l’adottato, e che quello spazio non si chiude da solo.

Il terzo è quello che mi ha tenuto sveglio. La delega sale verso il centro della distribuzione salariale e al livello di laurea triennale, poi scende ai due estremi. Scende in basso, dove il lavoro è manuale o troppo variabile per essere specificato in anticipo, e questo era prevedibile. Scende anche in alto, dove ci sono le professioni che tutti indicavano come le prime a essere riscritte, e questo non lo era.

La disponibilità tecnica, scrivono gli autori, spiega gran parte della variazione ma non il deficit tra le occupazioni più istruite. Qualcosa lì trattiene.

Dove la delega si ferma

Gli autori lasciano due ipotesi aperte, senza sceglierne una: lavoro che resiste alla specificazione anticipata, oppure discrezionalità professionale sul ritmo con cui il proprio mestiere viene codificato.

La prima è un limite tecnico, e i limiti tecnici hanno la brutta abitudine di cadere. Se un avvocato senior non delega perché la sua parte di lavoro non si lascia scrivere in una specifica, allora è questione di tempo, di finestre di contesto più lunghe, di modelli che tollerano meglio l’ambiguità di un incarico mal posto. La seconda ipotesi descrive invece una posizione, presa e tenuta, e implica che ci sia una categoria di persone che ha capito che scrivere il proprio criterio dentro una configurazione riusabile equivale a consegnarlo, e che ha deciso quanto e quando.

In Pelle Digitale avevo provato a descrivere la superficie di contatto tra noi e le macchine come il punto in cui si decide cosa passa e cosa resta, e mi rendo conto adesso che l’avevo pensata come una scelta individuale e istantanea, mentre qui la vedo funzionare come una scelta di categoria, lenta, forse nemmeno del tutto consapevole.

Il criterio che si scrive una volta sola

A luglio avevo scritto che il gemello cognitivo lo addestri tu, e l’argomento era che correggendo il modello gli trasferisci il criterio che ci hai messo quindici anni a costruire, mentre lui lo esporta a chiunque e tu intanto ti disalleni. Quel pezzo l’avevo scritto sulla correzione, che è un gesto quotidiano e distratto. La skill caricata su un marketplace è la stessa cosa fatta con intenzione, messa per iscritto, versionata, e resa disponibile a un numero indefinito di persone che non hanno fatto il percorso per arrivarci.

Chi delega in questo modo sta facendo la cosa più razionale del mondo dal punto di vista della propria produttività questa settimana. Sta anche pubblicando la parte trasferibile del proprio mestiere, gratis, in un posto dove viene indicizzata.

Le 53.000 skill che i ricercatori hanno analizzato sono, viste da questa angolazione, il più grande esercizio collettivo di documentazione del lavoro qualificato mai fatto, e nessuno lo sta chiamando così.

Chi si sottrae, e per quanto

Resta la domanda su cosa fare di questa informazione, e non ho una risposta pulita.

Da un lato la riluttanza delle professioni più istruite è difendibile e la capisco: c’è un valore reale nel non rendere esplicito tutto quello che sai, e chi consiglia le aziende su questi temi lo tocca con mano ogni volta che un cliente chiede il documento invece della conversazione. Dall’altro lato la stessa riluttanza somiglia molto a quella delle categorie che negli anni Novanta si sono difese dal digitale non digitalizzandosi, e sappiamo tutti come è finita quella storia.

Su questo avevo già toccato il tema della riconfigurazione delle competenze partendo dalla scuola, e mi accorgo che avevo trattato la questione come un problema di formazione delle nuove generazioni, quando questi dati la spostano su chi il mestiere ce l’ha già.

C’è una terza possibilità che il paper non nomina e che a me sembra la più probabile, ed è che le professioni in alto non stiano scegliendo affatto, ma semplicemente non abbiano ancora incontrato lo strumento nella forma in cui lo userebbero, perché i marketplace di skill sono costruiti da sviluppatori per sviluppatori e un notaio o un primario non ci passa. Se è così, il dato che oggi leggiamo come discrezionalità professionale è solo un ritardo di distribuzione, e la delega si riempirà dall’alto nei prossimi diciotto mesi.

Gli autori chiudono dicendo che distinguere tra le due ipotesi richiederà misurazioni ripetute nel tempo. Hanno ragione, e vale la pena rifare questo conto tra sei mesi, perché sarà la prima volta che potremo osservare una categoria professionale decidere in diretta quanto di sé mettere per iscritto.

Il paper è Who Delegates to AI? Evidence from 53,000 Agent Configurations, pubblicato su arXiv il 24 agosto 2026.