Створення пам’яті агента, яка зберігає інформацію протягом розмови без накопичення зайвих даних.

Сцена, яка повторюється майже з кожним агентом, що починає працювати, виглядає так.

У понеділок користувач каже, що керує Північно-Західним регіоном, цікавить лише активні проекти та не терпить довгих відповідей. Агент каже «Зрозуміло», і протягом усієї наступної сесії це означає саме це: відповіді короткі, стосуються лише Північно-Західного регіону та не містять чернеток. Користувач задоволений.

У вівторок та сама людина починає нову розмову та запитує, як просуваються її проекти. Агент весело запитує, про який регіон вона хоче дізнатися.

Вираз обличчя цього користувача — причина, чому варто серйозно замислитися над пам’яттю.

Чому зберігання всього провалюється

Майже кожен розробник вдається до одного й того ж рішення: зберегти всю розмову та завантажити її знову завтра. Це здається очевидним, але це пастка. Спосіб, у який це провалюється, навчає більшого про проектування агентів, ніж більшість посібників.

Припустимо, що вся історія спілкування зберігається та відтворюється щоразу, коли користувач повертається. Події відбуваються у передбачуваному порядку.

Перший тиждень: все працює. Агент справді пам’ятає все, і ви відчуваєте себе розумним. Це небезпечний етап, адже здається, що це підтверджує ефективність дизайну.

Третій тиждень: система стає повільною та дорогою у використанні. Кожен крок тепер вимагає обробки тисяч токенів старих розмов. Ви оплачуєте незначні розмови з понеділка, відповідаючи на запитання з п’ятниці. Вікно контексту — це робочий стіл агента, і ви вже засипали його минулотижневими документами ще до початку сьогоднішньої роботи.

На шостому тижні все йде не так. Ніхто не попереджає вас про цю стадію. Старі розмови містять твердження, які вже не є правдивими. Користувач зосереджувався на Північно-Заході, поки підвищення не поставило його на чоло всієї країни. Проект затримувався аж до моменту випуску. Перегляд усього змушує агента однаково оцінювати застарілі та актуальні факти. Проблема більше не в тому, що він пам’ятає занадто мало. Він пам’ятає занадто багато, не маючи уявлення про те, що вже застаріло.

Перегляд повної історії, по суті, є механізмом створення застарілого контексту. Тож питання „Як мені зберегти все?“ ніколи не було правильним. Правильні запитання такі:

Які речі варто зберігати, які слід отримувати за потреби, а які варто викинути та створити заново?

Якщо відповісти на них, то архітектура пам’яті буде визначена.

Трирівнева схема

Порівняйте це з тим, як ви обробляєте інформацію на роботі. Є речі, які ви зберігаєте у своїй пам’яті під час зустрічі та з радістю видаляєте пізніше. Є речі, які ви записуєте у зошит, тому що вони знадобляться наступного місяця. Є речі, які ви ніколи не запам’ятовуєте, оскільки вони змінюються та перевіряються щоразу. Агентам потрібні ті самі три рівні.

Рівень 1: пам’ять сесії, яка призначена для зникнення

Цей рівень містить усе, що пов’язано з поточною розмовою: історію повідомлень, результати проміжних інструментів, незавершене багатоетапне завдання та стан LangGraph, який переміщується між вузлами.

Коли сесія закінчується, цей рівень може зникнути. Це не означає втрати даних — це передбачено проектом, і це є перевагою.

Початківці відчувають провину з цього приводу, але в цьому немає потреби. Поетапний запис розмови схожий на зустріч: важливим є не текст запису, а висновки. Тож цікаве питання полягає у тому, що переходить до другого рівня після завершення сесії.

Не текст запису. Невеликий крок прямого вилучення виділяє три категорії:

1. Стабільні факти про користувача, такі як „керує Північно-Західним регіоном“, дійсні до скасування.
2. Переваги, такі як „бажає коротких відповідей“ та „виключити проекти у черзі“.
3. Рішення, такі як „погодився на формат щотижневого підсумку“.

