Czy wiesz, że agenty SI śnią? Jak działa dreaming i jak nauczyć tej funkcji Twojego agenta

Jest trzecia w nocy. Ludzie śpią, biuro ciemne, a w infrastrukturze firmy budzi się proces, który powoli przegląda wszystko, co agenty SI zrobiły w ciągu dnia, wszystkie transkrypty rozmów, nieudane wywołania narzędzi, powtórzone błędy, strategie, które zadziałały. Rano agenty wstają mądrzejsze, choć żaden z nich nie przepracował ani chwili więcej. Branża nazwała ten proces snem. I pierwszy raz od dawna nazwa marketingowa naprawdę dobrze opisuje mechanizm.

W tym wpisie rozbieramy dreaming na części: skąd się wziął, jak działa technicznie, co pokazują pierwsze wdrożenia i, co najważniejsze, jak nauczyć tej funkcji Twojego własnego agenta. Z gotowym promptem do wklejenia, bo u nas ten mechanizm pracuje co noc.

Skąd w ogóle sen u agenta, czyli problem wiecznej amnezji

Agenty potrafią dziś pracować godzinami, czasem prawie dobami. Dostały wiele elementów usprawniających ich pracę: protokoły z dostępem do narzędzi i danych firmowych, potem skille, czyli paczki wiedzy proceduralnej, które agent może podnieść z półki i użyć. Każdy klocek wydłużał smycz, na której agent może samodzielnie biegać.

Ale jeden problem pozostawał nierozwiązany: ciągłe samouczenie się. Agent kończył zadanie, sesja się zamykała i cała wiedza zdobyta w bólach szła do kosza. Następnego dnia ten sam agent popełniał te same błędy, odkrywał te same obejścia i płacił tokenami za te same śledztwa. Wieczna amnezja jako model biznesowy... dla dostawcy tokenów całkiem niezły, dla Ciebie już mniej.

Odpowiedzią jest pamięć jako osobny, pełnoprawny element systemu. I tu robi się ciekawie, bo okazało się, że najlepsza architektura pamięci dla agenta wygląda zaskakująco znajomo.

Pamięć agenta to... katalog z plikami

Nowoczesne systemy pamięci agentowej nie trzymają wspomnień w tajemniczej sieci neuronowej czy skomplikowanej bazie danych. Trzymają je w czymś, co każdy zna od dziecka, czyli w systemie plików. Pamięć to po prostu hierarchia plików tekstowych, którą agent sam zakłada, organizuje i aktualizuje, używając najzwyklejszych narzędzi terminalowych w rodzaju basha i grepa, czyli komend leżących u podstaw każdego systemu operacyjnego, na które nakładane są później interfejsy graficzne.

To nie jest pójście na łatwiznę, to świadoma decyzja projektowa, bo zamiast wymyślać sztywne API pamięci z wyspecyfikowanymi polami, pozwolono modelowi zarządzać notatkami tak, jak zarządza kodem, czyli popłynąć z nurtem. Najnowsze modele są w tym już naprawdę dobre: same decydują, co w ogóle warto zapamiętać, na ile plików podzielić wiedzę i jak utrzymać w tym porządek. Pamięć przestała być bazą danych, a stała się biblioteczką, którą agent sam kataloguje.

My prowadzimy pamięć naszych agentów dokładnie tak samo, mamy katalog plików markdown, jeden fakt na plik, plus plik indeksowy, który działa jak spis treści wczytywany na start każdej sesji. Proste, przeszukiwalne, a co najważniejsze: człowiek może to otworzyć i przeczytać bez dekodera.

Pamięć dla roju, czyli niekończące się przygody z uprawnieniami, kolizjami i audytami

Prawdziwa zabawa zaczyna się, gdy agentów jest wielu. W dużych firmach pracują już setki, czasem tysiące agentów równolegle, bardzo często na wspólnym stanie. I tu z pomysłu "pamięć to pliki" wynikają trzy rzeczy, które warto znać, nawet jeśli wdrażasz jednego skromnego agenta:

Zakresy uprawnień. Agent może mieć kilka magazynów pamięci naraz, np. pierwszy tylko do odczytu (wiedza organizacji: procedury, dobre praktyki, do kogo dzwonić, gdy się pali) i drugi do zapisu (pamięć robocza, często aktualizowana w trakcie pracy). Wiedza firmowa jest chroniona przed nadgorliwym agentem, który chciałby ją "poprawić" o trzeciej nad ranem, a pozostałe są otwarte na działania.

