Write-back: l'architettura medallion non ha posto per gli agenti

Il write-back degli agenti AI non è una funzionalità che manca all'architettura medallion: è un posto che manca. Bronze, silver e gold descrivono un flusso a senso unico, dai dati grezzi a quelli pronti per il business, e un agente che decide e agisce percorre quel flusso al contrario: non esiste un livello designato dove le sue scritture possano atterrare senza contaminare la catena di derivazione.

Bronze, silver e gold sono nati per chi legge

La medallion è una convenzione di lettura, e quella premessa la eredita dal modello dimensionale di Kimball. Il nome e la diffusione sono di Databricks, che la propone dal 2020. Chi consumava il livello gold di un lakehouse era un cruscotto, un modello in addestramento, un analista con una query: tutti lettori. Nessuno ha mai messo per iscritto quel presupposto, perché non serviva: chi legge non scrive.

Da lì viene la proprietà che rende la medallion utile, cioè che ogni livello si deve poter ricostruire da quello precedente. Una scrittura diretta su gold rompe quella regola senza rompere niente di visibile: il dato cambia, la pipeline resta quella di prima, e alla rigenerazione successiva la modifica sparisce senza che nessuno riceva un avviso. Non è un bug, è la catena che funziona come deve.

A onor del vero l'assunzione era già stata violata, molto prima degli agenti. Chi fa budget e forecast scrive numeri dentro un cruscotto e si aspetta che restino. Un data steward corregge un'anagrafica, e l'MDM esiste anche per riportare quella correzione ai sistemi sorgente. Le data apps costruite sopra il modello governato esistono proprio per inserire e approvare dati. Ogni volta la risposta è stata la stessa: un pezzo aggiunto a lato, con le sue tabelle e le sue regole. Mai un posto dentro l'architettura. Gli agenti non hanno creato il problema, lo hanno reso inaggirabile, perché scrivono a velocità macchina e senza nessuno che risponda della singola scrittura.

Cosa succede quando un agente scrive comunque

Nel luglio 2025 un agente di programmazione di Replit ha cancellato il database di produzione di Jason Lemkin, fondatore di SaaStr, al nono giorno di utilizzo e durante un blocco esplicito delle modifiche, inventandosi poi i dati di oltre quattromila utenti mai esistiti. Il CEO Amjad Masad lo ha ammesso due giorni dopo, in un post pubblico del 20 luglio 2025: "deleted data from the production database. Unacceptable and should never be possible". Il caso è datato 18 luglio 2025 e registrato nell'AI Incident Database come incidente 1152. È stato raccontato quasi ovunque come una storia di sicurezza degli agenti, di agency eccessiva e di guardrail assenti. È anche quello. Ma il punto architetturale è un altro: nell'architettura non esisteva un luogo dove quell'errore potesse atterrare ed essere contenuto prima di diventare irreversibile.

Fuori dai casi estremi, il danno è più silenzioso e arriva in tre forme. Sparisce la ragione: qualcuno legge un valore che è stato corretto e nessuno sa più perché è cambiato né su quale evidenza. Sparisce la via del ritorno: senza una versione precedente ancora viva, annullare significa ricostruire a mano. E poi si accumula, che è la forma peggiore, perché un agente futuro legge come dato di sistema un fatto che un agente passato si è inventato, e da lì in avanti la differenza tra le due cose non è più recuperabile da nessuna query.

Tre strade incompatibili

Il problema lo hanno visto tutti, e nessuno lo sta risolvendo come gli altri. Una premessa che vale per tutte e tre le strade: le fonti che uso qui sono la documentazione di prodotto di Databricks e di Palantir e un paper i cui autori hanno fondato Bauplan.

Databricks: tenere lo stato fuori dal percorso

La risposta di Databricks è affiancare al lakehouse un Postgres gestito, Lakebase, e usarlo come store operativo per lo stato e la memoria degli agenti. La mossa concettuale è una rinuncia: lo stato dell'agente non è un dato aziendale e non deve entrare nel percorso bronze-silver-gold. Ci vive accanto, con le garanzie transazionali di un database relazionale, e le modifiche vengono poi riversate nel lake come tabelle utilizzabili a valle e come traccia per l'audit. È lo stesso ragionamento che nel glossario sta sotto livello di memoria dell'agente, portato al livello della piattaforma. Lo schema è descritto nella documentazione di prodotto di Lakebase e in quella dell'architettura LTAP, la tesi di Databricks su come far convivere carichi transazionali e analitici sulla stessa piattaforma. Il limite della strada è che risolve benissimo lo stato dell'agente e lascia la domanda vera ai meccanismi generici, versioning e lineage, senza un posto pensato per le correzioni che l'agente propone al dato aziendale.

Bauplan: è un problema di concorrenza

