Databricks semplifica l'orchestrazione degli agenti AI, ma ora il rischio ricade su Postgres

Databricks semplifica l'orchestrazione degli agenti AI con un'architettura di produzione che sostituisce diversi servizi specializzati con un unico database Lakebase Postgres. Il rilascio del 22 luglio descrive un'applicazione di audit realizzata con CLA che elabora documenti in pochi minuti anziché in ore. Si tratta di un risultato riportato dall'azienda, ma il cambiamento architetturale è più rilevante.

Il sistema utilizza Postgres per code di attività, tentativi ripetuti, pianificazione, attribuzione dei costi e aggiornamenti di stato in tempo reale. Databricks afferma che CLA non necessita più di broker esterni come Kafka o Redis, scheduler separati come Airflow o Temporal, né di una cache dedicata.

Questo consolidamento crea un chiaro conflitto. I sistemi di orchestrazione specializzati separano le responsabilità e assorbono guasti complessi. Databricks concentra più di queste responsabilità in un database familiare, riducendo l'infrastruttura ma rendendo la progettazione del database centrale per l'affidabilità degli agenti.

Databricks semplifica lo stack attorno agli agenti a lunga esecuzione

Il cambiamento immediato non è un nuovo modello o framework per agenti. È un modello di produzione che tratta Lakebase come il centro di controllo per il lavoro degli agenti.

Databricks e la società di servizi professionali CLA hanno realizzato il sistema per l'audit assistito da agenti. Gli audit richiedono spesso al personale di esaminare contratti, fatture, dichiarazioni finanziarie e documenti di supporto prima di estrarre informazioni strutturate.

L'applicazione accetta caricamenti PDF tramite un'interfaccia FastAPI in esecuzione su Databricks Apps. Archivia questi file in Unity Catalog Volumes e scrive ogni richiesta di estrazione in Lakebase.

Lakebase è il servizio Postgres gestito di Databricks. La sua documentazione Postgres descrive scalabilità automatica, branching del database, repliche di lettura, ripristino istantaneo e integrazione con Unity Catalog.

Due tabelle relazionali costituiscono il nucleo operativo. La tabella tasks registra ogni lavoro logico, inclusi stato, priorità, informazioni sul lease, assegnazione dell'agente e output finale. La tabella task_attempts registra le singole esecuzioni, inclusi identificativi dei job, identificativi di tracciamento e metadati sui costi.

Lakeflow Jobs esegue il lavoro sui documenti. Ogni job legge un PDF archiviato, richiama componenti e modelli per l'elaborazione dei documenti, quindi scrive il risultato in Lakebase. MLflow acquisisce chiamate ai modelli, utilizzo dei token, latenza e informazioni sui costi.

L'architettura divide quindi le responsabilità senza introdurre un ulteriore livello infrastrutturale. Lakeflow esegue il lavoro, mentre Lakebase registra cosa deve essere eseguito, cosa è in esecuzione e cosa è terminato.

Databricks afferma che questa progettazione ha ridotto il processo di estrazione di CLA da ore a minuti senza diminuire la qualità. L'azienda non ha pubblicato un benchmark indipendente, la distribuzione dei carichi di lavoro o un tasso di errore misurato a sostegno di tale affermazione.

Tuttavia, il rilascio va oltre un diagramma di riferimento generico. Databricks identifica i modelli di concorrenza, recupero, limitazione, callback, osservabilità e fatturazione necessari per operare con questa architettura.

Questo dettaglio conta perché una tabella di database non diventa automaticamente una coda di attività sicura. Una query di base può selezionare il lavoro in attesa, ma più worker potrebbero selezionare la stessa riga prima che uno di essi ne aggiorni lo stato.

L'architettura deve anche recuperare il lavoro dopo l'arresto anomalo di un processo. Deve impedire che callback duplicati generino risultati duplicati. Deve mantenere le richieste ai modelli entro le quote esterne e consentire ai documenti urgenti di superare il lavoro in blocco.

La progettazione dell'orchestrazione affronta questi problemi con transazioni e funzionalità consolidate di Postgres. La notizia non è che Postgres possa archiviare lo stato degli agenti. Gli sviluppatori lo fanno da anni.