Optymistyczna kontrola współbieżności. Gdy stu agentów pisze do tej samej pamięci, któryś w końcu nadpisze pracę kolegi. Rozwiązaniem jest to, że agent przed zapisem sprawdza skrót zawartości (hash) i upewnia się, że nikt w międzyczasie nie zmienił pliku. Mechanizm stary jak bazy danych, ale kluczowy, żeby rój nie zadeptywał własnych śladów.

Historia wersji z atrybucją. Każda zmiana pamięci ma dziennik, w którym gromadzi informacje, który agent, o której godzinie, w której sesji, co dokładnie zmienił. Pełny diff, jak w systemie kontroli wersji. To jest ta cecha, o którą firmy dopominały się najgłośniej, i słusznie: pamięć bez audytu to plotka, pamięć z audytem to dokumentacja.

Czym właściwie jest dreaming

No dobrze, mamy pamięć jako pliki i agentów, którzy do niej piszą. Skąd jeszcze sen? Stąd, że pojedynczy agent pisząc notatki widzi tylko własny kontekst i własne zadanie. Jest jak pracownik, który prowadzi swój notesik: pożyteczne, ale nikt nie czyta wszystkich notesików naraz. W efekcie sesje przegapiały wnioski, które inne sesje już dawno wypracowały, a wspólne wzorce błędów pozostawały niewidoczne.

Dreaming to funkcja, którą Anthropic wypuścił właśnie jako research preview. To proces działający poza pasmem, obok normalnej pracy agentów. Uruchamiasz go harmonogramem, na przykład co noc, albo zdarzeniem, na przykład gdy agent kończy zadanie i zwija obóz. Proces bierze na warsztat transkrypty ostatnich sesji plus aktualny stan pamięci i robi cztery rzeczy:

• szuka wzorców w wielu sesjach naraz: powtarzających się błędów, nieudanych wywołań narzędzi, strategii, które konsekwentnie działają,
• porządkuje: scala duplikaty, usuwa nieaktualne wpisy, poprawia strukturę plików,
• weryfikuje: sprawdza istniejące wpisy pamięci z faktyczną pracą agentów i oznacza te potwierdzone,
• produkuje diff: paczkę proponowanych zmian, którą możesz zastosować automatycznie albo najpierw przejrzeć.

I tu od razu kubeł zimnej wody: dreaming jest udostępniany w najwyższych abonamentach i nie u wszystkich dostawców, jest jeszcze na wczesnym etapie testów i dostosowany jest głównie do klientów enterprise i ich trybu pracy. Dobra wiadomość jest taka, że sam mechanizm nie jest magią, tylko dobrze poukładanym procesem, więc da się go odtworzyć u siebie znacznie mniejszym kosztem. Pokazujemy, jak to zrobić, w dalszej części wpisu, z promptem do skopiowania.

Zwróć uwagę na trzy projektowe smaczki. Po pierwsze, dreaming widzi to, czego nie widzi żaden pojedynczy agent, bo patrzy z góry na wiele sesji naraz. Po drugie, oddziela cel "jakość pamięci" od celu "wykonaj zadanie": agent w pracy ma się skupić na pracy, a nie rozpraszać sprzątaniem biblioteczki. Po trzecie, dzieje się w tle, więc nie dokłada ani milisekundy opóźnienia do właściwej pracy. Nocna zmiana w czystej postaci.

Nocna zmiana w akcji: przykład z formularza kontaktowego

Przejdźmy do sytuacji, którą zna każda firma mająca dosyć zaawansowany system formularzy. Klient wypełnia jeden z formularzy, a zgłoszenie przejmuje agent: to prosta automatyzacja procesu, w której agent czyta treść, kwalifikuje sprawę, zakłada wątek w skrzynce, odpisuje klientowi i podaje temat dalej do handlowca.

W poniedziałek rano wpada zgłoszenie z urwanymi polami: jest sama treść wiadomości, bez telefonu i bez nazwy firmy, choć formularz oznacza je jako wymagane. Pierwszy agent traci kilkanaście minut na sprawdzenie, czy to nie jego wina: przegląda ostatnie zgłoszenia, porównuje pola, w końcu odpisuje klientowi z prośbą o numer. Do pamięci zapisuje notatkę: zdarzają się zgłoszenia z urwanymi polami, nie kombinuj, po prostu dopytaj.