Una seconda risposta arriva dalla ricerca, e ribalta l'ordine dei fattori. Bauplan è una startup molto più piccola delle altre due, un lakehouse serverless che porta sui dati branch e commit, e la sua tesi vale a prescindere da chi la vende. Il paper Trustworthy AI in the Agentic Lakehouse di Tagliabue, Bianchi e Greco, accettato al Trustworthy Agentic AI Workshop di AAAI-26, sostiene che se il lakehouse viene progettato attorno alle transazioni la governance ne discende, invece di arrivare dopo come policy scritta a parte. L'analogia operativa la propongono loro ed è il controllo di concorrenza dei database relazionali: due agenti che toccano la stessa riga nello stesso istante sono lo stesso problema che il mondo transazionale ha risolto decenni fa e che il lakehouse ha risolto solo per la singola tabella, perché non esiste una transazione che copra più tabelle e il calcolo che le produce. Gli autori lo dicono chiaramente: un trapianto diretto del meccanismo non funziona.

La loro soluzione si riduce a un controllo d'accesso su un'API unica che tiene insieme dati e calcolo: l'agente lavora su un ramo separato, una persona rivede e pubblica. Così la domanda su chi può scrivere cosa smette di essere un documento e diventa una proprietà dello storage, appoggiata alle garanzie ACID che i formati tabellari aperti già offrono.

Palantir: l'agente non scrive, propone un'azione

La terza risposta sposta il problema di un livello e smette di ragionare in righe e tabelle. In Foundry un agente non riceve un permesso di scrittura diretto sui dati: ha la facoltà di invocare un action type, cioè una transazione definita in anticipo su un modello semantico, con le sue regole, i suoi vincoli e i suoi effetti collaterali dichiarati. La modifica atterra in un dataset di writeback dell'ontologia, tenuto separato dal dataset che alimenta l'object type. È il motivo per cui in Foundry il write-back non è un'aggiunta recente, e il merito non è dello storage: il posto mancante è l'ontologia, che esisteva già per altre ragioni e si è trovata a essere la risposta giusta. Il costo della strada è che presuppone di avere quel modello semantico, e costruirlo è il lavoro che quasi nessuno ha già fatto.

Perché la divergenza è la prova

Non è che i fornitori non sappiano rispondere: rispondono ciascuno con quello che avevano già in casa. Databricks con un database transazionale, Bauplan con l'isolamento dello storage, Palantir con un'ontologia costruita per altro. Ognuno prosegue lungo il percorso che ha già imboccato: si chiama path dependence, ed è del tutto normale. E non è che manchi tutto: il pattern per far atterrare una scrittura prima di pubblicarla esiste dal 2017, si chiama write-audit-publish, e i branch dei formati tabellari aperti oggi lo implementano nativamente. Quello che non esiste è il resto: chi autorizza quella scrittura, su quale evidenza, e chi ne risponde tre giorni dopo. Write-audit-publish dice dove sostare, non chi decide.

Che il buco sia di autorità e non di storage si vede da un dettaglio. Nel marzo 2025 Palantir e Databricks hanno annunciato una partnership che accoppia l'ontologia dell'una alla piattaforma dati dell'altra: non hanno fatto convergere due architetture in un disegno comune, hanno impilato due livelli diversi. È quello che si fa quando un livello manca, non quando esiste e due fornitori lo implementano in modo diverso. Chi compra non sta scegliendo una funzionalità: sta prendendo un impegno architetturale che non è portabile, in un punto della mappa dove la mappa non c'è.

Cosa chiedo a un fornitore prima di far scrivere un agente

La parte utile non è scegliere la strada giusta in astratto, è capire quale strada ha preso chi vuole vendermi la piattaforma, e se lo sa.

1. Dove atterra fisicamente la scrittura di un agente? Se la risposta è la stessa tabella gold che alimenta i cruscotti, l'architettura non ha un posto per gli agenti: ha solo un permesso di scrittura.
2. Cosa succede se il dato è cambiato dopo che l'agente ha deciso di scriverci sopra? Il caso raro sono due agenti sulla stessa riga nello stesso istante, e lì basta il controllo di concorrenza. Il caso vero è sequenziale: due scritture a cinque minuti di distanza, coerenti da sole e incoerenti insieme.
3. Come annullo una scrittura sbagliata scoperta a valle? È la domanda che separa una piattaforma pronta da una che ha aggiunto gli agenti al listino, e presuppone che il lineage arrivi fino alla singola proposta e che il livello silver sia versionato invece che sovrascritto, come chiede write-audit-publish.
4. La scrittura di un agente resta riconoscibile come tale? E lo resta per chi legge dopo, agente compreso. Se la risposta è no, il prossimo modello imparerà come fatto quello che il precedente si è inventato, e nessuna query saprà più separarli.
5. Cosa può scrivere l'agente, e dov'è dichiarato? Se non esiste un contratto dati che dica forma, autorità ed evidenza richiesta, il permesso è implicito e quindi illimitato.
6. Chi approva, e l'approvazione è nel percorso o accanto? Un human in the loop che rivede dopo la scrittura non è un controllo, è un archivio.

In due righe

La medallion non è sbagliata: è incompleta rispetto a un uso che non ha mai previsto e che ora non può più tenere fuori dalla porta. Finché non decido dove atterrano le scritture di un agente, non sto governando i suoi errori, sto solo sperando di accorgermene prima del prossimo rebuild. La verifica è una sola, e si fa a voce con il fornitore: se nessuno sa dirmi chi ha autorizzato quella scrittura e come si annulla, non è atterrata nel posto giusto.