У подкасті Confluent Developer архітектор даних і AI‑систем Джон Міллер (Enid Technologies) та технологічний керівник з фінансового сектору Ерік Бродa (Agentic Mesh Company) розповідають, як мислити пам’ять у світі enterprise‑агентів. Їхня мета — побудувати агентів, які є повноцінними учасниками бізнес‑процесів, а не просто «розумними чатботами». Ключова частина цієї амбіції — системна робота з пам’яттю та контекстом.
Мюллер і Бродa пропонують розкладати пам’ять агентів на п’ять окремих типів і зводити все до того, що вони називають minimum viable context — мінімально життєздатний контекст, який агент отримує під час виклику LLM. Саме від цього, на їхню думку, залежить, чи зможуть агентні системи масштабуватися до рівня реальних корпоративних процесів.
Без пам’яті агент лише «вигадує»
Вихідна теза проста й доволі жорстка: без пам’яті агент не може приймати осмислені рішення. Міллер порівнює це з людьми: якщо немає знання про домен, проблему, політики чи історію взаємодій, ви по суті все вигадуєте. Те саме відбувається з LLM — якщо модель не знає і не може згадати, вона не може прийняти обґрунтоване рішення, лише генерувати більш‑менш правдоподібні відповіді.
У контексті enterprise‑агентів це особливо критично. Вони мають брати участь у бізнес‑процесах, виконувати завдання, пов’язані з комплаєнсом, обробкою транзакцій, інтерпретацією внутрішніх політик. Для цього мало просто вміти «розмовляти» природною мовою або викликати API. Потрібна цілеспрямована робота з пам’яттю, яка підказує не лише «що це таке», а й «як наша конкретна компанія хоче це робити».
Саме тут вступає в гру деталізована модель пам’яті, яку пропонують автори agentic mesh.
Статична пам’ять: те, з чим приходить модель
Перший тип — статична пам’ять. Це «pre‑trained штука», з якою приходить сама LLM або агент. Можна уявити її як загальний світогляд моделі: мова, базові факти, патерни текстів, типові структури кодів, сценаріїв чи документів, набуті під час попереднього навчання.
Ця пам’ять потужна, але загальна. У ній ще немає специфіки конкретної організації, її бізнес‑процесів, ролей, документопотоків, доменної термінології, не кажучи вже про локальні винятки чи кулуарні практики, якими насправді живе будь‑який великий бізнес.
Тому статичної пам’яті, на думку спікерів, недостатньо, якщо йдеться про enterprise‑агентів як учасників процесів, а не просто інструментів для розробників.
Довготривала enterprise‑пам’ять: «як у нас тут прийнято»
Другий рівень — довготривала enterprise‑пам’ять. Тут ідеться про те, як саме компанія хоче робити речі й наскільки специфічно це реалізовано в її процесах.
Якщо агент бере участь, наприклад, у комплаєнс‑процесі, йому потрібне не абстрактне уявлення про регуляції, а унікальний спосіб, у який ця організація їх інтерпретує та втілює. Це стосується процедур, локальних правил, особливих кроків погодження, послідовностей дій — усього, що відрізняє одну компанію від іншої.
Саме цю інформацію Бродa називає enterprise‑пам’яттю — те, що «вариться» у контекст, коли агенту потрібно виконати завдання в рамках реального бізнес‑процесу. Вона перетворює загальну модель на учасника конкретної корпоративної культури й операцій.
Семантична пам’ять: онтології, поняття та політики поверх них
Третій тип — семантична пам’ять. Вона відповідає за концепти, визначення, онтології й політики, накладені на ці поняття.
Автори підкреслюють, що зазвичай системи зберігають визначення об’єктів — скажімо, що таке «рахунок‑фактура». Але в enterprise‑середовищі цього замало. Є ще політики й «неявне знання» про те, що відбувається, коли сума занадто велика, коли виявлено помилку, які граничні значення вважаються ризикованими, хто має право ухвалювати рішення в нетипових випадках.
Ці політики та інтерпретації фактично є шаром над онтологіями. Саме вони перетворюють статичні визначення на робочу інструкцію для агента. Бродa прямо відносить такі речі до семантичної пам’яті й наполягає, що вони мають бути формально представлені та доступні агенту, а не залишатися лише в головах людей.
У цьому місці в розмові з’являються згадки про знаннєві графи, онтології, підходи на кшталт RAG як окремі інструменти, що можуть бути частиною цієї семантичної пам’яті, але не вичерпують її.
Спільна пам’ять між агентами: бачити розмови одне одного
Четвертий вимір — спільна пам’ять між агентами. Вона стає необхідною, коли агенти працюють разом над більшою проблемою, ніж можуть розв’язати поодинці.
Якщо кілька агентів беруть участь в одному бізнес‑процесі, їм потрібно бачити розмови одне одного, знати, які проміжні висновки вже зроблено, які дані перевірено, які дії виконано чи відхилено. Інакше кожен агент буде щоразу «починати з нуля», і система втратить перевагу від розподілу ролей і співпраці.
Бродa говорить саме про shared memory між агентами як окрему категорію. Це не просто логування чи аудит, а функціональна пам’ять, яка дозволяє агентам координуватися, будуючи спільне уявлення про задачу й прогрес роботи.
У їхній концепції agentic mesh саме ця спільна пам’ять є частиною «фабрик» довіри й ідентичності, які оточують агентів у ентерпрайзі. Але навіть без заглиблення в mesh очевидно, що без shared memory масштабування до багатoагентних сценаріїв ризикує розвалитися в хаос дублювання зусиль.
Minimum viable context: пам’ять підганяє токен‑бюджет
П’ятий, ключовий елемент — те, як усі попередні типи пам’яті врешті потрапляють у контекст виклику LLM. Тут Бродa вводить поняття minimum viable context.
Ідея в тому, щоб зібрати статичну, enterprise‑, семантичну й спільну пам’ять в єдиний контекст, але зробити це токен‑обізнано й ощадливо. Контекст в LLM залишається дефіцитним ресурсом, і автори прямо кажуть: усе це потрібно «зварити» в token‑aware штуку, яка подає правильний контент у правильний час з урахуванням бюджету токенів.
Вони наголошують, що йдеться саме про minimum viable context, а не просто про «чим більше, тим краще». Завдання системи пам’яті — вирішити, яку частину знань слід підвантажити зараз для конкретного запиту й завдання, щоб агент міг прийняти коректне рішення, не виходячи за межі токен‑лімітів.
Контекст, у їхньому баченні, — це не статичний «дамп» усієї можливої інформації, а динамічно сконструйований наріз пам’яті, оптимізований по корисності й вартості.
«Віртуальне управління пам’яттю» для агентів
Міллер описує це як свого роду «virtual memory management» для агентів. Він згадує, що вони багато писали й говорили про те, що таке minimum viable context для агента, який має відповісти на запитання чи виконати задачу.
Оскільки контекст у LLM схожий на людську короткочасну пам’ять — обмежений за обсягом і часом утримання, — вміння обирати, що саме потрапляє туди в кожний момент, стає першокласною турботою. Особливо коли йдеться про довгі сесії з coding‑агентами або про багатокрокові бізнес‑процеси, де, як зазначає Міллер, користувачам доводиться «підгодовувати» агента певною пам’яттю, щоб робота не розвалювалася.
Звідси випливає ще одна важлива думка: створення «другого мозку» або спеціальної пам’яті, якою живляться агенти, перестає бути опцією. Для enterprise‑класу агентів це, на їхню думку, вже частина базового дизайну системи, а не приємний бонус.
Як це під’єднати до агентів на базі coding‑моделей
Розмова відбувається на тлі більшої дискусії про використання coding‑агентів на кшталт Claude Code чи Codex як «двигуна» всередині enterprise‑агента. Бродa й Міллер розглядають їх як дуже здатних «працівників», які можуть виконувати складні, довготривалі завдання, виходячи далеко за межі суто програмування.
Але саме тому, підкреслює Бродa, їх потрібно оточити інфраструктурою — від ідентичності й доступів до пам’яті. У цьому контексті minimum viable context і п’ять типів пам’яті перетворюються на обов’язковий шар між сирою потужністю coding‑агента і реальним бізнес‑процесом.
Звідси з’являється ще один термін — agentic knowledge fabric, або AKF. Це назва для зв’язуючого шару, який об’єднує різні типи пам’яті та механізми доступу до знань. Бродa окреслює його скоріше як концептуальну парасольку: саме тут зосереджуються інструменти на кшталт онтологій, знаннєвих графів, політик, RAG‑подібних підходів — усе, що дозволяє побудувати семантичну й enterprise‑пам’ять, а потім «упакувати» її в токен‑обізнаний контекст.
Висновок: пам’ять як перший клас для агентів ентерпрайзу
З усього сказаного Міллер і Бродa роблять чіткий висновок: про пам’ять агентів у ентерпрайзі потрібно думати системно й багаторівнево. Є, як вони формулюють, «п’ять різних типів пам’яті, і вам потрібно думати про всі них». Статична, enterprise‑, семантична й спільна пам’ять створюють матеріал, з якого збирається minimum viable context — той самий мінімальний, але достатній зріз знань, що потрапляє до LLM у кожному конкретному виклику.
Без цього, на їхню думку, enterprise‑агенти залишаються в режимі «вигадування» — вони не пам’ятають ні історії процесів, ні специфіки компанії, ні прихованих політик, ні колективного прогресу інших агентів. А отже, не можуть стати повноцінними й безпечними учасниками бізнес‑процесів.
Наступний крок, який вони обговорюють у ширшій розмові, — це вже mesh‑рівень: як організувати ідентичності, ролі, доступи, explainability й облік токенів для цілих екосистем агентів. Але саме концепція п’яти типів пам’яті та minimum viable context задає фундамент, на якому такі системи мають будуватися.
Джерело
Agent Mesh: A Microservice With a Brain ft John Miller & Eric Broda | Ep. 33 | Confluent Developer