Po południu to samo powtarza się przy innym zgłoszeniu i budzi się drugi agent. Pierwsze, co robi, to czyta pamięć i znajduje gotową odpowiedź: to już było, nie szukaj błędu u siebie, od razu napisz do klienta. Kilkanaście minut w plecy zamienia się w kilkanaście sekund. Tyle daje sama pamięć.

Ale prawdziwa perła przychodzi w nocy. Dreaming przegląda cały tydzień i zauważa coś, czego nie zauważył żaden agent: każde urwane zgłoszenie miało załącznik cięższy niż dwa megabajty. Za każdym razem. Każdy agent widział tylko swoje jedno zgłoszenie, więc żaden nie mógł dostrzec wzorca. A wzorzec podpowiada konkretną hipotezę: gdzieś siedzi limit wysyłki, który ucina formularz w połowie. Klient widzi na stronie zielony komunikat "dziękujemy, wiadomość wysłana", a na skrzynkę firmy przychodzi kadłubek. I nagle to nie jest drobna niedogodność, tylko cicho przeciekające zapytania ofertowe, przy których nikomu nie zapaliła się żadna lampka.

Zauważ, co się właśnie zmieniło. Bez dreamingu firma dostaje trzy grzeczne maile do klientów i trzy notatki w stylu "dopytaj". Z dreamingiem dostaje jedno zdanie dla administratora: sprawdź limit wysyłki załączników w formularzu. Pierwsze to łatanie objawów, drugie to naprawa przyczyny.

Do tego dreaming dorzuca sprzątanie: pięć niemal identycznych notatek od różnych agentów scala w jedną, usuwa wpis, który według transkryptów już nie obowiązuje, a przy innym dopisuje notę weryfikacyjną: sprawdzone z dzisiejszą pracą agentów, wpis aktualny, można na nim polegać. Rano zespół agentów dostaje pamięć czystszą, bogatszą i zweryfikowaną.

Liczby robią wrażenie. Pytania jednak zadać trzeba

Pierwsze wdrożenia chwalą się mocnymi wynikami. Rakuten raportuje, że dzięki współdzielonej pamięci liczba błędów pierwszego podejścia w ich wewnętrznych agentach wiedzy spadła o 90%: agenty wyłapywały pomyłki i przekazywały je następnym iteracjom, co przy okazji obniżyło zużycie tokenów i opóźnienia. Harvey, firma od SI dla prawników, po włączeniu dreamingu zobaczyła sześciokrotny wzrost wskaźnika ukończenia zadań na swoim realistycznym benchmarku prawnym.

Sześć razy, drogi decydencie! I tu obowiązkowa łyżka dziegciu od wdrożeniowca: to są case studies z materiałów dostawcy, bez opublikowanej metodologii, poziomów bazowych i przedziałów ufności. Co nie znaczy, że nieprawdziwe: znaczy, że nieporównywalne. Najciekawsze jest zresztą to, skąd taka poprawa najpewniej się bierze. Nie z tego, że model "posiadł wiedzę przez sen", tylko z tego, że agenty przestały codziennie wdeptywać w te same kałuże: zapamiętały obejścia problemów z plikami, kolejność narzędzi, warunki sukcesu. Na slajdzie wygląda to skromniej niż "6x", ale to dokładnie te nudne rzeczy decydują, czy agent kończy zadanie.

Dwie analogie, które ustawiają myślenie

Warto zapamiętać dwa porównania, bo dobrze tłumaczą, czemu to podejście ma sens ekonomiczny.

Sen jako test-time compute dla pamięci. Kilka lat temu odkryliśmy, że pozwolenie modelowi myśleć dłużej, czyli wydać więcej tokenów na rozumowanie, daje lepsze wyniki. Dreaming to ta sama zasada zastosowana do pamięci: dodatkowa moc obliczeniowa wydana poza godzinami pracy na to, żeby wiedza była uporządkowana i świeża. Skalujesz jakość pamięci mocą obliczeniową, nie etatami.

Sen jako budowa indeksu wyszukiwarki. Wyszukiwarka nie przeszukuje internetu przy każdym Twoim zapytaniu: najpierw ponosi duży koszt zbudowania indeksu, a potem każde zapytanie jest tanie i szybkie. Dreaming robi z pamięcią to samo: kosztowną robotę porządkową wykonuje raz, w nocy, a korzystają z niej wszyscy agenci następnego dnia. Koszt się amortyzuje na cały rój.