L'affermazione più forte è che Postgres gestito possa diventare la spina dorsale dell'orchestrazione per un carico di lavoro di agenti in produzione senza Kafka, Redis, Temporal, Airflow o un altro scheduler.

La vera pressione ricade sull'infrastruttura specializzata

Databricks mette in discussione l'assunto secondo cui ogni applicazione di agenti in produzione necessiti di un broker, scheduler, cache e stack di osservabilità separati.

Le demo degli agenti spesso eseguono una singola richiesta dall'inizio alla fine all'interno di un unico processo. I sistemi di produzione si comportano diversamente perché gli utenti inviano lavoro in contemporanea, le chiamate ai modelli falliscono e le singole attività hanno durate imprevedibili.

Databricks illustra questa variabilità con due tipi di documento. Una fattura di due pagine potrebbe essere completata in pochi secondi, mentre un contratto di 200 pagine può richiedere diversi minuti. Un worker non può presumere che le attività verranno completate nell'ordine di invio.

Le quote dei modelli aggiungono un altro vincolo. Un endpoint può limitare le richieste al secondo, i token al minuto o entrambi. L'invio simultaneo di centinaia di documenti può attivare limitazioni e tentativi ripetuti.

L'applicazione deve anche rispondere a domande operative. I team devono sapere quale attività è fallita, quale chiamata al modello ha consumato token, quanto è costato ciascun tentativo e se un job abbandonato debba essere eseguito di nuovo.

Le architetture tradizionali spesso assegnano queste esigenze a prodotti separati. Un broker di messaggi trasporta le attività. Un motore di workflow gestisce l'esecuzione durevole. Una cache fornisce accesso rapido allo stato. Una piattaforma di monitoraggio aggrega stato, latenza e costi.

Questa separazione può supportare workflow complessi e grandi organizzazioni. Introduce però credenziali aggiuntive, processi di distribuzione, dashboard, modalità di guasto e codice di integrazione.

Databricks sostiene che questo sovraccarico sia sproporzionato per attività a lunga esecuzione indipendenti l'una dall'altra. L'estrazione di documenti rientra in questa descrizione perché un contratto di norma non dipende dal risultato di un altro contratto.

Lakebase modifica il calcolo collocando lo stato transazionale accanto al resto dell'applicazione Databricks. La stessa piattaforma fornisce interfaccia, file, job, tracce dei modelli, controlli di governance e registri di fatturazione.

L'approccio esercita pressione su due gruppi. I team di piattaforma devono giustificare ogni servizio aggiuntivo che introducono, mentre i fornitori di orchestrazione devono dimostrare perché le loro garanzie specializzate superino quelle di una coda di database ben progettata.

Questo non rende obsoleti i sistemi dedicati. Amazon, ad esempio, presenta AgentCore Runtime come un ambiente gestito con isolamento delle sessioni, scalabilità, identità e supporto per agenti a lunga esecuzione.

Questo approccio chiede ai team di adottare un runtime specifico per gli agenti. Databricks parte invece da un database operativo e lo collega a servizi già utilizzati per carichi di lavoro di dati e machine learning.

La competizione riguarda quindi i confini dell'infrastruttura. L'esecuzione degli agenti dovrebbe risiedere in un runtime specializzato, oppure un database dovrebbe coordinare job ordinari tramite stato relazionale durevole?

Databricks dispone di un vantaggio strutturale tra i clienti esistenti. I team che già utilizzano Lakeflow, MLflow, Unity Catalog e Databricks Apps possono consolidare senza introdurre un altro fornitore o modello di sicurezza.

Lo stesso vantaggio crea dipendenza dalla piattaforma. Un'azienda che sceglie il modello completo lega esecuzione delle attività, archiviazione, osservabilità, governance e rendicontazione dei costi ai servizi Databricks.

Per gli acquirenti, “più semplice” non può significare solo meno nomi di prodotti. Deve significare meno attività operative, responsabilità più chiare in caso di guasto, comportamento di recupero accettabile e una strategia di uscita sostenibile.

