Memoria agenților AI: de ce contextul trăiește în afara modelului

Un LLM nu ține minte nimic între apeluri: fiecare cerere pornește de la zero. Memoria agentului AI stă în afara modelului, într-un strat care scrie, actualizează și șterge contexte. Diferența dintre un asistent util și unul care repetă greșeli e arhitectura acelui strat, nu mărimea ferestrei de context.

Discuția a revenit în prim-plan printr-un material semnat de Veljko Kovac, Head of FDE la Cognee, publicat pe blogul n8n (sursa). Textul are meritul de a pune degetul pe rana reală: majoritatea echipelor care construiesc agenți nu au o problemă de model, au o problemă de state management. Mai jos e analiza pe ce contează operațional, plus ce înseamnă pentru un business român care vrea să automatizeze fără să-și saboteze datele.

De ce „modelul nu are memorie" nu e un defect, ci o limitare de design

Fiecare request către un LLM e independent. Modelul citește promptul, returnează un răspuns și nu păstrează nimic. Pentru o întrebare singulară e perfect. Pentru un agent de suport care gestionează un follow-up, pentru un asistent de vânzări care pregătește un call de reînnoire sau pentru un workflow care rulează din oră în oră și ar trebui să știe ce a făcut ultima dată, modelul e inutil fără un strat extern.

Concluzia practică: memoria nu se rezolvă prin „model mai bun cu fereastră mai mare". Se rezolvă prin arhitectură. Iar arhitectura se decide înainte să scrii primul nod, nu după ce ai 40 de workflow-uri care scriu în locuri diferite.

Memorie scurtă vs. memorie lungă: două componente, nu una

Sursa separă corect cele două orizonturi de timp.

Memoria de scurtă durată ține starea imediată: mesaje recente, pași intermediari, output-uri de tool-uri, stadiul task-ului. Trăiește aproape de agent, des în harness. Când fereastra de context se umple, soluția comună e sumarizarea istoricului și reintroducerea sumarului în prompt. Funcționează până nu mai funcționează: sumarele pierd detaliu, iar unele output-uri nu ar trebui comprimate deloc (draft-uri intermediare, rezultate de calcule scumpe).

Memoria de lungă durată supraviețuiește între sesiuni. Ține preferințe de utilizator, rezultate ale task-urilor trecute, lecții despre ce a funcționat și, tot mai des, cunoștințe pe care agentul nu le-a generat singur: documente, tickete, înregistrări CRM. Aici apare nevoia de strat extern dedicat din prima zi, pentru că cineva trebuie să decidă ce se păstrează, cum se organizează și ce se returnează la fiecare cerere.

Mecanismul de livrare rămâne același în ambele cazuri: modelul primește un singur prompt. Memoria schimbă doar felul în care e asamblat acel prompt: mesajul nou, plus sesiunea curentă, plus ce e relevant din memoria lungă chiar în acel moment.

Cele patru noțiuni care se confundă constant

LLM memory, context engineering, RAG și agent memory sunt folosite interșanjabil, deși descriu locuri diferite unde poate sta cunoașterea. Un sistem real le folosește pe toate.

• LLM memory (în greutățile modelului): ce a absorbit modelul la antrenare. Pattern-uri comprimate, nu tabel de lookup, de aceea poate repeta cu încredere ceva depășit. Fine-tuning-ul adaugă cunoștințe de domeniu, dar e lent, scump și nu prinde nimic dintr-o sesiune live.
• Context engineering: alegerea a ce intră în fereastra de context la un apel anume. Ferestre mari ajută, dar nu rezolvă memoria: contextul dispare la finalul sesiunii, prompturile lungi costă, iar modelul nu acordă atenție egală unui input foarte lung.
• RAG: citește dintr-o sursă existentă și adaugă rezultatele în prompt. Limitarea cheie e direcția: RAG citește, dar nu scrie înapoi. Nu reține ce a întrebat userul săptămâna trecută sau ce fix a eșuat deja.
• Agent memory: începe exact de acolo unde agentul scrie înapoi. Capturează fapte noi, preferințe și rezultate pe măsură ce lucrează, apoi le retrage mai târziu.

Exemplul din material e bun și îl păstrez ca ilustrație conceptuală, nu ca rezultat măsurat: un asistent de vânzări care extrage cifrele trimestrului prin RAG, dar reține din conversații anterioare că utilizatorul vrea cifre EU în euro, defalcate pe țară.

Arhitecturi de memorie: compromisul real

Orice sistem de memorie are nevoie de trei piese: un store unde se persistă, o logică de scriere și o interfață de retrieval. Store-ul influențează direct celelalte două.

Baze de date vectoriale. Memorii transformate în embeddings, găsite prin similaritate semantică. Simplu de pornit, tooling matur. Dar similaritatea nu e totul: „Q3 sales" și „Q4 sales" stau aproape lipite în spațiul vectorial, nu există noțiune de ce fapt e actual, iar o intrare relevantă formulată diferit poate fi ratată complet.

Fișiere simple. Agentul ține un MEMORY.md pe care îl citește și îl editează. Transparent, versionabil, fără infrastructură. Dar retrieval-ul se reduce la a încărca tot sau a căuta text, iar partajarea unui fișier între mulți agenți devine rapid haos.

Grafuri de cunoaștere. Faptele devin entități și relații: raportul de vânzări acoperă deal-uri EU, deal-urile EU se înregistrează în euro, cifrele vin din exportul de billing. Retrieval-ul găsește un punct de intrare și urmează muchiile, deci agentul primește fapte legate logic de întrebare, nu doar similare fonetic. Costul: mai multă muncă la ingestie.

