O czym jest ten film
- Istnieją dwa różne światy agentów AI: agenty osobiste (druga mózg) i agenty produkcyjne wdrażane dla wielu użytkowników.
- Agenty osobiste są napędzane plikami markdown (np. „LLM Wiki” w stylu Karpathy’ego) — proste, elastyczne, ale nie skalują się.
- Gdy agent trafia do produkcji, potrzeba kontroli dostępu, audytowalności, wyszukiwania na dużą skalę i optymalizacji kosztów — czego markdown nie zapewnia.
- Subskrypcyjne SDK agentów kodujących (Claude, Codex) nadają się do zadań osobistych, ale są wolne, kosztowne tokenowo i licencyjnie zabronione w produkcji.
- Autor rekomenduje Pydantic AI jako framework do agentów produkcyjnych.
- Baza danych zastępuje markdown; potrzebne są dwie rzeczy: retriever kontekstu (dostęp do danych biznesowych) i pamięć agenta (krótko- i długoterminowa).
- Demonstracja opiera się na Redis i nowej usłudze Redis Iris (w wersji preview), sponsorowanej — ale idee są przenośne na dowolną infrastrukturę.
- Retriever kontekstu nakłada strukturę (encje, schemat, relacje) na nieustrukturyzowane pary klucz-wartość i auto-generuje narzędzia MCP do filtrowania i wyszukiwania.
- Pamięć agenta przechowuje pamięć sesyjną, a proces w tle wypromowuje najważniejsze informacje do pamięci długoterminowej (wektory, wyszukiwanie semantyczne).
- Cała odpowiedź w demo powstała bez czytania dokumentów markdown i przy zużyciu poniżej tysiąca tokenów.
Redakcyjne tłumaczenie
Dwa rodzaje agentów AI
Na świecie istnieją dwa bardzo różne rodzaje agentów AI i w tej chwili wygląda na to, że wszyscy skupiają się wyłącznie na jednym z nich — na agentach osobistych. Zwykle masz agenta kodującego, takiego jak Claude Code, Hermes czy Open Claw, działającego na twojej maszynie i pomagającego zarządzać zbiorem powiązanych ze sobą dokumentów markdown, które tworzą twoją bazę wiedzy. Najczęściej będzie to coś w rodzaju „LLM Wiki” w stylu Karpathy’ego dla twojej organizacji — dokumenty indeksowe z tagowaniem, kategoryzacją i wszystkimi encjami, które budujesz z czasem wspólnie z agentem.
(Informacja dodatkowa: „LLM Wiki” w stylu Andreja Karpathy’ego to popularne podejście, w którym bazę wiedzy dla modelu buduje się jako zbiór połączonych plików markdown z indeksami i tagami, zamiast bazy danych.)
Nie zrozumcie mnie źle — agenty osobiste są niezwykle potężne. To, co widzicie, to mój własny; korzystam z niego codziennie. Ale jest granica, której trzeba być świadomym: agenty osobiste się nie skalują. Ta granica pojawia się w momencie, gdy chcesz udostępnić agenta innym ludziom. Wtedy lokalny układ z „LLM Wiki” i agentem działającym na twojej maszynie przestaje wystarczać — musi wyglądać zupełnie inaczej. I na tym chcę się skupić w tym filmie, bo sam nagrałem sporo materiałów o agentach osobistych i czuję, że za mało uwagi poświęcam drugiej stronie medalu.
Dlaczego agenty osobiste budujemy na markdownie
Wszystko w agencie osobistym jest napędzane markdownem. Nie ma znaczenia, czy budujesz coś dla siebie, czy używasz gotowego rozwiązania jak Hermes — zawsze jest to markdown. Powód jest prosty: dla agenta osobistego to najprostsze i najbardziej elastyczne podejście. Niezwykle łatwo budować bazę wiedzy z czasem, w miarę jak rozmawiasz ze swoją „drugą mózgiem” i dorzucasz kolejne informacje. Siła tkwi w tym, że wszystko trzymasz na własnym systemie, więc jest maksymalnie dostępne i szybkie. Na tym etapie nie zależy nam specjalnie na zarządzaniu (governance), kontroli dostępu ani na śledzeniu i audytowalności, które są niezbędne w systemach produkcyjnych. Chodzi o to, by było jak najprościej.
Ale gdy tylko agenta zaczynają używać inni ludzie — wielu użytkowników naraz, masz dane na żywo, musisz dbać o kontrolę dostępu i wyszukiwanie na dużą skalę — to podejście przestaje się sprawdzać. Po pierwsze, nie bez powodu istnieją bazy danych. Jeśli zarządzasz wszystkim wyłącznie dokumentami markdown, twoja organizacja i wyszukiwanie — samo tworzenie i utrzymanie wszystkich plików — nigdy się nie przeskaluje.
Po drugie, „druga mózg” bywa całkiem droga. Zwykle korzystasz z SDK agenta kodującego, jak Claude czy Codex, w ramach swojej subskrypcji. Kiedy przechodzisz do produkcji, tej subskrypcji już użyć nie możesz, bo jest przeznaczona wyłącznie do użytku osobistego. A wszystkie prompty systemowe, narzędzia i wszystko, co wrzucasz do swojej „drugiej mózgu”, każąc jej czytać całe dokumenty markdown — nieważne, jak bardzo to zoptymalizujesz, nigdy nie sprosta skali retrievalu i optymalizacji kosztów wymaganej w produkcji.
Architektura agenta produkcyjnego
I tu dochodzimy do naszej architektury. Jak wygląda wdrożenie agenta dla innych? Nadal chcemy tych samych korzyści co w „drugiej mózgu” — pamięci użytkownika i możliwości organizowania informacji tak, by agent dobrze je odzyskiwał — ale wszystko musi wyglądać inaczej.
Chcę też podkreślić: ten układ jest znacznie powszechniejszy niż agenty osobiste. Ludzie są tak zafiksowani na agentach osobistych z dobrego powodu — są uniwersalne. Niezależnie od tego, czym się zajmujesz, „druga mózg” pomoże ci ogarnąć pracę lub życie prywatne. Ale prawda jest taka, że niemal wszystko, co daje realną wartość biznesową, to agent wdrożony jako część platformy w środowisku produkcyjnym, do którego logują się inni ludzie i z którym rozmawiają. I to jest architektura, o której teraz mówimy.
Tutaj używamy bazy danych, żeby skalować. Markdown już nie wystarcza — nie możemy mieć wiki Hermesa czy Claude Code dla agentów produkcyjnych. Baza musi przechowywać i obsługiwać dla nas dwie rzeczy, dając do nich dostęp agentowi: retriever kontekstu i pamięć agenta. To na nich skupię się w reszcie filmu.
W tym materiale użyję Redisa jako platformy napędzającej całość, ale te idee pasują do dowolnego systemu, który stworzysz dla agenta produkcyjnego. Zasadniczo mamy tu nakładkę na naszą bazę danych — warstwę kontekstu dla agenta. Retriever kontekstu daje agentowi dostęp do danych biznesowych, podpowiadając mu ich format i to, co może odpytywać. Pamięć agenta to pamięć krótko- i długoterminowa dla naszych klientów — z czasem budujemy inteligencję o użytkownikach.
(Informacja dodatkowa: film jest realizowany we współpracy z Redisem. Autor otwarcie to zaznacza. Redis Iris to zapowiedziana przez Redis warstwa dla agentów — w chwili nagrania w wersji preview — obejmująca właśnie retriever kontekstu i pamięć agenta.)
Powiem to wprost: pracuję nad tym filmem z Redisem. Zgłosili się do mnie, a ja od dawna szukałem platformy bazodanowej jako przykładu do dokładnie tego materiału. Jestem szczerze pod wrażeniem tego, co wypuścili — retrievera kontekstu i pamięci agenta. Ale znów: te idee możesz przenieść na dowolny system produkcyjny.
Dane biznesowe i retriever kontekstu
Wracając do bazy danych: to magazyn klucz-wartość z zestawem przykładowych danych sklepu e-commerce. Wybrałem taki przykład, bo każdy sklep internetowy powinien mieć agenta do analityki oraz agenta obsługującego klientów. Mamy więc informacje o klientach — po prostu pary klucz-wartość, elastyczne i nieustrukturyzowane w Redisie (dane są oczywiście fikcyjne) — a dalej zamówienia, produkty i przesyłki. To wszystko dane, które agent ma przeszukiwać, by pomagać użytkownikom sprawdzać status zamówień albo wykonywać analitykę dla zespołu wewnętrznego.
Na tym zbudowałem agenta w Pydantic AI (repozytorium podlinkuję w opisie). Nadal uwielbiam Pydantic AI do wszystkich agentów produkcyjnych, bo SDK agentów kodujących — jak Claude Agent SDK czy Codex SDK — choć są teraz bardzo popularne, są wolne, bo stworzono je do dłuższych zadań agentycznego kodowania, i są bardziej tokenożerne. Do czegokolwiek, co wdrażasz na produkcję, wciąż polecam Pydantic AI.
(Informacja dodatkowa: Pydantic AI to framework do budowy agentów LLM w Pythonie, oparty na bibliotece Pydantic. Nastawiony na lekkie, produkcyjne aplikacje, w odróżnieniu od SDK zaprojektowanych do wielokrotnych, długich pętli kodowania.)
Ten agent w Pydantic AI ma dostęp do MCP retrievera kontekstu oraz narzędzi do pamięci agenta — wszystko w tej samej bazie Redis, obsługiwane przez Redis Iris.
(Informacja dodatkowa: MCP — Model Context Protocol — to standard łączenia agentów LLM z zewnętrznymi narzędziami i źródłami danych przez serwer udostępniający zestaw narzędzi.)
Demo: jedno zapytanie, wiele źródeł
Pokażę, jak retriever kontekstu i pamięć agenta współpracują. To demo jest celowo uproszczone — nie ma interfejsu ani uwierzytelniania, więc muszę sam podać, kim jestem. W realnym wdrożeniu zbudujesz to we frontendzie z uwierzytelnianiem, więc agent będzie wiedział, kim jesteś, bez pytania. Tu mówię: jestem Jordan Rivera, klient 1004. „Dlaczego moje zamówienie się spóźnia i czy możesz to załatwić tak, jak prosiłem ostatnim razem?”.
To dość obciążające zapytanie: wymaga sięgnięcia do pamięci, żeby zrozumieć, co mamy na myśli, oraz przeszukania danych biznesowych — konkretnie zamówień tego klienta. I proszę — dostajemy odpowiedź. W zbudowanym przez siebie narzędziu CLI wypisuję też wszystkie pojedyncze narzędzia, które agent wywołał. Najpierw przeszukał pamięci, żeby znaleźć moje preferencje dotyczące obsługi zamówień, potem pobrał informacje o kliencie, znalazł zamówienia i na ich podstawie sięgnął po przesyłkę. Widać, jak agent przechodzi przez relacje w Redisie — a bez retrievera kontekstu byłoby to bardzo trudne, bo nie ma schematu; wszystko to tylko pary klucz-wartość.
To właśnie jedna z kluczowych rzeczy, które retriever kontekstu dodaje nad Redisem: strukturę. To trochę jak metadane w „LLM Wiki” Karpathy’ego — mówimy agentowi, jakimi sposobami może przeszukiwać i filtrować dane, by robił to wydajniej. W odpowiedzi widzimy informacje o opóźnionych zamówieniach oraz notatkę: klient preferuje ponowne wysyłki zamiast zwrotów. To konkretnie pamięć wyodrębniona z wcześniejszej interakcji z fikcyjnym Jordanem Riverą. Robi wrażenie, jak szybko agent zebrał tyle kontekstu, by dać kompletną odpowiedź — i to bez wydawania dziesiątek tysięcy tokenów. Chyba nawet nie wydał tysiąca.
Jak działa retriever kontekstu
Mam też diagram w Excalidraw, żeby to rozłożyć na czynniki pierwsze. Retriever kontekstu dotyczy danych biznesowych — klientów czy zamówień. Zaczynamy od bazy Redis, gdzie wszystko jest nieustrukturyzowane. Agent nie ma jak wiedzieć, jakie informacje w ogóle może przeszukać, a tym bardziej jak zrobić to wydajnie. Retriever kontekstu pomaga w obu tych rzeczach.
Kiedy konfigurujesz usługę retrievera, dokumentuje ona i ustala strukturę dla agenta, a nawet tworzy serwer MCP — auto-generuje narzędzia. Buduje „inteligencję” o twoich danych, a potem przekłada ją na narzędzia do filtrowania i wyszukiwania tekstowego, na wszystkie operacje potrzebne agentowi do przeszukiwania bazy na dużą skalę. Nieważne, ile mamy rekordów — agent przesieje wszystko, bo narzędzia pozwalają mu szukać po użytkowniku, filtrować po statusie zamówienia i tak dalej.
W panelu Redisa mam gotową usługę retrievera dla „North Peak Support”. Wystawia ona endpoint MCP. Przy konfiguracji definiujesz encje — kolejne nawiązanie do „LLM Wiki” Karpathy’ego. Dajemy agentowi strukturę, wskazując kluczowe encje, na których będzie operował przy przeszukiwaniu danych. Mapuje się to niemal jeden do jednego na tabele w bazie Redis. Mamy encję klienta, encję produktu — i zaczynamy określać schemat: typy, relacje między obiektami, tak jak zrobiłbyś to w grafie wiedzy w agencie osobistym.
Gdy encje są zdefiniowane, następuje właśnie ta „inteligentna” część: platforma automatycznie generuje wszystkie narzędzia MCP na podstawie sposobów dostępu do danych — filtrowanie klienta po mieście, po e-mailu, w praktyce narzędzie dla każdego atrybutu. Dla typów tekstowych mamy pełne wyszukiwanie — możliwość znalezienia słów kluczowych w kliencie czy opisie produktu. To moja ulubiona część całej platformy: te auto-generowane narzędzia.
W CLI wpisuję /tools i widzę wszystkie narzędzia automatycznie załadowane do serwera MCP podpiętego pod mojego agenta w Pydantic AI. Podpięcie serwera MCP jest bardzo proste — jak każdego innego. Po prostu dałem dokumentację mojemu Claude Code i kazałem mu połączyć i uwierzytelnić MCP retrievera kontekstu, a on załatwił to za jednym razem.
Przykład analityczny: „Pokaż mi każde opóźnione zamówienie z jego produktem i sumą”. Tego typu pytania nie chciałbyś udostępniać każdemu użytkownikowi (nie powinien przeszukiwać danych innych), ale wyobraź sobie agenta dla twojego zespołu e-commerce. I proszę — oto pięć opóźnionych zamówień w systemie. Zamiast czytać dokument indeksowy, przeszukiwać kolejne pliki markdown albo rozgryzać schemat bazy, agent wykonał pojedyncze wywołanie narzędzia MCP, filtrując zamówienia po statusie.
Kolejny przykład: „Czy mamy jakieś zgłoszenia wsparcia wspominające o zwrocie?”. Tu potrzebne jest wyszukiwanie tekstowe. Znów pojedyncze wywołanie MCP — zapytanie o „refund” — i mamy pięć zgłoszeń. Szybko i wydajnie. W skrócie: czegokolwiek agent potrzebuje z bazy, jest na to narzędzie MCP. A jeśli okaże się, że jakiegoś narzędzia brakuje, po prostu dopracowujesz encje i typy, żeby to narzędzie zostało udostępnione agentowi.
Pamięć agenta: krótko- i długoterminowa
Teraz pamięć agenta — krótko- i długoterminowa dla wszystkich interakcji. Mój ulubiony element: przechowujemy pamięć krótkoterminową każdej rozmowy, ale Redis Iris przez pamięć agenta automatycznie uruchamia proces w tle, który wyodrębnia z niej kluczowe informacje i promuje je do pamięci długoterminowej.
To też powszechna technika w agentach osobistych i „drugich mózgach”. Pracujesz ze swoją „drugą mózgiem”, tworząc plany czy prowadząc badania, i wyodrębniasz kluczowe wnioski oraz rzeczy, które każesz jej zapamiętać, do wypromowanej pamięci — jak plik memory.md, zawsze podawany agentowi. Tutaj idea jest podobna: wyciągamy „złote samorodki” z rozmów, zapisujemy je w Redisie, a agent może je później przywołać.
Używamy tu wektorów — klasyczny RAG z wyszukiwaniem semantycznym. Dzięki temu skalujemy się tak, że każdy użytkownik może mieć miliony wspomnień, a my i tak wyciągniemy te najważniejsze na następną rozmowę.
(Informacja dodatkowa: RAG — Retrieval-Augmented Generation — to technika, w której model przed wygenerowaniem odpowiedzi pobiera pasujące fragmenty z zewnętrznej bazy; wyszukiwanie semantyczne dopasowuje treści po znaczeniu, a nie po dokładnych słowach.)
W panelu pamięć agenta działa jak retriever kontekstu — tworzysz usługę. Tyle że to nie serwer MCP, lecz zwykły endpoint API. Mamy endpoint i klucz API, a narzędzia do dostępu i budowania wspomnień wbudowałem w agenta Pydantic AI za pomocą Claude Code. Wszystko jest zarządzane w naszej bazie, tak jak dane biznesowe. Mamy folder pamięci z parami klucz-wartość: pamięć sesyjną (krótkoterminową), a proces w tle automatycznie promuje ważne rzeczy do pamięci długoterminowej. Jest wektor, którego agent używa do wyszukiwania (nieprzeznaczony do czytania przez człowieka), oraz tekst. I spójrzcie: „Użytkownik preferuje ponowne wysyłki zamiast zwrotów przy opóźnionych zamówieniach”. To ta rozmowa, którą pokazywałem wcześniej — teraz agent będzie o tym pamiętał.
Wracam do CLI, zakładam nową sesję komendą /new session i mówię: „Cześć, jestem Jordan i za każdym razem, gdy moje zamówienie się spóźnia, zawsze wysyłaj je ponownie ekspresowo, zamiast zwracać pieniądze”. Zwykle użytkownik nie jest aż tak wprost — robię to na potrzeby demo. Redis Iris i tak wyodrębni kluczowe wspomnienia, nawet jeśli nie mówisz tak dosłownie.
Otwieram zupełnie nową rozmowę — żeby udowodnić, że nie prowadzi jej pamięć krótkoterminowa — i pytam o swoje preferencje. Agent szybko pobiera wspomnienia: podsumowanie tego, co wie z wcześniejszych rozmów — tożsamość (która w produkcji powinna pochodzić z uwierzytelniania), przeszłe zamówienia, zgłoszenia wsparcia i preferencje. „Zdecydowanie preferujesz ponowne wysyłki zamiast zwrotów”. To ten złoty samorodek.
Najlepsze w Redis Iris jest to, że jeśli nie użyjesz tej platformy — oczywiście idee nadal obowiązują dla własnej infrastruktury — to musisz sam utrzymywać proces wyodrębniania wspomnień, budować narzędzia do wyszukiwania i tak dalej. Tutaj cała warstwa zarządzania pamięcią jest obsłużona za ciebie, a mimo to masz pełną kontrolę i wgląd, bo wszystko leży w twojej bazie Redis. Możesz też usuwać wspomnienia.
Podsumowanie
To wszystko, co trzeba wiedzieć o architekturze agentów produkcyjnych. Redis Iris to znakomita platforma — daje najlepszy obraz tego, jak zbudować warstwę nad bazą danych, która daje agentowi dostęp i strukturę, jednocześnie zachowując elastyczność danych bazowych.
I pamiętaj: dla agentów osobistych tego nie potrzebujesz. „LLM Wiki” — czy to z Hermesem, Claude Code, czy z Obsidianem — jest wręcz idealne, by trzymać rzeczy prosto i elastycznie. Ale gdy tylko wchodzisz na produkcję, gdy tylko zaczynają korzystać z twojego agenta inni ludzie, to jest właśnie to, czego potrzebujesz. Będę nadal tworzył treści o obu tych ścieżkach — obie są bardzo ważne.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Rozróżnij agenta osobistego od produkcyjnego, zanim wybierzesz architekturę
Na czym polega: To dwa różne problemy inżynierskie. Agent osobisty służy jednej osobie i optymalizuje prostotę oraz elastyczność; agent produkcyjny obsługuje wielu użytkowników i musi zapewnić kontrolę dostępu, skalę i optymalizację kosztów.
Jak stosować: Na starcie projektu odpowiedz na jedno pytanie: czy z tego agenta będą korzystać inni ludzie przez platformę? Jeśli tak, od razu projektuj pod bazę danych, uwierzytelnianie i audytowalność.
Na co uważać: Nie przenoś nawyków z agenta osobistego do produkcji „bo działało u mnie”. Setup markdownowy nie ma kontroli dostępu ani śledzenia, których produkcja bezwzględnie wymaga.
2.Markdown/„LLM Wiki” jest świetny — ale tylko lokalnie
Na czym polega: Baza wiedzy oparta na plikach markdown (styl Karpathy’ego) jest idealna dla drugiej mózgu, bo łatwo ją rozbudowywać w rozmowie. Nie skaluje się jednak na organizację i wyszukiwanie przy dużej liczbie rekordów i użytkowników.
Jak stosować: Trzymaj markdown dla swojej prywatnej wiedzy i notatek (Obsidian, Hermes, Claude Code). Do wielu użytkowników i danych na żywo przejdź na bazę danych.
Na co uważać: Samo utrzymanie plików (tworzenie, indeksowanie, tagowanie) staje się wąskim gardłem, zanim jeszcze uderzysz w limity wyszukiwania.
3.Nie wdrażaj na produkcję agenta na subskrypcyjnym SDK kodującym
Na czym polega: Subskrypcje Claude Code czy Codex są licencjonowane do użytku osobistego, a same SDK agentów kodujących są wolne i tokenożerne, bo zaprojektowano je do długich zadań kodowania.
Jak stosować: Do produkcji wybierz lżejszy framework agentowy (autor rekomenduje Pydantic AI) i płatny dostęp API rozliczany pod obciążenie produkcyjne.
Na co uważać: Sprawdź warunki licencji swojej subskrypcji — użycie „osobistej” subskrypcji w produkcie dla klientów może łamać regulamin. Osobno policz koszt tokenów przy skali.
4.Zastąp pliki bazą danych z warstwą kontekstu
Na czym polega: W produkcji baza danych przechowuje dane, a nad nią budujesz „warstwę kontekstu” (nakładkę) z dwoma funkcjami: retriever kontekstu (dane biznesowe) i pamięć agenta.
Jak stosować: Zaprojektuj tę warstwę jako osobny komponent między agentem a bazą — niezależnie od tego, czy użyjesz Redisa, czy innego magazynu. To ona nadaje strukturę i udostępnia narzędzia.
Na co uważać: Redis Iris z filmu jest w wersji preview i sponsorowany — traktuj go jako ilustrację wzorca, nie jako jedyną słuszną implementację. Wzorzec przenieś na swój stos.
5.Nadaj nieustrukturyzowanym danym schemat przez definicję encji
Na czym polega: Agent nad surowym magazynem klucz-wartość nie wie, co i jak może przeszukać. Definiując encje (klient, produkt, zamówienie), ich typy i relacje, dajesz mu strukturę — odpowiednik metadanych w „LLM Wiki”.
Jak stosować: Zmapuj encje mniej więcej jeden do jednego na tabele/kolekcje. Określ typy pól i powiązania, żeby agent mógł przechodzić po relacjach (np. klient → zamówienia → przesyłka).
Na co uważać: Braki w definicji encji przekładają się bezpośrednio na brakujące narzędzia i ślepe punkty agenta. Traktuj schemat jak kontrakt, który trzeba utrzymywać.
6.Auto-generuj narzędzia MCP zamiast pisać je ręcznie
Na czym polega: Z dobrze zdefiniowanych encji można automatycznie wygenerować narzędzia MCP: filtrowanie po każdym atrybucie oraz pełne wyszukiwanie tekstowe dla pól tekstowych. Agent dostaje wtedy jedno wywołanie zamiast czytania wielu dokumentów.
Jak stosować: Oprzyj dostęp do danych o zestaw wąskich narzędzi (filtruj po statusie, po użytkowniku, szukaj po słowie kluczowym). Jeśli brakuje jakiegoś narzędzia, popraw encje/typy, żeby je wystawić.
Na co uważać: Jedno celne wywołanie narzędzia jest o rzędy wielkości tańsze niż wczytywanie całych dokumentów — w demo cała odpowiedź kosztowała poniżej tysiąca tokenów. Pilnuj, by narzędzia były wąskie i wydajne.
7.Rozdziel pamięć krótko- i długoterminową i promuj to, co ważne
Na czym polega: Pamięć sesyjna (krótkoterminowa) zapisuje przebieg rozmowy, a proces w tle wyodrębnia z niej kluczowe fakty i promuje je do pamięci długoterminowej — analogicznie do pliku memory.md w drugiej mózgu.
Jak stosować: Zbuduj proces ekstrakcji „złotych samorodków” (preferencje, decyzje, fakty o użytkowniku) i zapisuj je trwale, by agent działał lepiej w kolejnych rozmowach.
Na co uważać: Jeśli nie użyjesz gotowej platformy, musisz sam utrzymywać proces ekstrakcji i tooling wyszukiwania — to realny nakład. Zadbaj też o możliwość przeglądania i usuwania wspomnień.
8.Pamięć długoterminową buduj na wektorach i wyszukiwaniu semantycznym
Na czym polega: Długoterminowe wspomnienia zapisuje się jako wektory (klasyczny RAG), co pozwala odzyskiwać najistotniejsze fakty nawet przy milionach wspomnień na użytkownika.
Jak stosować: Przechowuj obok siebie reprezentację wektorową (do wyszukiwania) i tekst czytelny dla człowieka (do wglądu i weryfikacji). Odpytuj semantycznie pod kątem następnej rozmowy.
Na co uważać: Wektor nie jest dla ludzi — utrzymuj równoległy tekst, żeby móc audytować i debugować, co agent „pamięta”. Zapewnij izolację wspomnień per użytkownik.
9.Egzekwuj kontrolę dostępu i uwierzytelnianie od pierwszego dnia
Na czym polega: W demo autor podaje tożsamość ręcznie i nie ma uwierzytelniania, ale zaznacza, że w produkcji tożsamość musi pochodzić z logowania, a niektóre zapytania (np. analityka po wszystkich zamówieniach) nie mogą być dostępne dla zwykłych klientów.
Jak stosować: Powiąż tożsamość agenta z uwierzytelnionym użytkownikiem frontendu i ogranicz zakres narzędzi/danych zależnie od roli (klient vs. zespół wewnętrzny).
Na co uważać: Bez kontroli dostępu narzędzie „pokaż wszystkie zamówienia” pozwoli jednemu klientowi zobaczyć dane innych. Rozdziel agenta obsługi klienta od agenta analitycznego.
10.Zachowaj kontrolę i wgląd — trzymaj dane u siebie
Na czym polega: Zaletą trzymania wszystkiego w jednej bazie (tu: Redis) jest pełna widoczność i kontrola nad danymi biznesowymi oraz wspomnieniami, nawet gdy warstwa zarządzania jest zautomatyzowana.
Jak stosować: Wybieraj rozwiązania, w których dane bazowe pozostają w twojej infrastrukturze, a warstwa kontekstu/pamięci jest przejrzysta (możesz przeglądać, edytować, usuwać).
Na co uważać: „Zarządzane za ciebie” nie może oznaczać „nieprzejrzyste”. Zanim zaufasz platformie, upewnij się, że masz realny wgląd i możliwość ingerencji w przechowywane dane i pamięć.