Quattro modelli Postgres rendono credibile la coda

L'architettura funziona perché trasforma primitive di database familiari in garanzie esplicite su concorrenza, recupero, limitazione e tentativi ripetuti.

Il primo modello è l'estrazione dalla coda sicura rispetto alla concorrenza. Un worker seleziona le righe idonee con FOR UPDATE SKIP LOCKED, che blocca le righe selezionate consentendo agli altri worker di ignorarle.

PostgreSQL documenta SKIP LOCKED come utile per evitare contese quando più consumatori accedono a una tabella simile a una coda. Avverte inoltre che l'opzione presenta una vista incoerente, rendendola inadatta alle query di uso generale.

Questa distinzione coglie il punto di forza dell'architettura. La tabella delle attività non viene usata per reportistica arbitraria durante l'estrazione dalla coda. I worker necessitano di rivendicazioni esclusive sui job disponibili senza attendere il blocco di un altro worker.

La query ordina il lavoro per priorità decrescente e orario di creazione. I job con priorità più alta vengono eseguiti per primi, mentre quelli con la stessa priorità mantengono l'ordine di arrivo.

Il secondo modello utilizza lease a scadenza. Quando un worker rivendica un'attività, registra un tempo di scadenza del lease invece di assegnarne la proprietà per sempre.

Un processo di pulizia periodico restituisce alla coda le attività scadute. Se un worker scompare a causa di un'espulsione, distribuzione, errore di memoria o arresto anomalo del processo, un altro worker può recuperare il suo job entro pochi minuti.

I lease risolvono il problema del lavoro abbandonato, ma introducono anche un requisito. L'applicazione deve scegliere periodi di scadenza superiori alle normali durate delle attività oppure rinnovare i lease mentre il lavoro prosegue.

Un lease che scade troppo presto può far apparire abbandonato un lavoro sano. Un lease che dura troppo a lungo aumenta il tempo di recupero dopo un guasto reale.

Il terzo modello controlla il consumo del modello prima dell'invio. L'orchestratore supporta un limite di attività concorrenti, un budget di token previsto o una combinazione dei due.

Un limite di concorrenza conta le righe attualmente contrassegnate come in elaborazione. Poiché il database conserva quel conteggio, la restrizione resta visibile tra i riavvii dei worker e più repliche dell'orchestratore.

Un budget di token stima il consumo per ogni attività in corso. L'orchestratore invia un altro job solo quando i suoi token previsti rientrano nel limite configurato.

Quando entrambi i controlli sono abilitati, prevale il vincolo più restrittivo. Questo si adatta a carichi di lavoro che alternano molte piccole fatture e pochi contratti ad alto consumo di token.

Il quarto modello rende idempotenti i callback. L'idempotenza significa che ripetere la stessa richiesta produce lo stesso risultato effettivo anziché applicare la modifica due volte.

Interruzioni di rete e proxy possono far arrivare un callback più di una volta. Databricks accetta callback per job in elaborazione o reinseriti in coda, trattando gli stati già completati come no-op.

Questo comportamento riduce il rischio di elaborazioni o fatturazioni duplicate. Dipende tuttavia da identità delle attività stabili, transizioni di stato accurate e da un confine transazionale che includa l'aggiornamento del risultato.

Nel loro insieme, i quattro modelli creano una coda credibile. Le transazioni impediscono rivendicazioni simultanee, i lease recuperano il lavoro abbandonato, i budget limitano l'invio e i callback idempotenti tollerano le riconsegne.

È così che Databricks semplifica una coda di attività per agenti senza sostenere che una coppia di tabelle sia di per sé sufficiente. Il codice dell'applicazione implementa comunque la policy che governa ogni transizione.

Il meccanismo è adatto a job con strutture di dipendenza relativamente semplici. Diventa meno interessante quando il lavoro richiede workflow annidati, azioni compensative, approvazioni umane o lunghe catene di eventi temporizzati.

Un motore di workflow dedicato spesso rappresenta direttamente queste relazioni. Con una coda di database, gli sviluppatori devono modellarle come tabelle, transizioni di stato e logica applicativa.