Jak nauczyć dreamingu własnego agenta

I teraz najlepsze: skoro gotowa funkcja nie jest dostępna dla wszystkich, zbudujmy ją sami. Nie potrzebujesz do tego platformy klasy enterprise. My w MTZN prowadzimy nocną konsolidację pamięci od dawna, na zwykłych plikach markdown, i wystarczy do tego dobrze napisany prompt plus odrobina dyscypliny. Zasady projektowe, które się u nas sprawdziły:

1. Dreaming proponuje, człowiek zatwierdza. Nocny proces niczego sam nie kasuje i nie przepisuje. Produkuje ponumerowaną listę propozycji, a rano człowiek klika "zastosuj 1 i 3, odrzuć 2". To nasz odpowiednik trybu review z dużych platform.
2. Każda propozycja ma dowód. Nie ma cytatu z transkryptu, nie ma propozycji. To najskuteczniejszy bezpiecznik przed halucynacją, jaka mogłaby wjechać do pamięci na stałe.
3. Raport zawsze na dysk. Nocny przebieg zostawia raport w stałym miejscu, więc decyzję można podjąć także trzy dni później, a odrzucone propozycje nie wracają jak bumerang.

Poniżej prompt, który stanowi bazę: to na nim zbudowaliśmy własne, dedykowane rozwiązanie, zintegrowane z naszą strukturą danych i procesami. Sama baza jest samodzielna i możesz jej używać u siebie od zaraz: kopiujesz, wklejasz swojemu agentowi jako instrukcję nocnego przebiegu i tyle. Zakłada prostą strukturę pamięci: katalog z plikami .md (jeden fakt na plik) plus indeks, który agent wczytuje na start każdej sesji. Miejsca w klamrach, czyli katalog pamięci, plik indeksu i katalog transkryptów, podmień na własne ścieżki, zanim puścisz pierwszy przebieg.

# Dream: Memory Consolidation

You are performing a dream — a reflective pass over your memory files. Synthesize what you've learned recently into durable, well-organized memories so that future sessions can orient quickly.

Memory directory: `${MEMORY_DIR}`
${MEMORY_DIR_CONTEXT}

