Când un agent AI execută un flux real de business, problema nu apare doar atunci când „greșește”, ci și atunci când reușește doar pe jumătate. De exemplu, poate crea o ofertă în CRM, poate trimite un email clientului, dar poate eșua la emiterea facturii sau la actualizarea stocului. În acel moment nu mai vorbim despre un simplu retry, ci despre un proces parțial reușit, cu efecte deja produse în mai multe sisteme.
Aici intervin compensating transactions. Microsoft descrie acest model ca o metodă de a anula sau corecta pașii deja executați atunci când o operațiune distribuită nu se finalizează complet. Important: nu este mereu un rollback clasic, în ordinea exact inversă. În procesele reale, „anularea” poate însemna anularea unei rezervări, marcarea unei comenzi pentru revizuire, emiterea unui storno sau trimiterea unei notificări interne.
Pentru firmele care implementează agenți AI, ideea-cheie este simplă: nu presupune că toate acțiunile pot fi șterse ca într-o tranzacție SQL. Dacă agentul a atins sisteme externe, email, CRM, ERP, facturare sau ticketing, trebuie să proiectezi din start ce faci când pasul 3 reușește, iar pasul 4 eșuează.
O abordare practică este saga pattern. Conform documentației Microsoft și AWS, o saga împarte procesul în pași locali, fiecare cu propria acțiune și, dacă este cazul, cu propria acțiune compensatorie. Dacă un pas eșuează, orchestratorul pornește compensările pentru pașii anteriori. Pentru un IMM, asta înseamnă să definești explicit perechi de tipul: „creează comandă” / „anulează comandă”, „rezervă slot” / „eliberează slot”, „generează task” / „închide taskul și marchează motivul”.
Primul principiu tehnic este idempotency. Microsoft recomandă ca pașii de compensare să fie idempotent, iar Stripe explică foarte clar de ce: un retry sigur nu trebuie să dubleze aceeași operațiune. Dacă agentul sau orchestratorul retrimite aceeași cerere după un timeout, rezultatul trebuie să rămână același, nu să apară două facturi, două rezervări sau două emailuri. În practică, asta înseamnă chei unice de operațiune, verificarea stării înainte de execuție și endpoint-uri care pot răspunde corect la cereri repetate.
Al doilea principiu este separarea pașilor „compensabili” de cei greu reversibili. În saga pattern există ideea de pivot transaction: după acel punct, procesul merge mai degrabă pe pași retryable decât pe pași ușor anulabili. Pentru business, regula sănătoasă este să lași acțiunile sensibile cât mai târziu posibil: plata, notificarea externă finală, emiterea documentului fiscal sau schimbarea unui status vizibil clientului ar trebui să vină după validări, verificări și confirmări interne.
Al treilea principiu este human-in-the-loop. Documentația LangGraph arată explicit că un flux poate fi întrerupt pentru approve or reject, review and edit state sau validarea inputului uman. Pentru procesele cu impact financiar, contractual sau reputațional, agentul AI nu ar trebui să compenseze singur orice situație ambiguă. O regulă practică este: dacă pasul de compensare afectează bani, documente sau comunicarea către client, ridică execuția într-o coadă de aprobare umană.
Al patrulea principiu este audit trail complet. Temporal arată că un workflow trebuie să aibă event history, iar AWS Step Functions oferă execution event history și detalii despre retries. Pentru firme, asta se traduce printr-o cerință foarte concretă: pentru fiecare execuție trebuie să poți răspunde rapid la cinci întrebări — ce a încercat agentul, ce a reușit, ce a eșuat, ce compensări a lansat și cine a aprobat excepțiile. Fără acest istoric, remedierea devine lentă și riscantă.
Al cincilea principiu este monitorizarea activă. Nu este suficient să ai loguri; trebuie să ai alerte pentru execuții blocate, compensări eșuate, număr neobișnuit de retry-uri și fluxuri care stau prea mult în așteptare umană. Microsoft mai subliniază că uneori compensarea însăși poate eșua, caz în care sistemul trebuie să rețină progresul și să poată relua de unde a rămas sau să ceară intervenție manuală.
Dacă vrei o regulă simplă pentru implementare, ea este aceasta: fiecare pas important al agentului AI trebuie să aibă definit înainte de lansare un „do”, un „undo”, o cheie de idempotency, un prag de retry și o condiție clară de escaladare către om. Așa reduci haosul operațional când procesul se rupe la mijloc și transformi automatizarea AI dintr-un experiment fragil într-un sistem controlabil.