Questo compromesso dovrebbe orientare l'adozione. I team dovrebbero selezionare questo modello perché il loro workflow è sufficientemente semplice, non perché Postgres possa teoricamente rappresentare ogni possibile workflow.

Un unico database collega stato, visibilità e costi

La parte più distintiva dell'architettura non è l'accodamento. È la decisione di derivare visibilità operativa e attribuzione dei costi dagli stessi record delle attività.

Gli operatori hanno bisogno di più di un'etichetta di completamento o fallimento. Il dashboard CLA mostra i conteggi delle attività in coda, in elaborazione, completate, non riuscite e annullate.

Mostra inoltre i token di input e output, i costi dei modelli, i costi di calcolo, il tempo di risposta mediano e il livello di confidenza per documento. I filtri coprono intervalli temporali, stati delle attività e singoli agenti.

La latenza mediana è una scelta utile per questo carico di lavoro. Il backoff dei tentativi e la saturazione della coda possono creare ritardi estremi che distorcono una semplice media.

Postgres LISTEN/NOTIFY fornisce il meccanismo di aggiornamento in tempo reale. Un trigger del database pubblica un evento quando cambia lo stato di un'attività e il backend dell'applicazione mantiene una connessione in ascolto.

Il backend distribuisce questi eventi ai browser tramite Server-Sent Events. SSE è un flusso HTTP unidirezionale che consente a un server di inviare aggiornamenti attraverso una connessione persistente del browser.

Databricks afferma che le modifiche al dashboard compaiono di norma entro circa un secondo. Il design non richiede Redis, un server WebSocket o un message bus per questo percorso.

Il sistema mantiene il polling come fallback permanente. I browser richiedono dati aggiornati ogni dieci secondi quando lo streaming non è disponibile.

Questo fallback è importante perché i proxy di ingresso cloud possono interrompere uno stream senza produrre un chiaro errore nel browser. Un dashboard che si basa solo sugli eventi push può diventare silenziosamente obsoleto.

Il dashboard combina informazioni con velocità di aggiornamento diverse. Lo stato di Postgres è immediato, mentre i dati delle tracce MLflow arrivano in meno di un secondo, secondo Databricks.

Le query di fatturazione possono richiedere decine di secondi. L'applicazione esegue quindi query rapide sullo stato durante gli aggiornamenti normali e riserva le query di fatturazione più lente alle azioni degli utenti.

L'attribuzione dei costi richiede un ulteriore livello di filtraggio. Le tabelle di fatturazione Databricks includono attività a livello di account, quindi una query non filtrata combinerebbe le spese di job e applicazioni non correlate.

L'orchestratore registra le esecuzioni specifiche dei Databricks Job assegnate alle proprie attività. Le query di fatturazione filtrano quindi l'attività dell'account in base a tali identificatori.

Ciò consente a un unico SQL warehouse di supportare più applicazioni, mentre ogni dashboard mostra solo il proprio carico di lavoro. Gli operatori possono restringere ulteriormente i risultati per stato, agente o data.

Il design supporta domande pratiche che il monitoraggio generico spesso nasconde. Un team può esaminare il costo delle attività non riuscite nell'arco di sette giorni o confrontare la spesa mediana tra agenti.

Questo legame tra identità dell'attività e costo è rilevante oltre l'audit. Le applicazioni AI perdono spesso la relazione tra una richiesta dell'utente, i tentativi che ha attivato e la fattura del modello risultante.

Un record di attività durevole fornisce ai team una chiave di join stabile. Collega l'intento aziendale, la cronologia di esecuzione, le tracce del modello, l'attività di calcolo e l'output finale.

I team ad alta intensità di conoscenza affrontano un problema correlato dopo l'esecuzione. Devono preservare i documenti, le decisioni e gli output che circondano il lavoro automatizzato in un contesto ricercabile.

Una base di conoscenza ingegneristica strutturata può integrare le tracce di runtime conservando il contesto umano dietro incidenti e decisioni di progettazione.

