Wprowadzenie pamięci agentów w Databricks: wykorzystywanie wcześniejszej pracy ponownie
Databricks wprowadził w wersji beta pamięć agentów, kwestionując praktykę, w której agenci przedsiębiorstw muszą na nowo odkrywać to, czego nauczyli się w poprzednich rozmowach. Ogłoszenie z 20 października, Introducing Agent Memory on Databricks, wprowadza trwały kontekst do Agent Bricks, platformy firmy do tworzenia agentów. Praktyczne pytanie brzmi, czy zachowywanie doświadczeń zapewnia wiarygodną poprawę w zmiennych zadaniach biznesowych.
Główne porównanie dotyczy zarządzanej pamięci kontra wielokrotne odkrywanie informacji na nowo i własna infrastruktura pamięci. Programiści korporacyjni muszą zdecydować, czy utrzymywanie własnego systemu nadal uzasadnia jego koszt inżynieryjny. Amazon’s AgentCore już oferuje zarządzaną pamięć, dlatego Databricks wchodzi do istniejącej rywalizacji o to, gdzie powinna znajdować się zgromadzona wiedza agenta.
Dla nabywców to ogłoszenie rodzi bardziej konkretne pytanie niż to, czy asystent pamięta preferowany format odpowiedzi. Czy platforma potrafi zachować użyteczne korekty, właściwie je stosować i wyjaśnić, kiedy zapamiętane informacje wpłynęły na odpowiedź? To połączenie decyduje o tym, czy pamięć staje się przewagą operacyjną, czy kolejnym źródłem błędów.
Wprowadzenie pamięci agentów w Databricks zapewnia trwałość kontekstu
Databricks oferuje pamięć między sesjami jako obsługiwaną usługę, przenosząc część ciężaru wdrożeniowego z zespołów aplikacyjnych.
W ogłoszeniu dotyczącym pamięci agentów firma opisuje zarządzane historie rozmów, trwałe wspomnienia oraz procesy działające w tle, które konsolidują to, co agenci powinni zachować. Usługa działa na Lakebase, zarządzanej przez Databricks bazie danych Postgres. Databricks twierdzi, że programiści mogą sprawdzać, eksportować i usuwać zapamiętane wpisy.
Zmienia to punkt wyjścia dla aplikacji przedsiębiorstwa. Wcześniej zespół, który samodzielnie budował trwałość danych, musiał połączyć magazynowanie z zasadami wyboru i odzyskiwania przydatnych informacji. Opcja zarządzana pozwala takiemu zespołowi ocenić istniejące wdrożenie, zanim zdecyduje się na własne.
To rozróżnienie ma znaczenie, ponieważ zachowanie transkrypcji nie prowadzi automatycznie do użytecznej pamięci. Transkrypcja rejestruje to, co się wydarzyło, w tym błędy, porzucone podejścia i tymczasowe założenia. Użyteczna pamięć wymaga oceny, które elementy powinny wpływać na przyszłą pracę.
Rozważmy przykładowego asystenta analitycznego, który otrzymuje korektę definicji przychodu. Korekta może dotyczyć działu, okresu sprawozdawczego lub konkretnego pulpitu. Zapamiętanie zdania bez jego zakresu grozi zastosowaniem wczorajszej odpowiedzi do innego pytania.
W tym miejscu ogłoszenie staje się istotne nie tylko dla personalizacji. Preferencja dotycząca tonu wpływa na prezentację. Zapamiętana definicja biznesowa wpływa na treść odpowiedzi i potencjalnie na działania, które po niej następują.
Decyzja inżynieryjna dotyczy więc odpowiedzialności w takim samym stopniu jak magazynowania danych. Jeśli programiści przyjmą zarządzaną pamięć, nadal muszą określić, które zachowane informacje należą do ich aplikacji. Potrzebują też sposobu na zakwestionowanie wpisu, który wydaje się autorytatywny, ale przestał obowiązywać.
Introducing Agent Memory on Databricks daje tym zespołom opcję infrastrukturalną. Nie oznacza jednak, że każda rozmowa powinna tworzyć trwałą wiedzę. Selektywne zachowywanie pozostaje decyzją produktową, zwłaszcza gdy użytkownicy łączą trwałe preferencje z tymczasowymi prośbami.
Aplikacja może zasadnie pamiętać preferowany przez użytkownika format raportów, jednocześnie odmawiając zachowania wstępnej prognozy. Oba stwierdzenia pojawiają się w rozmowie, ale niosą różne oczekiwania. Traktowanie ich identycznie ułatwiłoby wdrożenie trwałości, lecz utrudniłoby zaufanie do niej.
Natychmiastowa zmiana jest zatem konkretna, ale ograniczona. Databricks oferuje teraz programistom zarządzane miejsce do zachowywania doświadczeń między rozmowami. To, czy dane doświadczenie zasługuje na ponowne wykorzystanie, zależy od zasad aplikacji i dowodów stojących za każdym wspomnieniem.
Ta granica kształtuje stawkę biznesową. Zespoły mogą przenieść pracę infrastrukturalną na platformę, ale nie mogą przenieść na nią własnego rozumienia tego, co stanowi ważną wiedzę biznesową.
Zespoły przedsiębiorstw stają przed inną decyzją: tworzyć czy kupować
Pod presją znajdują się zespoły utrzymujące infrastrukturę pamięci równolegle z agentami, które od niej zależą.
Dla wewnętrznej grupy platformowej własna pamięć oznacza ciągłe zobowiązanie. Ktoś musi badać brakujące wpisy, nieodpowiednie odzyskiwanie informacji, sprzeczne korekty i nieudane aktualizacje. Te obowiązki pozostają także po tym, jak początkowa demonstracja zacznie działać.
Usługa zarządzana zmienia porównanie z dostępności funkcji na wartość operacyjną. Pytanie brzmi, czy własne wdrożenie zapewnia wystarczającą kontrolę lub specjalizację, aby uzasadnić jego utrzymanie. To bardziej wymagający standard niż samo wykazanie, że agent potrafi zapisywać informacje.
Istnieją uzasadnione powody, by zachować własne podejście. Organizacja może potrzebować wyspecjalizowanych zasad retencji, nietypowych granic wdrożenia lub formatu pamięci współdzielonego przez istniejące systemy. Wymagania te zasługują na ocenę, a nie na założenie, że zarządzana infrastruktura zawsze wygrywa.
Z drugiej strony zespół o standardowych wymaganiach niewiele zyskuje na odtwarzaniu znanej infrastruktury tylko dlatego, że już posiada aplikację. Jego ograniczona uwaga inżynieryjna może przynieść większą wartość dzięki lepszym ocenom lub bardziej przejrzystym kontrolom użytkownika.
Wejście Databricks daje też nabywcom korporacyjnym kolejny punkt odniesienia. Dokumentacja typów pamięci AgentCore firmy Amazon opisuje przechowywanie surowych interakcji i długoterminowych zapisów wyodrębnianych przez przetwarzanie w tle. Opisuje również konsolidację i odzyskiwanie informacji w późniejszych sesjach.
To podobieństwo wyznacza konkurencyjny poziom bazowy. Trwała pamięć jest już funkcją platformową dostępną u innego dużego dostawcy. Databricks musi konkurować jakością wdrożenia, dopasowaniem operacyjnym i integracją z obciążeniami, które faktycznie realizują klienci.
Dostępna dokumentacja nie wskazuje zwycięzcy pod względem wydajności między tymi usługami. Opisy architektury wyjaśniają zamierzone działanie, ale nie zastępują równoważnych testów. Uczciwe porównanie powinno utrzymywać stałe zadanie, model, historię i zasady punktacji.
Dla nabywców oznacza to, że wybór dostawcy powinien wynikać ze wzorców awarii aplikacji. Asystent wsparcia, który zapomina preferencje, ma inne wymagania niż agent analityczny, który wielokrotnie wybiera niewłaściwe źródło. Jakość pamięci musi być mierzona względem konkretnego problemu, którego rozwiązanie jest kupowane.
Rozmowy zakupowe muszą także odróżniać wygodę od zależności. Konsolidacja infrastruktury może zmniejszyć liczbę systemów obsługiwanych przez organizację. Może również sprawić, że migracja stanie się bardziej doniosła, gdy zgromadzony kontekst stanie się częścią zachowania aplikacji.
Wpisy możliwe do wyeksportowania pomagają, lecz sam eksport nie gwarantuje równoważnego zachowania w innym miejscu. Inny system może wybierać inne wspomnienia lub inaczej interpretować ten sam zachowany tekst. Przenośność zasługuje zarówno na test zachowania, jak i test transferu danych.
Najmocniejszy argument za zakupem zarządzanej pamięci jest zatem praktyczny: usługa powinna ograniczać koszty utrzymania, zachowując kontrolę potrzebną aplikacji. Nabywcy powinni oczekiwać dowodów obu tych efektów, zanim uznają konsolidację infrastruktury za usprawnienie.
Presja spada zarówno na własne wdrożenia, jak i na dostawców usług zarządzanych. Każdy z nich musi wyjaśnić, jak jego podejście poprawia ukończoną pracę, zamiast jedynie zwiększać ilość informacji, które agent może zachować.
Mechanizm zależy od wyboru tego, co zasługuje na ponowne wykorzystanie
Kluczowy problem projektowy polega na zdecydowaniu, które doświadczenia powinny wpływać na kolejne zadanie.
Dokumentacja potoku pamięci Databricks opisuje przetwarzanie w tle, które wyodrębnia trwałe informacje, łączy nakładające się wpisy i reorganizuje zapisane wspomnienia. Programiści mogą przekazywać instrukcje dotyczące tego, co należy zachować. Udokumentowany projekt faworyzuje fakty i procedury nadające się do ponownego użycia, zamiast zmiennych wartości, które powinny pochodzić z bieżących źródeł.
To rozróżnienie ma bezpośrednie konsekwencje dla analityki przedsiębiorstw. Zapamiętanie sposobu obliczania wskaźnika może pomóc agentowi powtórzyć prawidłowy proces. Zapamiętanie poprzedniej wartości wskaźnika może prowadzić do nieaktualnej odpowiedzi, gdy zmienia się sytuacja biznesowa.
Przykładowy asystent sprzedaży wyraźnie pokazuje tę różnicę. Mógłby zachować zasadę, że zespół wyklucza anulowane umowy z konkretnego raportu. Powinien jednak nadal pozyskiwać bieżące dane o umowach podczas przygotowywania następnego raportu.
Zachowana reguła ogranicza konieczność ponownego odkrywania informacji, nie zastępując świeżych dowodów. Jeśli organizacja zmieni tę regułę, pamięć wymaga jednak odpowiedniej korekty. Skuteczne ponowne wykorzystanie zależy więc zarówno od zachowania, jak i rewizji.
Przetwarzanie w tle tworzy kolejną granicę decyzyjną. Dokumentacja potoku umożliwia uruchomienia ręczne lub zaplanowane, mniej więcej co 24 godziny. Zaplanowaną konsolidację należy więc rozumieć jako przetwarzanie opóźnione, a nie gwarancję, że każda nowa korekta natychmiast zmieni wszystkie przyszłe interakcje.
Dla projektantów aplikacji implikacja jest prosta. Korekta potrzebna przy następnym żądaniu użytkownika wymaga innego traktowania niż wiedza, która może poczekać na późniejszą konsolidację. Użytkownik nie powinien musieć rozumieć harmonogramu przetwarzania, aby wiedzieć, czy korekta zadziałała.
Dokumentacja mówi również, że utrzymanie może zmieniać wpisy zapisane bezpośrednio przez agenta. Oznacza to, że przechowywane wspomnienie jest częścią ewoluującej interpretacji rozmowy. Nie musi być trwałą kopią pierwotnego stwierdzenia.
Stwarza to pytanie o odpowiedzialność dla zespołów produktowych. Jeśli zapamiętana instrukcja zmieni się podczas konsolidacji, aplikacja powinna dysponować wystarczającymi dowodami, by wyjaśnić wynikające z tego zachowanie. W przeciwnym razie użytkownik obserwuje, jak asystent zmienia interpretację bez zrozumiałego powodu.
Przydatną analogią jest analityk prowadzący notatki robocze. Notatki pomagają tylko wtedy, gdy zachowują istotne warunki i pozostają odróżnialne od zweryfikowanych materiałów źródłowych. Zachowane podsumowanie agenta zasługuje na podobną kontrolę.
To samo rozróżnienie pojawia się w zarządzaniu wiedzą osobistą: gromadzenie informacji i czynienie ich użytecznymi to zadania powiązane, lecz odrębne. W przypadku agentów przedsiębiorstw użyteczność zależy także od tego, czy zachowane informacje nadal są odpowiednie dla bieżącego żądania.
Mechanizm ten sprawia, że pamięć staje się aktywną częścią zachowania aplikacji. Wybiera, kompresuje i aktualizuje doświadczenia, zanim rozpocznie się kolejne zadanie. Zespoły oceniające usługę powinny oceniać te przekształcenia, zamiast traktować skuteczne przechowywanie jako linię mety.
Benchmark potwierdza ograniczone twierdzenie dotyczące wydajności
Databricks informuje o poprawie wyników w swoim benchmarku dla przedsiębiorstw, ale rezultaty te nie potwierdzają uniwersalnych korzyści.
Badania firmy Databricks dotyczące MemCurrent opisują architekturę stojącą za tym wydaniem. W wewnętrznym benchmarku Databricks raportuje wskaźnik zaliczeń na poziomie 68,4% z MemCurrent, wobec 22,3% bez pamięci. Firma podaje również zużycie o 31% mniejszej liczby tokenów i o 26% szybsze wykonywanie.
Wewnętrzny benchmark obejmuje 114 przypadków dotyczących 29 użytkowników i 2233 historycznych sesji. Databricks twierdzi, że przygotował ocenę na podstawie przedsiębiorstwowych rozmów o danych i zweryfikował te przypadki. Są to wyniki raportowane przez firmę, a nie niezależna walidacja każdego wdrożenia.
Badanie przedstawia też przykładową poprawę przepływu pracy: powiązane zadanie uzupełniające wymagało dwóch wywołań narzędzi i 41 sekund, po tym jak wcześniejsze zadanie wymagało 11 wywołań i niemal sześciu minut. Przykład wspiera proponowany mechanizm unikania powtarzanego rozpoznawania. Nie ustala jednak średniej poprawy, jakiej powinni oczekiwać klienci.
Rozróżnienie między przykładem a oczekiwanym wynikiem ma znaczenie. Powtarzane zadanie z kontekstem nadającym się do ponownego wykorzystania stanowi korzystną okazję dla pamięci. Nowe zadanie z niepowiązanymi wymaganiami może niewiele zyskać na informacjach historycznych.
Podobnie niższa liczba tokenów mierzy konkretny zasób, a nie całe obciążenie operacyjne. Zespoły nadal muszą uwzględnić pracę potrzebną do tworzenia, utrzymywania, sprawdzania i oceniania pamięci. Decyzja o wdrożeniu powinna uwzględniać całą aplikację.
Wyniki są najbardziej użyteczne jako powód do przetestowania konkretnej hipotezy. Jeśli agent wielokrotnie na nowo odkrywa stabilną wiedzę biznesową, zachowane doświadczenie powinno ograniczyć tę powtarzalność. Hipoteza staje się słabsza, gdy wcześniejsze rozmowy oferują niewiele istotnych informacji.
Ocena powinna również obejmować zadania, w których pamięć powinna pozostać niewykorzystana. W przeciwnym razie system może sprawiać wrażenie skutecznego, wstawiając kontekst historyczny do każdej odpowiedzi. Selektywność ma znaczenie, ponieważ nieistotne wspomnienia same tworzą rozproszenie.
Niezależne badania zapewniają szersze ramy oceny. Benchmark LongMemEval, przedstawiony na ICLR 2025, testuje ekstrakcję, rozumowanie między sesjami, rozumowanie czasowe, aktualizacje wiedzy i powstrzymywanie się od odpowiedzi. Powstrzymywanie się od odpowiedzi oznacza odmowę udzielenia odpowiedzi, gdy dostępne dowody nie uzasadniają odpowiedzi.
Te kategorie pokazują, dlaczego proste przywoływanie informacji jest niepełną miarą. Asystent może trafnie odzyskać stare stwierdzenie, a mimo to zastosować je w niewłaściwym momencie. Może też zawieść, odpowiadając z pewnością, gdy jego pamięć nie zawiera żadnych istotnych dowodów.
Dla nabywców korporacyjnych użyteczne pytanie jest zatem węższe niż to, czy pamięć poprawia wyniki benchmarków. Czy poprawia zadania, które faktycznie wykonują ich pracownicy, w tym przypadki ze zmienionymi definicjami lub sprzecznymi instrukcjami?
Wprowadzenie Agent Memory na Databricks stwarza możliwość przeprowadzenia takiego porównania z wykorzystaniem zarządzanej infrastruktury. Opublikowane wyniki uzasadniają zainteresowanie, jednak własna ocena aplikacji musi ustalić, czy raportowany mechanizm da się przenieść.
To dająca się obronić interpretacja dowodów. Firma przedstawiła mierzalne twierdzenie wraz z opisaną oceną. Klienci nadal potrzebują wyników odzwierciedlających ich własne historie, uprawnienia i decyzje biznesowe.
Własność pamięci wymaga czegoś więcej niż identyfikatora użytkownika
Trwały kontekst wymaga wyraźnych zasad bezpieczeństwa i usuwania, ponieważ zapamiętane informacje mogą przetrwać rozmowę, w której powstały.
Dokumentacja Databricks dotycząca pamięci i sesji stwierdza, że usunięcie sesji nie usuwa pamięci. Rozróżnia też partycjonowanie według użytkownika od kontroli dostępu. Identyfikator aktora wybiera, których wpisów używa operacja, ale podmiot mający dostęp do magazynu może odczytać wpisy należące do innych aktorów.
Dokumentacja zaleca wyprowadzanie tego identyfikatora ze zweryfikowanej tożsamości w zaufanym kodzie aplikacji. W przypadku ścisłej izolacji tenantów zaleca oddzielne magazyny. Ostrzega też, że interfejsy i zachowanie wersji beta mogą się zmienić.
Są to istotne szczegóły wdrożeniowe dla nabywcy oceniającego to wydanie. Pole oznaczające informacje według użytkownika nie egzekwuje automatycznie granicy bezpieczeństwa. Aplikacja musi prawidłowo połączyć tożsamość, uprawnienia i strukturę przechowywania.
Przykładowe wdrożenie obsługi klienta pokazuje ten problem. Zapamiętana preferencja może być nieszkodliwa w obrębie własnego konta klienta, lecz nieodpowiednia w rozmowie innego klienta. Prawidłowe odzyskiwanie informacji wymaga, aby aplikacja ustaliła właściwą tożsamość, zanim model zażąda jakiejkolwiek pamięci.
Usuwanie stwarza inny problem. Użytkownik może racjonalnie sądzić, że usunięcie rozmowy usuwa to, czego asystent się z niej nauczył. Jeśli informacje pochodne przetrwają, produkt musi jasno wyjaśnić to rozróżnienie.
To implikacja projektowa dla aplikacji, a nie dowód, że konkretne wdrożenie niewłaściwie obsługuje usuwanie. Udokumentowane rozdzielenie czyni z tego pytanie, na które zespoły muszą odpowiedzieć. Kompletna polityka usuwania powinna uwzględniać zarówno pierwotną interakcję, jak i zachowane z niej informacje.
Korekta zasługuje na podobną uwagę. Zastąpienie fałszywego wspomnienia powinno wpływać na przyszłe zachowanie, ale zespoły muszą też rozumieć, jak korekta oddziałuje z pozostałą historią. W przeciwnym razie te same podstawowe dowody mogą ponownie wesprzeć błędną interpretację.
Pamięć może również zachowywać instrukcje, które nigdy nie powinny były uzyskać trwałego autorytetu. Rozważmy przykładowy dokument zawierający mylące wskazówki operacyjne. Jeśli agent podsumuje te wskazówki jako zaakceptowaną praktykę, błąd może wpłynąć na późniejsze zadania wykraczające poza pierwotny przegląd dokumentu.
Ten scenariusz wymaga oceny autorytetu źródła i zachowania retencji. Nie powinien być przedstawiany jako wykryta luka w Databricks. Istotne pytanie brzmi, czy aplikacja odróżnia preferencję zatwierdzoną przez użytkownika od niezaufanej treści napotkanej podczas pracy.
Doświadczenie produktowe ma tu równie duże znaczenie jak backend. Użytkownicy potrzebują zrozumiałych sposobów sprawdzania ważnych wspomnień, ich poprawiania i żądania usunięcia. Możliwość techniczna ma ograniczoną wartość praktyczną, jeśli jej mechanizmy kontroli pozostają niedostępne dla osób, których dotyczą.
Dla programistów lekcja operacyjna jest konkretna. Pamięć wprowadza kolejną ścieżkę, przez którą informacje trafiają do odpowiedzi. Debugowanie musi więc uwzględniać, co agent zapamiętał, dlaczego odzyskał te informacje oraz czy aplikacja autoryzowała ich użycie.
Te obowiązki nie znikają wraz z zarządzanym przechowywaniem. Stają się częścią decyzji o tym, czy zarządzana usługa pasuje do granic zaufania aplikacji.
Na co zwracać uwagę po ogłoszeniu wersji beta
Kolejne dowody powinny połączyć zarządzaną pamięć z powtarzalnymi wynikami klientów i jaśniejszymi ograniczeniami operacyjnymi.
Pierwszym sygnałem jest niezależna lub opublikowana przez klienta ocena powtarzalnych zadań przedsiębiorstwowych. Użyteczne wyniki porównywałyby tę samą aplikację z pamięcią i bez niej, uwzględniając korekty, zmieniające się fakty i niepowiązane zapytania. Takie dowody sprawdziłyby, czy zachowany kontekst usprawnia pracę poza przypadkami wybranymi przez firmę.
Przekonująca ocena wyjaśniałaby porażki obok sukcesów. Jeśli wydajność poprawia się wyłącznie przy ściśle powtarzanych pytaniach, korzyść pozostaje węższa niż trwałe rozumienie biznesu. Jeśli zyski utrzymują się w powiązanych, lecz różnych zadaniach, argument za doświadczeniem nadającym się do ponownego wykorzystania staje się silniejszy.
Drugim sygnałem jest rozwój produktu dotyczący ograniczeń operacyjnych i kontroli użytkownika. Nabywcy powinni obserwować udokumentowane zmiany dotyczące harmonogramowania, skali, izolacji, inspekcji i zachowania przy usuwaniu. Te szczegóły określają, które aplikacje mogą polegać na usłudze bez budowania rozbudowanej infrastruktury wspierającej.
Postęp w zakresie tych mechanizmów kontroli wzmocniłby argument „budować czy kupić”. Jeśli zespoły nadal potrzebują rozległych niestandardowych mechanizmów do zarządzania zwykłym zachowaniem pamięci, przewaga operacyjna staje się mniej przekonująca. Istotną miarą jest to, jak wiele odpowiedzialności usługa rzeczywiście eliminuje.
Trzecim sygnałem jest sposób, w jaki konkurenci ułatwiają weryfikację własnych twierdzeń dotyczących pamięci. Istniejąca oferta Amazon oznacza, że kategoria ma już alternatywy. Jaśniejsze oceny porównawcze pomogłyby klientom odróżnić różnice w zachowaniu od różnic w terminologii.
Same odpowiedzi konkurencji nie potwierdziłyby przewagi Databricks. Pokazałyby, że zarządzana pamięć stała się kolejnym wymiarem wyboru platformy. Dowody na to, że aplikacje mogą zachowywać użyteczne zachowanie między usługami, wyjaśniłyby również, jakiej przenośności mogą oczekiwać nabywcy.
Te sygnały należą do siebie, ponieważ zakup dotyczy systemu działającego w czasie. Wydajność bez kontroli rodzi trudne pytania operacyjne. Kontrola bez użytecznej poprawy wykonywania zadań pozostawia nabywcom utrzymywanie kolejnej funkcji, której wartość pozostaje niepewna.
Dla pracowników wiedzy rezultat powinien być widoczny w codziennym użyciu. Asystent powinien wymagać mniej powtarzanych korekt, pozostając jednocześnie responsywny, gdy okoliczności się zmieniają. Zapamiętywanie przestarzałego założenia z większą konsekwencją mijałoby się z celem.
Dla programistów ogłoszenie tworzy ukierunkowany eksperyment. Wybierz powtarzalny przepływ pracy z możliwymi do zidentyfikowania błędami związanymi z pamięcią, a następnie porównaj wyniki w spójnych warunkach. Oddziel bieżące dowody od zapamiętanych wskazówek i zbadaj przypadki, w których informacje historyczne powinny pozostać poza odpowiedzią.
Wprowadzenie Agent Memory na Databricks daje zespołom przedsiębiorstw konkretną usługę do oceny względem ich obecnego podejścia. Zacznij od pracy, którą agent wielokrotnie wykonuje błędnie lub niepotrzebnie powtarza. Zidentyfikuj, które korekty zasługują na trwałość, a które fakty muszą pozostać powiązane z bieżącymi źródłami. Następnie sprawdź, czy zachowany kontekst poprawia późniejsze decyzje, nie przenosząc przestarzałych założeń w przyszłość. Zapytaj, kto może sprawdzić wspomnienie, kto może je zmienić i co usunięcie oznacza w całej aplikacji. Traktuj opublikowane benchmarki jako hipotezę wartą przetestowania na własnych zadaniach. Zanim rozszerzysz wdrożenie, czy Twój zespół potrafi wykazać, że agent zapamiętuje właściwą lekcję i przestaje jej używać, gdy przestaje ona mieć zastosowanie?