Та розмова у понеділок може скласти чотири тисячі токенів. Те, що заслуговує на те, щоб залишитися після неї, — це приблизно сорок токенів структурованих фактів, що є компресією у приблизно сто разів. На відміну від резюме, ніщо важливе не стає нечітким, адже ви видобули названі категорії замість загального враження. Резюме тихо видаляють обмеження, а видобуток є рішенням: певна перевага або потрапляє до списку слово в слово, або ні, і для цього можна написати тест.

Рівень 2: довгострокова пам’ять, мала, структурована та змінна

Це компактний сховище, яке зберігається між сеансами — це щоденник користувача. Протистояйте бажанню бути кмітливим. Саме через нудний формат він і працює ефективно:

{
  "user_id": "u-2481",
  "facts": [
    {"fact": "manages Northwest region", "updated": "2026-08-03"},
    {"fact": "prefers concise answers", "updated": "2026-07-19"}
  ],
  "preferences": [
    {"pref": "exclude draft projects from reports", "updated": "2026-08-03"}
  ],
  "decisions": [
    {"decision": "weekly summary every Monday", "updated": "2026-07-28"}
  ]
}

Кілька десятків рядків JSON на користувача, які завантажуються в контекст на початку кожної сесії. Це достатньо дешево, щоб включати їх завжди, і достатньо незначно, щоб не спричиняти перевантаження.

Три правила допомагають підтримувати їх у належному стані.

Структурований формат кращий за прозу. Нечітка проза на кшталт „ця людина, ймовірно, керує Північним заходом та любить лаконічність“ згодом є марною. Натомість окремі факти можна показувати користувачеві, виправляти та видаляти поодинці.

Додавайте часові позначки до всього та замінюйте інформацію, а не додаєте її. Коли користувач переходить від регіону Північний захід до регіону Національний, не потрібно додавати ще один факт поруч із першим — його потрібно перезаписати. Як тільки в базі даних зберігаються одночасно дані про керування Північним заходом та Національним, це призводить до проблеми застарілої інформації, яка залишається такою назавжди.

Дозвольте користувачеві побачити це та виправити. Навіть простий запит на кшталт „Ось що я пам’ятаю про вас“ змінює ситуацію. Інформація, яку користувач не може перевірити, з часом стає інформацією, якій він не довіряє, зазвичай у ту мить, коли агент із повною впевненістю називає щось, що вже кілька місяців застаріло.

У рівень 2 не потрапляє ніщо, що можна знайти через пошук. Це належить до рівня 3, і команди часто витрачають там свої зусилля на неправильні речі.

Рівень 3: генерування за потребою, навмисне незберігання в пам’яті

Сюди належить усе, що змінюється самостійно: статуси проектів, цифри, дати, організаційні схеми, поточні показники, зміст баз даних та API.

Правило полягає у тому, що цей рівень ніколи не слід запам’ятовувати. Не узагальнюйте його, не зберігайте в пам’яті та не переносите з попередньої розмови. У момент необхідності агент викликає інструмент та отримує поточне значення.

Якщо записати це, здається очевидним. Це також найбільш проблематичне правило в пам’яті агента, оскільки зберігання актуальних даних у пам’яті здається оптимізацією. Насправді це часова бомба з повільним запалювачем:

• Зберігається інформація «Проект Falcon відкладено», а потім проект все одно випускається. Протягом тижнів агент продовжує говорити про проект, який вже було виконано.
• Зберігається інформація «У команді 8 учасників», а потім до неї приєднуються ще двоє людей. Кожна відповідь щодо потужності є некоректною.

Найкращим узагальненням всієї архітектури, мабуть, є це:

Використовуйте пам’ять для фактів про людину. Використовуйте інструменти для фактів про все інше.

Переваги користувачів змінюються рідко, і вони самі повідомляють про це. Світ змінюється постійно, але нічого вам не каже. Тож пам’ятайте про користувача та запитуйте світ.

Сценарій невдачі: „поділитися всім“ та багатоагентна система

Це упорядкована версія. Шлях до неї пролягав через інцидент у вигаданій двоагентній системі в компанії з послуги мереж.

Агент А спілкувався з користувачами та збирав вимоги до звітів. Агент Б готував ці звіти. Коли А передавав роботу Б, команда повторила початкову помилку у масштабах архітектури: вони передавали всі дані А — повну переписку, результати роботи всіх інструментів та весь стан системи. Логіка здавалася бездоганною. Хіба більше контексту не означає краще обізнаного Б?