Il valore del modello Lakebase si estende quindi oltre la riduzione dei servizi. Crea una narrazione operativa unica per ogni attività, dall'invio attraverso i tentativi fino a costo ed esito.

Un'infrastruttura più semplice sposta il rischio nella progettazione del database

Databricks riduce l'overhead di integrazione, ma non elimina la complessità dei sistemi distribuiti. Sposta tale complessità in schemi, transazioni, lease e codice applicativo.

L'espressione “nessuna infrastruttura esterna” merita una lettura attenta. L'applicazione dipende comunque da diversi servizi Databricks, tra cui Apps, Lakeflow Jobs, MLflow, Unity Catalog Volumes e Lakebase.

La semplificazione avviene all'interno di un'unica piattaforma gestita. Non riduce l'architettura a un unico processo o servizio.

Questa distinzione è importante durante un'interruzione. Una coda Lakebase potrebbe rimanere durevole mentre il servizio job non è disponibile, ma l'applicazione necessita comunque di un comportamento testato per l'invio ritardato e il ripristino.

I team devono anche stabilire cosa accade quando il callback riesce ma un'operazione circostante fallisce. L'idempotenza protegge dalle consegne ripetute solo quando ogni effetto collaterale utilizza identificatori e confini coerenti.

Anche il controllo dei limiti di frequenza contiene incertezza. Un budget di token previsto dipende dalla stima del consumo del documento prima che il modello lo elabori.

Le stime possono sottostimare documenti complessi o sovrastimare quelli semplici. Una sottostima può attivare limitazioni da parte del provider, mentre una sovrastima può lasciare inutilizzata la capacità disponibile del modello.

Il design pubblicato non fornisce risultati sul throughput, limiti di profondità della coda, tassi di errore, carico del database o dati operativi comparativi. Non confronta inoltre direttamente l'implementazione con un motore di workflow dedicato.

Databricks riferisce che il tempo di estrazione è sceso da ore a minuti. Tuttavia, non comunica il campione di documenti, il processo di revisione umana, la misura di accuratezza, la configurazione del modello o il workflow di riferimento.

I lettori dovrebbero considerare il risultato come il resoconto di un cliente in produzione, non come un benchmark controllato. L'architettura può essere utile anche senza dimostrare miglioramenti universali delle prestazioni.

Postgres stesso può diventare un punto di contesa. Dequeue frequenti, aggiornamenti di stato, calcoli del budget di token, letture del dashboard e join di fatturazione provengono tutti da record operativi correlati.

Lakebase offre calcolo con scalabilità automatica e storage durevole indipendente. Queste funzionalità possono ridurre la pianificazione della capacità, ma l'autoscaling non elimina query inefficienti o contesa sui lock.

Anche le tabelle di coda crescono diversamente dalle normali tabelle applicative. La cronologia dei tentativi si accumula, i record completati rimangono preziosi per gli audit e gli indici devono supportare sia la pianificazione in tempo reale sia l'analisi storica.

Le policy di conservazione e archiviazione sono quindi parte della progettazione della coda. Senza di esse, le query operative possono gradualmente competere con i carichi di reporting.

La sicurezza merita pari attenzione. La tabella delle attività può contenere posizioni dei documenti, risultati estratti, punteggi di confidenza, assegnazioni degli agenti e identificatori di esecuzione.

Databricks afferma che Unity Catalog fornisce identità e autorizzazioni condivise. I team devono comunque applicare il principio del privilegio minimo, proteggere gli endpoint webhook e decidere quali operatori possano ispezionare risultati sensibili.

Il branching del database può aiutare a riprodurre difetti in un ambiente isolato. Può anche copiare dati operativi sensibili, rendendo necessari mascheramento e controlli di accesso adeguati al carico di lavoro di audit.

La questione competitiva più ampia rimane irrisolta. Anche AlloyDB AI di Google posiziona un'infrastruttura compatibile con PostgreSQL come fondamento per applicazioni AI, incluse le ricerche vettoriali e ibride.