Session transcripts: `${TRANSCRIPTS_DIR}` (large JSONL files — grep narrowly, don't read whole files)
${HAS_TEAM_MEMORY?`
${TEAM_MEMORY_GUIDANCE_BLOCK}
`:""}
---

## Phase 1 — Orient

- `ls` the memory directory to see what already exists
- Read `${INDEX_FILE}` to understand the current index
- Skim existing topic files so you improve them rather than creating duplicates
- `ls -R logs/` — recent activity logs (one file per session under `YYYY/MM/DD/`). If a `sessions/` subdirectory also exists, review recent entries there too

## Phase 2 — Gather recent signal

Look for new information worth persisting. Sources in rough priority order:

1. **Session logs** (`logs/YYYY/MM/DD/<id>-<title>.md`) — the append-only activity stream, one file per session. Read the most recent 1–3 days of sessions (the filename title tells you what each was about); each line is prefix-coded (`>` user, `<` assistant, `.` tool call)
2. **Existing memories that drifted** — facts that contradict something you see in the codebase now
3. **Transcript search** — if you need specific context (e.g., "what was the error message from yesterday's build failure?"), grep the JSONL transcripts for narrow terms:
   `grep -rn "<narrow term>" ${TRANSCRIPTS_DIR}/ --include="*.jsonl" | tail -50`

Don't exhaustively read transcripts. Look only for things you already suspect matter.

## Phase 3 — Consolidate

For each thing worth remembering, write or update a memory file at the top level of the memory directory. Use the memory file format${IS_STONE_SHELL_MEMORY_VARIANT?"":" and type conventions"} from your system prompt's auto-memory section — it's the source of truth for what to save, how to structure it, and what NOT to save.

Focus on:
- Merging new signal into existing topic files rather than creating near-duplicates
- Converting relative dates ("yesterday", "last week") to absolute dates so they remain interpretable after time passes
- Deleting contradicted facts — if today's investigation disproves an old memory, fix it at the source

## Phase 4 — Prune and index

Update `${INDEX_FILE}` so it stays under ${INDEX_MAX_LINES} lines AND under ~25KB. It's an **index**, not a dump — each entry should be one line under ~150 characters: `- [Title](file.md) — one-line hook`. Never write memory content directly into it.

- Remove pointers to memories that are now stale, wrong, or superseded
- Demote verbose entries: if an index line is over ~200 chars, it's carrying content that belongs in the topic file — shorten the line, move the detail
- Add pointers to newly important memories
- Resolve contradictions — if two files disagree, fix the wrong one

${CLAUDE_MD_RECONCILIATION_BLOCK}

---

Return a brief summary of what you consolidated, updated, or pruned. If nothing changed (memories are already tight), say so.${ADDITIONAL_CONTEXT?`

## Additional context

${ADDITIONAL_CONTEXT}`:""}

Ten prompt to odpowiedź na to, co korporacje kupują w pakietach enterprise, a całość mieści się w czterech fazach. Najpierw rozeznanie, czyli przegląd tego, co już leży w pamięci, żeby poprawiać istniejące pliki zamiast mnożyć bliźniaki. Potem zbieranie świeżego sygnału: logi ostatnich sesji, wpisy, które rozjechały się z rzeczywistością, i wąskie wyszukiwania po transkryptach, bez czytania ich w całości. Potem konsolidacja, czyli dopisywanie do istniejących plików, zamiana dat względnych na konkretne i kasowanie faktów, które właśnie zostały obalone. Na koniec porządki w indeksie, żeby nie spuchł i pozostał spisem treści, a nie składem wiedzy. Skala mniejsza niż u dostawcy, zasada identyczna, a wejście kosztuje tyle, co skopiowanie tekstu. I tak jak w dużych systemach, prawdziwa wartość przychodzi po tygodniach: pamięć, w której wpisy mają konkretne daty i nie zalegają w niej rzeczy obalone wczoraj, starzeje się z godnością zamiast gnić.

Krótko o koszmarach

Dreaming ma też ciemną stronę i nie wolno jej przemilczeć. Jeśli do pamięci trafi fałszywy wniosek, następna sesja dostanie go jako fakt, użyje i wzmocni: w branży mówi się na to memory poisoning. Jeszcze gorzej, gdy złośliwa instrukcja ukryta w jakimś dokumencie zostanie uznana za cenną lekcję: taki atak nie kończy się z sesją, tylko zamieszkuje w pamięci na stałe, jak teściowa, która wpadła na chwilę. Dlatego wszystkie opisane wyżej bezpieczniki: dowody, wersjonowanie, diffy, zatwierdzanie przez człowieka, to nie biurokracja. To pasy bezpieczeństwa. Sen bez nadzoru to nie wizja, to lunatykowanie.

Zamiast kołysanki

Pamięć zmienia agenta z narzędzia w pracownika, który uczy się fachu. A dreaming zmienia stado takich pracowników w zespół, który uczy się razem: dzisiejsze błędy stają się jutrzejszymi skrótami, a wiedza przestaje umierać o północy wraz z sesją. To jest, naszym zdaniem, najciekawsza zmiana w budowaniu agentów od czasu narzędzi: nie kolejny większy model, tylko mądrzejszy sposób gospodarowania doświadczeniem.

Więc jeśli Twój agent codziennie rano budzi się jako niemowlę, wiesz już, czego mu brakuje. Wklej mu prompt, załóż katalog pamięci i daj mu się wyspać. A jeśli chcesz, żeby ktoś ułożył cały ten cykl z Tobą, od struktury pamięci po nocny harmonogram, wiesz gdzie nas znaleźć. Obiecujemy, że odbierze człowiek. Wyspany.

Prompt powyżej jest celowo prosty, żeby dało się go wkleić i zapomnieć. Ale dreaming da się rozkręcić znacznie dalej i tutaj robi się naprawdę ciekawie. Możemy wdrożyć u Ciebie kreatywne podejście do dreamingu: osobne, szczegółowe instrukcje dla różnych typów pamięci, bo inaczej porządkuje się fakty o projekcie, inaczej preferencje człowieka, a jeszcze inaczej procedury i obejścia. Możemy dołożyć rozbieganą fazę w stylu ADHD, która celowo szuka odległych skojarzeń między sesjami i wyławia rzeczy, na które uporządkowany proces nigdy by nie wpadł. Możemy wreszcie dorzucić mechanikę pomiaru: kilka wersji prompta dreamingu pracuje równolegle na tym samym materiale, a potem porównujemy wyniki i wiemy, która wersja faktycznie daje lepszą pamięć. Bo skoro dreaming ma poprawiać agenta, to wypadałoby wiedzieć, czy naprawdę go poprawia.