Memoria comună a agenților AI: ce păstrăm, cine citește și când uităm
Seria II: De la infrastructură la proiecte agentice în producție. Episodul 10 din 20.
Într-un proiect cu mai mulți agenți AI, următorul agent trebuie să poată găsi deciziile relevante fără să primească întreaga istorie a conversațiilor. Dar o afirmație repetată de trei ori rămâne o afirmație, nu devine automat o decizie aprobată. Pentru portalul B2B fictiv al acestei serii, întrebarea utilă este: ce informație merită păstrată între sarcini și cine îi confirmă valabilitatea?
Patru lucruri pe care le numim prea ușor „memorie”
Contextul conversației este textul disponibil agentului în sesiunea curentă. Ajută la continuarea dialogului, însă poate conține idei abandonate și instrucțiuni contradictorii. Starea execuției păstrează pasul la care a ajuns un flux; un checkpoint este o salvare intermediară din care acesta poate fi reluat. Nu dovedește că toate enunțurile din flux sunt corecte.
Baza de cunoștințe conține documente, proceduri și specificații ale proiectului, cu propriile lor versiuni și proprietari. Memoria comună persistentă reține selectiv concluzii reutilizabile peste sesiuni: o decizie tehnică, o limitare confirmată ori rezultatul unui test. „Comună” înseamnă că agenții autorizați o pot consulta, nu că fiecare agent poate scrie sau citi orice.
Documentația LangGraph separă memoria de scurtă durată, legată de firul conversației, de memoria de lungă durată, disponibilă între conversații. Această separare este un exemplu de implementare, nu o obligație de a folosi acel produs. Metoda RAG poate regăsi pasaje relevante, dar relevanța unei căutări nu stabilește nici dreptul de acces, nici statutul de adevăr al pasajului.
Decizia principală: promovăm informația, nu transcrierea
Propunerea pentru portal este să stocăm o înregistrare numai dacă va influența o decizie ulterioară și poate fi verificată la sursă. Un agent de dezvoltare poate propune o intrare, însă schimbările care afectează contracte API, securitatea ori datele clienților cer validarea responsabilului desemnat. În schimb, o ipoteză de lucru poate rămâne în sarcină, cu termen scurt, fără să intre în memoria activă.
De exemplu, echipa decide că documentele încărcate în portal sunt vizibile numai organizației care le-a trimis. Aceasta este o regulă confirmată dacă există o specificație aprobată și teste care o verifică. Un mesaj precum „probabil vom permite partajarea între organizații” este doar o ipoteză. Agenții care dezvoltă portalul nu trebuie să o transforme în regulă. Dacă, mai târziu, portalul va include agenți pentru utilizatorii finali, aceștia vor avea o memorie separată, supusă drepturilor fiecărei organizații.
O fișă minimă poate avea: identificatorul proiectului și al subiectului, enunțul precis, tipul lui (decizie, constatare, ipoteză), sursa cu versiune sau referință la commit, autorul propunerii, persoana care a validat, data validării, versiunea fișei și data revizuirii. Proveniența este traseul prin care ajungem de la enunț la documentul ori testul original. Un link fără versiune poate deveni insuficient după modificarea documentului.
Nu stocăm parole, tokenuri, date personale inutile sau copii întregi de documente confidențiale doar pentru confortul căutării. Fișa poate indica locul autorizat al sursei. Datele sensibile rămân în sistemele proiectate pentru ele, cu politici proprii de acces și păstrare.
Cine poate citi și cine poate modifica
Un namespace este un spațiu logic care grupează înregistrări, de pildă după proiect și organizație. El ajută la structurare, dar numele său nu reprezintă o barieră de securitate. Aplicația trebuie să verifice identitatea și drepturile înaintea fiecărei citiri, căutări, scrieri ori ștergeri. Într-un portal cu clienți diferiți, filtrarea doar în promptul agentului este insuficientă: controlul se aplică în serviciul care furnizează datele.
Pentru agenții care construiesc aplicația, putem acorda citire pentru deciziile tehnice ale proiectului și drept de propunere pentru intrări noi. Aprobarea rămâne la proprietarul domeniului. Pentru un agent integrat în portal, drepturile sunt derivate din utilizatorul și organizația pe care îi deservește; nu primește implicit acces la notele interne de dezvoltare. Înregistrăm cine a citit sau a schimbat o fișă importantă și motivul operației, potrivit politicii de audit.
Aceasta este o regulă de proiectare, nu o funcție garantată de un anumit magazin de memorie. Documentul conceptual NIST din februarie 2026 discută identificarea agenților, autorizarea, delegarea și trasabilitatea acțiunilor. Este un document de explorare, nu certificarea unei arhitecturi concrete. Politica proiectului trebuie implementată și testată în sistemele alese.
Ce facem când doi agenți schimbă aceeași fișă
Să presupunem că un agent actualizează regula de acces după aprobarea unei specificații, iar altul lucrează dintr-un checkpoint mai vechi. Fără control, ultima scriere ar putea readuce o variantă depășită. O soluție propusă este versionarea optimistă: cititorul primește numărul versiunii, iar serverul acceptă schimbarea numai dacă acea versiune este încă actuală. La conflict, agenții recitesc sursele și solicită o decizie, fără a combina automat două reguli incompatibile.
Memoria activă indică o singură versiune autoritativă pentru fiecare decizie. Variantele vechi pot rămâne în jurnalul de modificări pentru audit, dar nu sunt oferite agentului ca instrucțiuni curente. Dacă un document sursă se modifică, fișa aferentă intră în revizuire. Sistemul nu deduce validitatea doar din faptul că aceeași propoziție apare în mai multe mesaje.
Când revizuim, expirăm și uităm
Fiecare fișă primește un proprietar și un termen de revizuire potrivit subiectului. O decizie despre contractul API se revizuiește când se schimbă versiunea contractului; o observație despre o eroare temporară poate expira la închiderea incidentului. Termenul nu înseamnă neapărat ștergere imediată, ci oprirea folosirii automate până la verificare. Stările propuse sunt: propusă, validată, în revizuire, înlocuită și retrasă.
Corectarea trebuie să ajungă și în indexul de căutare, în cache și în rezumatele derivate, altfel o versiune veche poate reapărea. Ștergerea din copiile de siguranță urmează politica lor de retenție; de aceea evităm de la început datele care nu trebuie memorate. Un studiu academic publicat ca preprint în iunie 2026 arată că datele introduse prin canale obișnuite pot contamina memoria persistentă a unui agent. Rezultatul indică un risc de proiectare, fără a demonstra că orice implementare va fi compromisă.
Pentru proiectul exemplificativ, rezultatul practic este un registru mic de decizii cu surse și revizuire, separat de conversații și de datele clienților. Echipa poate începe cu câteva fișe aprobate manual, poate testa ce vede fiecare rol și poate simula un conflict de versiune. Abia apoi merită automatizată propunerea de noi amintiri. Episodul următor va folosi aceste reguli când va evalua ce știe să facă un agent de programare în condițiile reale ale proiectului.
Surse
- LangGraph, Memory: memorie de scurtă și lungă durată
- LangGraph, Persistence: checkpoint-uri și retenție
- NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization, document conceptual, februarie 2026
- Dash și colaboratorii, From Untrusted Input to Trusted Memory, preprint, iunie 2026