Sisteme hibride. În practică, niciun store unic nu acoperă tot. ID-urile exacte cer index structurat, relațiile cer graf, potrivirea fuzzy cere vectori, iar „ce prefera clientul în martie?" cere timestamp-uri. De aceea un strat de memorie nu e o bază de date: baza de date e doar unde stă informația, stratul decide ce se scrie, în ce formă și expune operațiile de write, retrieve, update și forget.

Legătura cu subiecte apropiate de pe site e directă: când discutăm despre cum devine baza de date recompensă pentru agenții AI, vorbim de fapt despre aceeași decizie de arhitectură, doar privită din unghiul sursei de adevăr.

Memoria trebuie administrată, nu doar acumulată

Un strat care doar crește devine mai prost în timp. Faptele se schimbă, preferințele se mută, intrările vechi încep să concureze cu cele corecte. Sursa identifică trei procese care trebuie tratate explicit:

1. Consolidare. Intrările brute se adună mai repede decât devin utile. Sistemul ar trebui să le transforme periodic în mai puține înregistrări de nivel superior (sumare, fapte derivate), păstrând o urmă înapoi la original.
2. Actualizare. Când un fapt se schimbă, o suprascriere oarbă pierde istoricul. Păstrarea informației temporale permite agentului să răspundă atât la „ce e adevărat acum?", cât și la „ce credeam în martie?".
3. Uitare. Unele date trebuie să dispară: dataset expirat, corectare, cerere de ștergere. Operațiune explicită, deliberată, separată de procesul mai moale prin care memoriile mai puțin utile își pierd relevanța.

Sistemele bune învață și din utilizare. Un răspuns confirmat crește ponderea memoriilor care l-au susținut; o corectare scade memoriile care au indus în eroare. Peste săptămâni, retrieval-ul ar trebui să devină mai precis, nu mai zgomotos.

Cum verifici dacă memoria ta funcționează cu adevărat

Benchmark-urile publice dau un prim semnal, dar au o capcană de dimensiune. Dacă întregul istoric al unui benchmark încape într-o fereastră de context modernă, poți sări peste memorie și să lipești tot în prompt, iar testul nu mai spune nimic despre stratul de memorie. Materialul dă repere concrete: conversațiile LoCoMo au în jur de 26k tokeni, varianta comună din LongMemEval aproximativ 115k, iar BEAM e cel mai solicitant, cu până la 10M tokeni și zece abilități de memorie testate. În plus, benchmark-urile verifică în general răspunsul final, nu ce a stocat efectiv memoria, nu cum rezistă după săptămâni de actualizări și nu cum se comportă când mai mulți agenți o partajează.

Testul care contează rămâne al tău: rulează același workflow cu memorie pornită și oprită și măsoară rezultatul care îți pasă. Tickete rezolvate, întrebări repetate mai puțin, follow-up-uri corecte. Aici fac o distincție pe care o repetăm constant în agenție: ce măsori e o constatare, ce presupui e o ipoteză. O verificare incompletă nu dovedește absența unei funcții.

Ce înseamnă pentru tine, antreprenor sau marketer în România

Dacă ai un magazin online, un serviciu B2B sau o echipă de vânzări cu CRM, întrebarea nu e „ce model folosim", ci „unde stă ce știm despre client între două interacțiuni". În multe firme românești răspunsul e: în capul agentului de vânzări, în trei foi de calcul și într-un canal de chat pe care nimeni nu-l citește. Exact acolo se pierde contextul.

Trei consecințe practice, fără promisiuni de cifre:

• Un agent de suport fără memorie lungă îți repetă întrebările și pare prost, oricât de bun e modelul din spate.
• Un workflow care rulează periodic fără stare ia decizii inconsistente: trimite aceeași notificare de două ori sau sare peste un pas pentru că nu știe ce a făcut la rularea anterioară.
• Un „creier al companiei" construit pe documente, tickete și note CRM devine util doar dacă cineva decide ce se păstrează și ce se șterge. Altfel, în șase luni ai o arhivă zgomotoasă în care retrieval-ul aduce fapte vechi lângă cele actuale.

Pentru marketingul online, logica se leagă de ce se întâmplă în piață: magazinele fizice devin citabile de agenți, iar Shopify UCP location search arată clar că datele structurate și consistente contează din ce în ce mai mult. Un strat de memorie bine întreținut e aceeași disciplină aplicată intern.

FAQ

Un LLM poate ține minte conversația fără un strat extern? Nu. Fiecare apel e independent, iar modelul nu păstrează nimic între cereri. Ce pare memorie e de fapt context reconstruit la fiecare apel din istoricul sesiunii și din memoria lungă.

E suficient RAG pentru un agent care lucrează în timp? Nu, pentru că RAG doar citește. Nu reține ce a întrebat utilizatorul, ce fix a eșuat sau ce preferință a exprimat anterior. Continuitatea cere un strat care scrie înapoi.

Ce benchmark ar trebui să folosesc ca să testez memoria? Unul al cărui istoric nu încape într-o fereastră de context, altfel testezi modelul, nu memoria. Pentru decizia reală, rulează propriul workflow cu memorie pornită și oprită și compară rezultatul operațional.

Concluzia ALLSoft Agency

AI-ul ajută real la analiză și planificare: structurează ce ai deja în tickete, documente și CRM, propune scheme de consolidare, semnalează unde ai date contradictorii. Dar decizia despre ce se păstrează, ce se actualizează și ce se șterge rămâne umană, iar execuția în workflow-uri rămâne treaba unui media buyer sau a unui operator care înțelege procesul, nu doar nodurile. Un strat de memorie greșit proiectat nu se repară cu un model mai scump.

Pasul concret îl face ALLSoft Agency: pornim de la întrebarea „ce context trebuie să supraviețuiască între două interacțiuni", măsurăm cu memorie pornită și oprită, și abia apoi alegem arhitectura. Fără hype, fără cifre inventate.