Cos'è l'esecuzione durevole?

L'esecuzione durevole è la garanzia con cui un flusso di lavoro di lunga durata, agentico o meno, sopravvive a crash, riavvii e deploy senza perdere lo stato accumulato: a ogni passo completato il motore scrive un checkpoint, e se il processo muore a metà, alla ripartenza riprende esattamente da lì, non dall'inizio. La differenza rispetto a un retry generico è tutta qui: un retry rilancia la funzione da capo sperando che sia innocuo rifare ciò che era già andato a buon fine; l'esecuzione durevole registra cosa è già successo e lo salta, riprendendo dal passo interrotto. Il motore che offre questa garanzia esiste sia come libreria dentro l'applicazione sia come servizio esterno a cui il codice delega l'orchestrazione: il denominatore comune è che lo stato di esecuzione, incluso il punto esatto raggiunto in una funzione che può durare ore o giorni, non vive nella memoria di un singolo processo ma su uno storage persistente consultato a ogni ripresa.

Non è un retry e non è compensazione

Vale la pena separare l'esecuzione durevole da due pattern vicini con cui viene confusa. Un semplice retry con backoff rilancia una singola chiamata quando fallisce, senza alcuna nozione di dove si trovasse l'intero flusso: utile, ma troppo granulare per garantire che un processo di venti passi sopravviva a un riavvio del server all'ottavo. Il saga pattern, invece, risponde a un problema logico diverso: cosa fare quando un passo fallisce per sempre e bisogna disfare gli effetti già prodotti dai passi precedenti con azioni compensative. L'esecuzione durevole non decide se disfare o continuare: garantisce solo che, qualunque cosa il flusso stia facendo, l'infrastruttura sotto non gli faccia perdere il lavoro già svolto per un crash, un riavvio o un deploy. Le due cose si compongono bene: un flusso durevole può includere una saga al suo interno, ma risolvono problemi diversi.

Un esempio enterprise concreto

Un agente che elabora un lotto di diecimila fatture, ognuna con una chiamata a un servizio di riconoscimento documentale, una verifica su un ERP esterno e la scrittura del risultato, può girare per ore. Senza esecuzione durevole, un deploy dell'applicazione a metà lotto, o un crash del container per esaurimento memoria, costringe a rilanciare tutto da capo: le fatture già elaborate vengono rielaborate, e se la chiamata all'ERP non è stata progettata per essere ripetibile in sicurezza, quella rielaborazione rischia di duplicare una scrittura, lo stesso problema descritto in idempotenza e backfill. Con un motore durevole, il riavvio riprende dalla fattura 6.412, non dalla prima, e ogni chiamata già andata a buon fine non viene ripetuta.

Perché conta per chi decide

Perché la maggior parte dei team che costruisce agenti persistenti o pipeline lunghe finisce per reinventare a mano un pezzo di questa garanzia: una colonna "ultimo passo completato" in un database, un job scheduler che rilancia da zero, un flag di idempotenza aggiunto dopo il primo incidente in produzione. È lavoro fragile e ricorrente, lo stesso che un motore di esecuzione durevole risolve una volta sola. Il costo di non averlo non è teorico: è il lavoro perso su un batch lungo, sono gli effetti collaterali duplicati di un retry mal progettato, è il tempo ingegneristico speso a ricostruire a mano una garanzia che esiste già come componente. Chi valuta un agent harness o una piattaforma per agent ops dovrebbe chiedere esplicitamente come viene gestita questa garanzia, perché la risposta separa un flusso che tollera un riavvio in produzione da uno che no.