Databricks mostra come creare agenti resilienti con Temporal e Lakebase, ma la demo mette in luce la parte più difficile
L'8 settembre Databricks ha pubblicato un'implementazione di riferimento che mostra come creare agenti resilienti con Temporal e Lakebase nonostante crash dei worker, tentativi ripetuti e revisioni che durano più giorni. Il sistema applica questa architettura alla valutazione dei prestiti personali, dove la perdita di un singolo controllo completato può compromettere la tracciabilità della decisione.
Il cambiamento importante non è un altro framework per agenti o un modello più grande. Databricks e Temporal hanno suddiviso lo stato dell'agente tra due sistemi con responsabilità diverse. Temporal preserva il flusso di controllo, mentre Lakebase espone dati operativi interrogabili da applicazioni, revisori e analisti.
Questa divisione crea anche la tensione centrale. L'esecuzione resiliente può recuperare il lavoro registrato, ma non può rendere ogni effetto esterno eseguibile esattamente una sola volta. L'applicazione necessita comunque di identificatori stabili, scritture nel database protette, regole sulle versioni delle policy e riconciliazione quando i componenti non concordano.
Databricks trasforma la resilienza degli agenti in un sistema verificabile
L'implementazione di riferimento considera un agente come un processo aziendale di lunga durata, non come una sessione di chat temporanea.
L'implementazione di riferimento segue una richiesta di prestito dalla raccolta delle evidenze fino a una decisione umana. Il suo agente esegue controlli su credito, reddito, rapporto debito/reddito e policy di sottoscrizione come operazioni separate.
L'esempio utilizza richiedenti e provider simulati, quindi non elabora vere domande di prestito. Questa scelta mantiene l'esperimento incentrato sul comportamento dell'esecuzione anziché sulle prestazioni del modello di credito.
Un richiedente di esempio ha un punteggio di credito di 665 e una segnalazione di insolvenza non rilevante. L'agente raccoglie le evidenze, valuta le soglie della policy specifiche per finalità e genera una raccomandazione. Non può prendere la decisione finale sul prestito.
Un sottoscrittore deve approvare, rifiutare o richiedere ulteriori informazioni. Quest'ultima opzione estende lo stesso caso a un altro turno dell'agente, preservando le evidenze precedenti e la motivazione del revisore.
Lo scenario è volutamente più difficile di una singola richiesta a un modello. Un worker può interrompersi dopo il completamento di diversi controlli. Una scrittura nel database può essere confermata prima che il suo completamento raggiunga Temporal. Un revisore può lasciare il caso aperto per giorni.
Un browser non aggiornato può anche inviare un comando obsoleto dopo che il caso è avanzato. Nel frattempo, la policy di sottoscrizione può cambiare senza una corrispondente distribuzione dell'applicazione.
Queste situazioni generano sei requisiti pratici: recupero, nuovi tentativi controllati, attese persistenti, visibilità operativa, governance a runtime e cronologia di audit. Una trascrizione da sola non può soddisfarli.
Una trascrizione registra i messaggi, ma non necessariamente il flusso di controllo completo. Non mostra automaticamente quale operazione sia stata completata, quale risultato sia stato accettato o quale comando abbia fatto avanzare il processo.
L'implementazione assegna quindi a ogni esecuzione di prestito un Temporal Workflow. Un Workflow è un flusso di controllo resiliente la cui cronologia registrata consente a un altro worker di ricostruirne lo stato.
Le chiamate a modelli, database e strumenti di sottoscrizione vengono eseguite come Activities. Un'Activity è un'operazione ripetibile il cui risultato può essere registrato nell'Event History del Workflow.
Le risposte dei revisori arrivano come Signals, ovvero comandi asincroni consegnati a un Workflow aperto. Temporal può mantenere tale attesa senza riservare un processo worker per più giorni.
React e FastAPI gestiscono l'applicazione rivolta agli utenti. Avviano le esecuzioni, mostrano le evidenze, elencano i casi e inviano le decisioni di revisione. Temporal Cloud archivia la cronologia dell'esecuzione e distribuisce i task ai worker.
Lakebase Postgres ospita la proiezione rivolta all'applicazione. Una proiezione è una rappresentazione interrogabile dello stato corrente del workflow, costruita a partire dagli aggiornamenti prodotti durante l'esecuzione.
Unity Catalog resta la fonte delle regole di sottoscrizione. Una tabella sincronizzata continuamente rende queste regole disponibili tramite Lakebase, così i worker possono leggere policy aggiornate senza una distribuzione del codice.
Questa architettura rende visibile e riproducibile il comportamento dell'agente in caso di errore. Trasforma la resilienza da promessa generale in un insieme di specifici contratti di recupero e coerenza.
Tuttavia, la demo non riunisce tali contratti in un unico database. Temporal e Lakebase rimangono sistemi separati, e il divario tra loro determina le questioni ingegneristiche più difficili.
La memoria dell'agente non è lo stato di esecuzione
Un agente resiliente necessita di decisioni registrate sul flusso di controllo, non soltanto di messaggi archiviati o memorie recuperate.
Molti sistemi per agenti descrivono la persistenza come memoria. Salvano una conversazione, recuperano documenti precedenti o inseriscono un risultato intermedio in un database. Queste capacità aiutano i modelli a recuperare il contesto, ma non ricostruiscono l'esecuzione.
Supponiamo che un worker completi un controllo del credito e poi si arresti. Un sostituto deve stabilire se il risultato è stato registrato, se un altro tentativo è sicuro e quale operazione debba essere eseguita successivamente.
Questo è un problema di flusso di controllo. Include Activities pianificate, risultati completati, timer, comandi umani accettati, tentativi di ripetizione e il turno di revisione corrente.
Temporal memorizza queste informazioni in un'Event History ordinata. Durante il replay, il codice del workflow utilizza gli eventi registrati e ricostruisce variabili quali evidenze, utilizzo dei token e stato della revisione.
Un risultato di Activity registrato viene restituito durante il replay anziché essere eseguito nuovamente. Pertanto, un controllo del credito completato o una risposta del modello registrata restano fissi per quell'esecuzione del workflow.
Un completamento non registrato presenta un caso diverso. Un provider di modelli potrebbe completare l'elaborazione di una richiesta appena prima che il worker perda la connettività. Se Temporal non riceve mai il risultato, può pianificare un altro tentativo.
Questo limite conta perché le chiamate ai modelli non sono né prive di effetti collaterali né garantite come deterministiche. Una seconda risposta può differire dalla prima, anche con input identico.
La dimostrazione assegna policy di retry ai singoli tipi di operazione. Le Activities del modello consentono fino a quattro tentativi entro una finestra schedule-to-close di tre minuti.
Le Tool Activities consentono fino a tre tentativi con un timeout start-to-close di 60 secondi. Le Lakebase Activities consentono fino a cinque tentativi con un timeout start-to-close di 15 secondi.
Questi valori descrivono la configurazione di esempio, non impostazioni predefinite universali per la produzione. I team devono definire i limiti dei tentativi in base al comportamento del provider, agli obiettivi di latenza, alle modalità di errore e alle conseguenze a valle.
Il modello di esecuzione resiliente di Temporal affronta il recupero dei processi preservando la cronologia necessaria per il replay. Non rende automaticamente sicuro ripetere un pagamento, un'email, una modifica al database o una richiesta a un modello.
Ogni operazione esterna necessita di un contratto di idempotenza. L'idempotenza significa che tentativi ripetuti convergono verso un unico risultato previsto invece di produrre effetti duplicati.
La demo sui prestiti costruisce questo contratto con identificatori deterministici. Un'esecuzione, messaggio, chiamata a strumento, evento, turno di revisione e decisione del revisore ricevono ciascuno un'identità stabile.
Le chiavi primarie e i vincoli di unicità di Postgres impediscono ai retry di creare copie illimitate. Gli upsert consentono a un tentativo ripetuto di indirizzare la stessa riga logica.
Gli aggiornamenti protetti aggiungono un ulteriore livello. Consentono solo transizioni di stato valide, come spostare una chiamata a strumento in attesa al completamento senza riaprire un record terminale.
Tuttavia, anche un aggiornamento protetto richiede un'interpretazione attenta. PostgreSQL può interessare zero righe senza generare un errore quando il target ha già raggiunto uno stato terminale.
L'articolo di Databricks riconosce che l'attuale wrapper dell'Activity non sempre trasforma questo esito di zero righe in un errore. Il codice di produzione dovrebbe ispezionare lo stato archiviato prima di considerarlo innocuo.
Questo dettaglio distingue un utile riferimento ingegneristico da un modello di produzione completo. L'orchestrazione resiliente fornisce il meccanismo di recupero, mentre gli sviluppatori dell'applicazione definiscono ancora una semantica aziendale sicura.
Lo stesso principio si applica al di fuori della sottoscrizione. I provider di pagamento necessitano di chiavi di idempotenza, i sistemi email di identificatori di messaggio stabili e gli strumenti non supportati di record di riconciliazione.
I team che sviluppano un agente interno necessitano anche di un livello di evidenze ricercabile. Una base di conoscenza ingegneristica strutturata può aiutare le persone a ispezionare documentazione, decisioni e contesto tecnico relativi a tali workflow.
La lezione più ampia è precisa: la memoria aiuta un modello a ricordare, mentre l'esecuzione resiliente aiuta un sistema a continuare. Gli agenti di produzione necessitano di norma di entrambe, ma le due cose non sono intercambiabili.
Creare agenti resilienti con Temporal e Lakebase separando le responsabilità
Il design funziona perché Temporal e Lakebase conservano tipi diversi di verità per consumatori diversi.
Temporal detiene la verità di esecuzione. La sua cronologia determina quali task siano stati completati, quali timer siano scattati, quali Signals siano arrivati e cosa debba fare successivamente un worker in replay.
Lakebase detiene la vista corrente dell'applicazione. Archivia stato delle esecuzioni, messaggi, evidenze degli strumenti, record di revisione, eventi operativi, metadati delle raccomandazioni e metriche dei retry in tabelle relazionali.
Questa divisione consente all'interfaccia utente di interrogare i casi correnti con normali pattern SQL. I revisori possono trovare casi in attesa, ispezionare una raccomandazione o confrontare misurazioni operative tra esecuzioni.
Le evidenze appaiono prima della chiusura di un Workflow. Una volta completata la ricerca della policy, il risultato strutturato diventa disponibile insieme a soglie, valori effettivi, esiti delle regole, motivazione e fonte della policy.
Questo è importante nei sistemi con revisione umana. Un revisore non dovrebbe attendere il completamento dell'intero processo prima di vedere le evidenze alla base di una raccomandazione.
L'applicazione usa due schemi Lakebase. Lo schema agent_ops contiene i record operativi, mentre agent_policy contiene una copia in sola lettura della policy di sottoscrizione governata.
Ogni Activity scrive righe utilizzando identificatori allineati al Workflow. Un retry può quindi aggiornare lo stesso record logico mentre la proiezione del database si aggiorna.
Lakebase non diventa parte del replay di Temporal. Questo confine impedisce alle normali query applicative di decidere l'esecuzione del workflow, ma significa anche che gli aggiornamenti non sono atomici nei due sistemi.
Un evento Temporal può essere registrato mentre una proiezione Lakebase rimane temporaneamente indietro. Una scrittura nel database può anche essere confermata prima che Temporal registri il completamento dell'Activity corrispondente.
L'architettura accetta questo divario e utilizza la coerenza eventuale. La coerenza eventuale significa che viste separate possono non concordare brevemente, ma convergono tramite retry e scritture deterministiche.
È un design ragionevole per dashboard ed elenchi di casi. Richiede maggiore cautela quando una vista del database viene utilizzata per convalidare un comando che influenza lo stato aziendale.
Lakebase offre un accesso Postgres familiare e indicizzazione orientata all'applicazione. Il suo modello di database operativo supporta anche la memoria degli agenti, lo stato corrente e i carichi di lavoro di feature serving.
Il suo calcolo può scalare automaticamente entro limiti configurati. Scale-to-zero può sospendere il calcolo inattivo, sebbene la prima query dopo un periodo di inattività possa subire latenza di attivazione.
Queste funzionalità del database aiutano con il traffico irregolare degli agenti. Non eliminano la pianificazione della capacità, i limiti di connessione, la configurazione dei pool o i test di recupero.
Il percorso delle policy è altrettanto importante. Unity Catalog archivia soglie specifiche per finalità, incluse le regole su credito e rapporto debito/reddito. Una tabella sincronizzata in modo continuo presenta tali valori all'interno di Lakebase.
I responsabili delle policy possono aggiornare la fonte senza ridistribuire il worker o l'API. Una ricerca successiva può leggere le regole propagate da Postgres.
Questo evita di incorporare ogni soglia aziendale nel codice dell'applicazione. Introduce inoltre una questione relativa alla tempistica delle policy, alla quale il livello di orchestrazione deve rispondere esplicitamente.
Un caso aperto dovrebbe mantenere le regole applicate al suo avvio oppure adottare una policy più recente in un turno successivo? Entrambe le scelte hanno conseguenze per coerenza, verificabilità e trattamento dei clienti.
La demo registra le soglie applicate e la fonte insieme alla raccomandazione. Queste evidenze consentono ai revisori di ricostruire quale policy abbia informato uno specifico risultato.
Quando Lakebase non è disponibile, l'esempio può usare una policy di fixture e registrare questo percorso di fallback. L'articolo osserva correttamente che un workflow regolamentato potrebbe invece fallire in modalità chiusa.
Questa scelta non può essere delegata a una libreria di retry. Product owner, team di compliance e ingegneri devono definire se una policy obsoleta o di fallback sia legalmente e operativamente accettabile.
Il percorso di ritorno proposto usa Lakebase Change Data Feed. Una volta abilitato, può acquisire le mutazioni del database e pubblicarle nelle tabelle della cronologia Delta gestite da Unity Catalog.
Databricks afferma che il feed raggruppa le modifiche approssimativamente ogni 15 secondi. Questo intervallo è adatto a audit e analisi retrospettivi, mentre l'applicazione legge lo stato corrente direttamente da Lakebase.
Tuttavia, il repository prepara soltanto i propri schemi per questo percorso. Non contiene un'esecuzione end-to-end osservata del feed nell'ambiente di destinazione.
Costruire agenti durevoli con Temporal e Lakebase richiede quindi tre confini chiari: verità dell'esecuzione, verità operativa e cronologia analitica governata.
Il pattern diventa prezioso quando tali confini sono espliciti. Diventa pericoloso quando i team presumono che la parola “durevole” significhi che ogni componente sia sempre concorde.
La revisione umana espone il compromesso sulla coerenza
L'attesa dell'underwriter mostra perché la durabilità deve includere l'identità del comando, il rifiuto dello stato obsoleto e una convalida indipendente del Workflow.
Dopo che il modello produce una raccomandazione, il Workflow crea un identificatore di revisione a partire dall'esecuzione e dal turno corrente. Registra la revisione in attesa in Lakebase ed entra in AWAITING_REVIEW.
Temporal attende quindi una condizione senza mantenere occupato un worker. Il Workflow aperto può sopravvivere alla sostituzione del processo mentre l'essere umano impiega tempo per rispondere.
L'API accetta approvazione, rifiuto o una richiesta di ulteriori informazioni. Verifica innanzitutto se Lakebase mostri ancora la revisione pertinente come in attesa.
Confronta inoltre l'identificatore di revisione inviato con il round di revisione corrente. Una mancata corrispondenza genera un conflitto invece di inoltrare una decisione palesemente obsoleta.
Questo controllo preliminare nel database migliora l'esperienza utente, ma non è autorevole. La proiezione di Lakebase può essere in ritardo rispetto a Temporal, in particolare mentre un'Activity esegue retry.
L'API invia quindi il comando come Signal e il Workflow lo convalida nuovamente rispetto allo stato di esecuzione. Decisioni duplicate o obsolete vengono ignorate all'interno del flusso di controllo durevole.
Questo secondo controllo è essenziale. Una scheda del browser potrebbe restare aperta mentre un altro revisore fa avanzare il caso, oppure una richiesta precedente potrebbe arrivare dopo l'avvio di un nuovo round di revisione.
Una risposta HTTP 202 conferma soltanto che Temporal ha ricevuto il Signal. Non significa che il Workflow abbia accettato la decisione aziendale.
Il client deve aggiornare la vista Lakebase per osservare lo stato risultante. Questa distinzione evita che la conferma di trasporto venga scambiata per l'approvazione del prestito.
Quando il Workflow accetta una decisione, un'Activity Lakebase idempotente la persiste. L'approvazione o il rifiuto completano l'esecuzione.
Una richiesta di ulteriori informazioni riprende l'esecuzione. La motivazione del revisore diventa un nuovo messaggio utente, il turno avanza e la raccomandazione successiva riceve un nuovo identificatore di revisione.
Questo meccanismo conferisce a ogni round di revisione un confine stabile. Rende inoltre visibile il principale compromesso: lo stato reattivo dell'applicazione è separato dallo stato autorevole dell'esecuzione.
I team devono progettare tenendo conto di disaccordi temporanei. Le interfacce dovrebbero comunicare chiaramente comandi in attesa, conflitti, proiezioni ritardate e azioni obsolete rifiutate.
Anche i dashboard operativi devono distinguere l'attesa intenzionale dal guasto. Un caso in attesa di un underwriter è sano, mentre un'Activity bloccata nei retry richiede un intervento.
La demo espone metriche a livello di Workflow, turno e tentativo di Activity. Gli operatori possono ispezionare la cronologia di Temporal, interrogare lo stato di Lakebase e controllare separatamente l'ambiente del worker.
Questa separazione aiuta a diagnosticare se un ritardo dipenda dalla revisione umana, dalla disponibilità del modello, dall'autenticazione al database o da uno strumento non riuscito.
Aggiunge però anche superficie operativa. I team devono monitorare Temporal, Lakebase, distribuzioni dei worker, pool di connessioni, job di sincronizzazione e i contratti che li uniscono.
L'autenticazione introduce un'altra preoccupazione di lunga durata. Il client Lakebase usa OAuth machine-to-machine e aggiorna il proprio pool di connessioni prima che scadano le credenziali temporanee del database.
Senza rotazione delle credenziali, un worker può fallire secondo una pianificazione prevedibile anche se il suo Workflow rimane recuperabile. Un flusso di controllo durevole non rende utilizzabili connessioni scadute.
Gli sviluppatori che confrontano framework per agenti durevoli dovrebbero quindi guardare oltre il supporto ai checkpoint. Dovrebbero chiedersi come vengano identificati i comandi, come vengano deduplicati gli effetti collaterali e dove risieda lo stato autorevole.
Dovrebbero inoltre testare deliberatamente le interazioni obsolete. Aprite due sessioni di revisione, fate avanzare una e quindi inviate la decisione precedente.
Un'implementazione corretta dovrebbe rifiutare o ignorare in sicurezza quel comando. Dovrebbe conservare prove sufficienti per spiegare successivamente l'esito.
L'esempio del prestito è utile perché collega questi dettagli a una decisione significativa. L'approvazione umana non è una pausa decorativa tra chiamate al modello.
È una transizione di stato con identità, autorizzazione, contesto della policy e requisiti di audit. Questo la rende un test di durabilità più incisivo di un assistente conversazionale che si riavvia dopo un errore.
La demo non dimostra la prontezza per la produzione
Databricks presenta un'architettura credibile, ma le sue stesse evidenze lasciano irrisolte la compliance per il credito, la scalabilità e la validazione dell'intero ciclo dei dati.
Il repository riporta 21 test superati che coprono sequenziamento del workflow, comportamento della revisione, costruzione OAuth, persistenza idempotente, contratti delle metriche, avvio dell'API e impostazioni del worker.
Un esercizio di recupero dopo un crash usa un provider deterministico. Interrompe l'esecuzione del worker e verifica che i progressi registrati sopravvivano al ritorno del processo.
Questi test supportano l'affermazione limitata sulla durabilità. Mostrano che il flusso di controllo e i contratti di persistenza dell'esempio si comportano come previsto in presenza di guasti selezionati.
Non convalidano l'agente come sistema di credito. I record dei richiedenti e le risposte dei provider sono fixture, mentre il provider scriptato predefinito evita una dipendenza da un modello live.
Il repository non stabilisce qualità del modello di credito, conformità normativa, sicurezza di produzione, disponibilità regionale o prestazioni su larga scala. Databricks dichiara direttamente questi limiti.
L'esercizio di crash locale è stato inoltre eseguito con Lakebase disabilitato. Isola il recupero di Temporal, ma non verifica il recupero lungo il percorso dati integrato completo.
Allo stesso modo, il percorso Change Data Feed rimane un'attività di abilitazione e distribuzione. L'esempio prepara le tabelle, ma non mostra l'arrivo osservato della cronologia end-to-end.
Change Data Feed era in Public Preview quando l'articolo è apparso. Lo stato di anteprima è rilevante per i team che richiedono impegni di supporto maturi o una copertura regionale convalidata.
Il database e il Workflow non condividono una transazione. Identificatori stabili e retry garantiscono convergenza, ma i team necessitano comunque di riconciliazione in caso di divergenza prolungata o imprevista.
Un processo di riconciliazione per la produzione dovrebbe individuare Workflow privi di proiezioni corrispondenti. Dovrebbe inoltre rilevare effetti del database confermati i cui risultati dell'Activity non siano mai entrati nella Event History.
La sincronizzazione delle policy merita lo stesso scrutinio. Un'esecuzione successiva può utilizzare una policy aggiornata senza distribuzione, ma un'esecuzione aperta necessita di una regola documentata sulla versione della policy.
Il comportamento di fallback crea un altro rischio. La demo può sostituire una policy di fixture quando Lakebase è disabilitato o una riga della policy non è disponibile.
Questo comportamento aiuta lo sviluppo locale, ma un fallback silenzioso sarebbe inaccettabile in molti ambienti regolamentati. Il sistema registra il fallback, ma i responsabili delle policy devono decidere se l'esecuzione debba continuare.
Le prestazioni rimangono non testate nelle evidenze pubblicate. I carichi di lavoro degli agenti possono creare scritture a raffica, cronologie lunghe, trascrizioni estese e code di revisione irregolari.
La retention della cronologia Temporal, il volume dei retry, la latenza del modello, la concorrenza dei worker, i limiti delle connessioni al database e gli aggiornamenti delle proiezioni influenzano tutti il comportamento del sistema.
L'autoscaling di Lakebase può rispondere alla domanda, ma contano comunque le nuove connessioni e i dati riscaldati. Lo scale-to-zero può inoltre scambiare l'efficienza nei periodi di inattività con la latenza di riattivazione.
I requisiti di sicurezza vanno oltre TLS e le credenziali temporanee. Una vera piattaforma di underwriting richiederebbe autorizzazioni rigorose, controlli sui dati sensibili, regole di retention e confini per l'accesso all'audit.
Anche la raccomandazione del modello necessita di una governance indipendente. Registrare prove e policy migliora la tracciabilità, ma non stabilisce che la raccomandazione sia equa o accurata.
Una valutazione completa testerebbe il ragionamento sulle azioni avverse, le prove mancanti, i dati conflittuali dei provider, le modifiche alle policy e i tentativi di manipolare gli input degli strumenti.
Dovrebbe inoltre testare incidenti operativi che attraversano i confini tra componenti. Tra gli esempi figurano sincronizzazione delle policy non disponibile, proiezioni ritardate, rotazione parziale delle credenziali e provider esterni non disponibili.
L'architettura dovrebbe quindi essere letta come orientata alla produzione, non certificata per la produzione. Questa distinzione rafforza il riferimento perché rende visibile il lavoro rimanente.
Databricks ha mostrato come assegnare responsabilità tra orchestrazione, archiviazione operativa e dati governati. Non ha eliminato la necessità di convalidare ogni contratto sotto carico reale.
Tre segnali mostreranno se questo pattern regge
Le prossime evidenze dovrebbero testare il recupero integrato, la coerenza delle policy e l'adozione oltre la dimostrazione controllata di underwriting.
Il primo segnale è un deployment Change Data Feed end-to-end osservato. Il sistema pubblicato prepara le tabelle operative, ma lascia incompiute l'attivazione del feed e la verifica della destinazione.
Una convalida riuscita dovrebbe tracciare una singola esecuzione dalle prove degli strumenti, attraverso la revisione umana, fino alla cronologia gestita da Unity Catalog. Dovrebbe inoltre documentare ritardi, duplicati, modifiche dello schema e recupero dopo un'interruzione.
Questo risultato rafforzerebbe l'affermazione secondo cui l'attività operativa può ritornare nella cronologia analitica governata. Una dipendenza continuativa da un percorso non verificato indebolirebbe la narrazione del ciclo completo dei dati.
Il secondo segnale è uno studio pubblico su carico e guasti che utilizzi Lakebase lungo tutto il test di recupero. Dovrebbe includere crash dei worker, retry del database, rotazione delle credenziali e ritardo delle proiezioni.
Risultati utili riporterebbero il comportamento di completamento, la distribuzione dei retry, il rifiuto dei comandi obsoleti e il tempo necessario affinché lo stato dell'applicazione converga.
Questo testerebbe l'architettura come sistema combinato anziché convalidare isolatamente il recupero di Temporal. Rivelerebbe inoltre dove emergono limiti di scalabilità o colli di bottiglia operativi.
Il terzo segnale è l'adozione in un workflow reale con revisione umana. Il credito è soltanto una dimostrazione, ma requisiti simili compaiono nell'elaborazione dei sinistri, negli approvvigionamenti, nella risposta alla sicurezza e nelle approvazioni regolamentate.
Un’implementazione credibile dovrebbe spiegare come versiona le policy, riconcilia lo stato, controlla il comportamento di fallback e verifica gli interventi umani. Queste pratiche contano più dello specifico provider di modelli.
Le evidenze provenienti da un’implementazione di questo tipo sosterrebbero il giudizio centrale dell’articolo. Gli agenti durevoli sono applicazioni distribuite, i cui fallimenti devono essere modellati esplicitamente.
Un’implementazione che riduce la durabilità ai checkpoint delle conversazioni indicherebbe la direzione opposta. Lascerebbe gli effetti collaterali, le attese prolungate e le policy variabili al di fuori del contratto di ripristino.
Per gli sviluppatori, la domanda immediata non è se ogni agente abbia bisogno di Temporal e Lakebase. Molte attività brevi e di sola lettura non giustificano due sistemi gestiti e un livello di proiezione.
La domanda è se un agente possa sopravvivere al proprio worker, modificare lo stato esterno, attendere le persone o applicare policy che cambiano in modo indipendente. Queste caratteristiche rendono necessaria un’esecuzione durevole.
Se descrivono il vostro sistema, esaminate l’architettura dell’agente, riproducete i relativi test di crash e mettete in discussione ogni effetto collaterale soggetto a retry. Poi testate cosa accade quando la verità dell’esecuzione e la verità operativa sono temporaneamente in disaccordo.
Questo è lo standard pratico per i team che cercano di creare agenti durevoli con Temporal e Lakebase. Iniziate con un workflow dalle conseguenze rilevanti, definite l’autorità di ciascun sistema e rendete le evidenze di ripristino parte della revisione del prodotto.