AWS adotta un approccio più specifico per gli agenti con servizi gestiti di runtime, memoria, identità e orchestrazione. I sistemi di workflow dedicati continuano a concentrarsi sull'esecuzione durevole attraverso grafi di processo complessi.

Databricks ha dimostrato che Postgres può coprire una significativa fascia intermedia. Non ha dimostrato che l'orchestrazione incentrata sul database debba sostituire tali sistemi per ogni carico di lavoro degli agenti.

Il caso di adozione più forte riguarda attività indipendenti e di lunga durata su una piattaforma Databricks esistente. Il più debole riguarda workflow tra sistemi con dipendenze complesse e requisiti rigorosi di portabilità.

Tre segnali metteranno alla prova il caso dell'orchestrazione Lakebase

Il prossimo test è capire se l'architettura CLA diventerà un modello di produzione ripetibile anziché un'implementazione per cliente attentamente progettata.

Il primo segnale è l'adozione oltre l'estrazione di documenti. Databricks dovrebbe pubblicare esempi che coinvolgano agenti di coding, operazioni clienti, bonifica dei dati o workflow di ricerca.

Questi carichi di lavoro metterebbero alla prova diverse dimensioni delle attività, strutture di dipendenza, autorizzazioni degli strumenti e requisiti di approvazione umana. Risultati simili rafforzerebbero l'affermazione che Lakebase sia un archivio generale dello stato degli agenti.

Se gli esempi futuri resteranno limitati a job di documenti indipendenti, il design rimarrà comunque utile. Il suo ambito pratico sarà semplicemente più ristretto di quanto suggerisca il più ampio linguaggio sull'orchestrazione.

Il secondo segnale è rappresentato dai dati operativi comparativi. I team hanno bisogno di throughput della coda, tempi di ripristino, utilizzo del database, tassi di errore e latenza di dispatch sotto carico sostenuto.

Un confronto con worker basati su Redis o con un motore di workflow durevole sarebbe particolarmente utile. Potrebbe mostrare quando la riduzione del lavoro di integrazione supera la logica aggiuntiva della macchina a stati all'interno dell'applicazione.

Dati trasparenti rafforzerebbero l'argomentazione di semplificazione di Databricks. L'assenza di tali dati lascerebbe gli acquirenti dipendenti dalle descrizioni dell'architettura e dagli esiti riportati dai clienti.

Il terzo segnale è la productizzazione. Il modello attuale si basa su codice applicativo che implementa locking, lease, throttling, callback, streaming del dashboard e attribuzione della fatturazione.

Databricks potrebbe trasformare parti di questo design in template, componenti gestiti, librerie di riferimento o funzionalità Lakebase integrate. Ciò ridurrebbe la quantità di codice critico per la correttezza che ogni cliente deve mantenere.

La productizzazione rivelerebbe anche come Databricks definisce il confine tra funzionalità del database e funzionalità di workflow. Un livello gestito più ampio competerebbe più direttamente con runtime per agenti e piattaforme di orchestrazione.

I team che valutano il modello dovrebbero iniziare dalla forma del proprio workflow. Attività indipendenti con stati terminali chiari si allineano bene al design CLA.

Dovrebbero poi testare il comportamento in caso di errore prima di ottimizzare il throughput. Interrompete i worker, ritardate i callback, duplicate le richieste, esaurite le quote del modello e interrompete gli stream del dashboard.

Infine, confrontate il carico operativo con un'alternativa specializzata. Contate i servizi eliminati, ma anche le transizioni personalizzate, le regole di ripristino, i test e i runbook aggiunti.

Databricks semplifica l'infrastruttura visibile attorno all'orchestrazione degli agenti, e Lakebase offre al design un nucleo transazionale credibile. La domanda aperta è se la vostra applicazione sia abbastanza semplice perché tale consolidamento rimanga semplice.

Se lo è, una coda incentrata sul database può accorciare il percorso dal prototipo a un sistema di produzione osservabile. Se non lo è, il broker o il motore di workflow mancante riapparirà come codice applicativo. Il passo successivo corretto è un progetto pilota incentrato sui guasti, usando dimensioni reali delle attività, quote reali e obiettivi di ripristino reali.