Саме спосіб, яким це сталося, є корисною частиною. Під час однієї сесії користувач вголос замислився перед агентом А: а що, якщо включити архівовані проекти? Однак, подумавши ще раз, він вирішив, що це спотворить загальні показники, тож краще їх не включати. Це було зовсім звичайне вголос мислення, і агент А правильно з ним впорався.

Потім відбулася передача даних, і агент Б отримав усю транскрипцію, включаючи непрямо пов’язану інформацію. Але у агента Б не було жодного контексту розмови агента А, щоб оцінити цю інформацію. У наданих даних не було жодної згадки про те, що ідея з архівованими проектами була відхилена, і поза контекстом це виглядало як вказівка. Агент Б вірно включив архівовані проекти, і загальні показники в офіційному звіті виявилися неправильними — причину цього ніхто не міг знайти, переглядаючи код агента Б, адже його код був бездоганним.

Це багатоагентна версія всього вищесказаного: передача даних — це межа сеансу. Коли агент B починає виконувати свою роботу, це означає початок нового чату у вівторок. Команда припустилася тієї ж помилки з „збереженням усього“ між агентами, замість того щоб робити це протягом кількох днів.

Рішення було таким самим. Передача транскриптів замінилася структурованим пакетом даних для передачі, фактично це був тимчасовий об’єкт другого рівня, який агент A створює для агента B:

{
  "task": "generate weekly regional report",
  "requirements": [
    "region: Northwest",
    "active projects only",
    "exclude drafts AND archived"
  ],
  "format": "summary table first, details after",
  "constraints_confirmed_by_user": true
}

Це приблизно п’ятдесят токенів без жодної неоднозначності. B отримує висновки, а не складний шлях до них. Клас помилок archived-projects став неможливим для використання, а не просто виявленим чи обробленим, оскільки покинуті ідеї фізично не можуть вижити після того, як їх включають до списку вимог.

Візьміть одне речення у будь-якій моделі з кількома агентами: агенти повинні передавати один одному висновки, а не протоколи розмови.

Чек-лист для застосування цього тижня

П’ять рішень, які ви можете прийняти щодо існуючого агента:

1. Дозвольте пам’яті сеансу зникнути. Додайте крок вилучення наприкінці сеансу або після N ходів, який буде передавати лише факти, уподобання та рішення, а решту — разом із чатом — дозволить зникнути.
2. Зберігайте Tier 2 у вигляді простого JSON. Дискретні елементи, часові позначки, оновлення. Ніколи не дозволяйте утворюватися розрізненому текстовому блоку та не використовуйте режим додавання лише в кінець.

Надайте користувачам можливість отримати інформацію. Запит типу „Що ви пам’ятаєте про мене?“ навіть у примітивному вигляді сприяє побудові довіри та дозволяє безкоштовно виявити застарілі дані.

Перевіряйте рівень достовірності даних про світ. Усе, що інструмент може отримати у актуальному вигляді — таке як статуси, кількості, дати та числа — має бути використано. Пам’ять призначена для користувача, а інструменти — для отримання інформації про світ.

Передавайте висновки у структурованому вигляді. Використовуйте структурований пакет даних із описом завдання, вимог та обмежень. Якщо під час передачі використовується необроблений текст, це вже ознака вищезгаданої проблеми, про яку ви ще не усвідомлюєте.

Висновок

Думка про те, що пам’ять означає зберігання більшої кількості інформації, є абсолютно хибною. Кожна з вищезгаданих проблем — від спроб швидкого рішення проблеми з амнезією до застарілих даних та звітів про архівовані проекти — має своєю причиною надмірне та необережне зберігання інформації.

Ефективна пам’ять агента — це насамперед вміння забувати. Стан сесії може зникнути, довгострокові нотатки залишаються достатньо короткими, щоб їх можна було прочитати одним поглядом, а все нове, що може розповісти світ, не зберігається в пам’яті. Агенти, які створюють враження справді особистих, — це не ті, хто пам’ятає все. Вони пам’ятають саме ті сорок токенів, які потрібні.