Коли великі компанії намагаються «нагодувати» AI‑агентів усім корпоративним знанням одразу, результат часто виявляється розчаровуючим: купа інтеграцій, красиві діаграми, але Jira‑квитки так і не рухаються швидше. На це дивиться зсередини великого ентерпрайза Радж Навакоті — staff software engineer в IKEA у домені Delivery Services, де понад сотня інженерів працює як «компанія в компанії». У своїй доповіді він пропонує альтернативу класичному підходу до контексту для агентів — методологію demand‑driven context, яку в березні 2025 року формалізував у препринті на arXiv.
Це не ще один рецепт «як краще налаштувати RAG». Йдеться про зміну самої логіки побудови знання: від здогадок зверху до навчання з реальних провалів агентів, крок за кроком, як у test‑driven development.
Від «нагодувати все одразу» до «дати задачу і подивитися, де болить»
Класичний ентерпрайз‑підхід до AI‑контексту виглядає знайомо: є велика корпоративна база знань — Confluence, Jira, SharePoint, GitHub, внутрішні wiki. На неї накручують retrieval‑шар: RAG, knowledge graph, десятки MCP‑серверів. Ідея проста: якщо агенту дати доступ до всього, що знає компанія, він зможе розв’язувати реальні задачі.
На практиці це працює частково. Там, де знання формалізовані й задокументовані, RAG чи графи дають приблизно 40% фактичної точності — цього достатньо для довідкових відповідей, але замало для автономної роботи з критичними задачами. А далі починається зона невизначеності: виходи стають недетермінованими, ненадійними й, головне, майже ніхто їх системно не тестує.
Навакоті описує типовий сценарій: команда будує 10–20 MCP‑серверів, підключає всі можливі джерела, запускає агента — і виявляється, що 20–30% відповідей корисні, а решту часу люди фактично виконують роль «data entry» для агента, дописуючи відсутні деталі, виправляючи помилки, відповідаючи на уточнення. Замість економії часу — додаткове навантаження.
Корінь проблеми — у природі корпоративного знання. Значна його частина взагалі не живе в Confluence чи GitHub. Приблизно 40% — це «tribal knowledge», те, що знають конкретні люди й команди, але ніколи не оформлювали як документацію. Ще частина знання застаріла, дублюється або суперечить одне одному. У такій ситуації будь‑який retrieval‑шар стає лише складною надбудовою над монолітом, який сам по собі не придатний для роботи агентів.
Demand‑driven context пропонує розвернути цю логіку. Замість того щоб намагатися заздалегідь передбачити, що саме потрібно агенту, й «згодувати» йому все, методика пропонує дати агенту реальну роботу — інциденти, квитки, бізнес‑кейси — і дозволити саме провалам показати, якого знання бракує.
Цикл demand‑driven context: агент падає, питає, вчиться
У центрі методології — простий, але дисциплінований цикл, який перетворює кожен провал агента на крок уперед для всієї системи знань.
Спочатку агент отримує реальне завдання. У демонстрації Навакоті це — аналіз кореневої причини інциденту в складній системі доставки. Агент має доступ до наявної монолітної бази знань і стандартних джерел — логів, документації, описів сервісів. Він намагається виконати задачу, використовуючи все, що може витягнути через retrieval.
Неминуче він натикається на прогалини. У логах з’являються невідомі бізнес‑терміни, внутрішні скорочення, специфічні правила маршрутизації, які ніколи не були задокументовані. Або ж знаходить суперечливі описи одного й того ж процесу. На цьому етапі в demand‑driven context відбувається те, чого бракує більшості нинішніх інтеграцій: агент не просто «галюцинує» далі, а явно фіксує, чого саме йому не вистачає.
Ключовий момент циклу — явний запит на відсутнє знання. Агент формулює конкретне питання до людини: що означає цей термін, як поводиться цей сервіс у такому‑то сценарії, які бізнес‑правила застосовуються до цього типу замовлень. Людина дає відповідь у вільній формі, але далі вона не губиться в чаті чи листуванні.
Наступний крок — оновлення бази знань. Отримана від людини інформація структурується й додається до спільного контексту у вигляді окремого «контекст‑блоку». Це може бути невеликий Markdown‑файл із чітко визначеною сутністю: опис конкретного сервісу, бізнес‑правила для певного типу інцидентів, розшифровка внутрішнього скорочення. Головне — цей блок стає частиною спільної контекстної бази, доступної всім агентам.
Після оновлення агент знову запускається на тій самій задачі, але вже з новим контекстом. Якщо все зроблено правильно, він проходить далі, а наступний провал знову підсвічує наступну прогалину. Так, крок за кроком, реальні задачі «витягують» із людей саме те знання, яке справді потрібне для роботи агентів, а не те, що хтось вирішив задокументувати «про всяк випадок».
У демонстрації Навакоті один прогін по інциденту виявив близько шести раніше неописаних сутностей — внутрішніх термінів і бізнес‑логіки. Після їхнього оформлення як контекст‑блоків агент уже міг обробляти подібні інциденти значно впевненіше. А коли процес повторили на 14 різних інцидентах, внутрішній «скоринг упевненості» агента зріс приблизно з 1,5 до 4,4. Це не магія моделі, а результат систематичного закриття конкретних прогалин у знанні.
Test‑driven development для знання: провал як перший клас громадянин
Навакоті прямо порівнює demand‑driven context із test‑driven development (TDD). У TDD розробник спочатку пише тест, який падає, і лише потім реалізує мінімальний код, щоб тест пройшов. Провалений тест тут не побічний ефект, а головний інструмент проєктування системи.
У випадку з контекстом для агентів роль тестів відіграють реальні робочі задачі: інциденти, Jira‑квитки, запити від бізнесу. Кожна така задача — це «тест» для поточної бази знань і можливостей агентів. Якщо агент не може її виконати, це означає, що в системі бракує конкретного знання або воно оформлене так, що агент не може ним скористатися.
Demand‑driven context пропонує ставитися до цих провалів так само серйозно, як інженери ставляться до червоних тестів у TDD. Кожен провал має бути:
- Виявлений і зафіксований як конкретний кейс, а не розмитий «агент щось не те відповів».
- Проаналізований з точки зору того, якого саме контексту бракує.
- Закритий через створення нового контекст‑блоку або уточнення наявного.
- Повторно прогнаний, щоб переконатися, що нове знання справді вирішує проблему.
Різниця з класичним підходом до документації принципова. Зазвичай команди намагаються писати документацію «на майбутнє», часто не маючи чіткої відповіді, хто й коли нею скористається. У demand‑driven context кожен новий блок знання має конкретне походження: він з’явився тому, що без нього агент не зміг розв’язати реальну задачу. Це робить контекст не лише повнішим, а й значно більш релевантним.
Так само, як у TDD набір тестів із часом стає живим описом поведінки системи, набір контекст‑блоків, народжених із провалів агентів, стає живим описом того, як насправді працює організація — з усіма її неформальними правилами, винятками й історичними особливостями.
Спільна контекстна база для багатьох агентів і ролей
Ще один принциповий елемент методології — припущення про спільну контекстну базу, якою користуються різні агенти з різними ролями й межами міркування. Це не приватний кеш одного бота, а загальний «шар знання», який еволюціонує завдяки взаємодії багатьох агентів і людей.
У типовому ентерпрайзі вже зараз можна побачити кілька класів агентів: одні допомагають розробникам із кодом, інші підтримують SRE‑команди в інцидентах, треті працюють із бізнес‑аналітикою чи підтримкою клієнтів. Усі вони стикаються з різними зрізами однієї й тієї ж інституційної реальності: як працює білінг, як маршрутизуються замовлення, які SLA діють для різних ринків.
Demand‑driven context передбачає, що кожен із цих агентів, натикаючись на прогалину, не просто «лататиме» її локально, а вноситиме вклад у спільну базу. Якщо агент підтримки клієнтів вперше стикається з новим типом промо‑кампанії й змушений питати людину про специфіку її умов, відповідь оформлюється як контекст‑блок. Наступного разу, коли інцидентний агент аналізуватиме сплеск помилок, пов’язаний із цією ж кампанією, він уже матиме потрібний контекст.
Ця спільність працює і в зворотному напрямку. Агент, який спеціалізується на глибокому технічному аналізі, може виявити й задокументувати нюанси поведінки сервісу, про які бізнес‑команди навіть не підозрювали. Коли пізніше бізнес‑агент отримує запит на оцінку ризиків зміни тарифів, він уже має доступ до технічних обмежень, що впливають на цю оцінку.
Важливо, що методологія не прив’язана до конкретного сховища чи формату. У демонстрації Навакоті контекст‑блоки зберігалися як плоскі файли в Git‑репозиторії, але той самий підхід можна застосувати до Confluence, Slack, GitHub чи будь‑якого іншого джерела, підключеного через MCP або RAG. Ключове — не інструмент, а дисципліна: кожен виявлений пробіл у знанні має перетворюватися на артефакт у спільній базі.
Замість «вгадувати зверху» — будувати знизу, від інцидентів і квитків
Мабуть, найрадикальніший аспект demand‑driven context — це те, як він переосмислює саму задачу кураторства контексту. Замість топ‑даун‑підходу, коли архітектори й техліди намагаються змоделювати «повну» картину домену й описати її наперед, методика пропонує рухатися знизу, від реальних робочих артефактів.
Базовою одиницею стає не абстрактна «доменна модель», а конкретний інцидент, Jira‑квиток чи інший робочий елемент. Саме він визначає, яке знання потрібне тут і зараз. Якщо агент не може закрити квиток, значить, у базі знань бракує чогось, без чого людина теж не змогла б його закрити — або змогла б, але лише завдяки власному tribal knowledge.
Такий підхід має кілька наслідків.
По‑перше, він різко знижує ризик витрачати час на документацію, якою ніхто не користуватиметься. Кожен контекст‑блок має «родовід» у вигляді конкретного інциденту чи задачі, де він уперше знадобився.
По‑друге, він природно пріоритизує знання за бізнес‑цінністю. Інциденти з високою критичністю, квитки, що блокують релізи, або задачі з великим фінансовим впливом автоматично стають «тестами» вищого пріоритету. Відповідно, прогалини, які вони виявляють, закриваються раніше, ніж менш важливі.
По‑третє, він дозволяє будувати знання інкрементально. Не потрібно чекати, поки хтось «перепише всю документацію». Достатньо почати з невеликої підмножини задач, які вже сьогодні обробляють агенти, і дозволити їм поступово витягувати з організації те, що справді критично.
У цьому сенсі demand‑driven context нагадує перехід від водоспадної розробки до agile. Замість того щоб намагатися спроєктувати всю систему наперед, команда працює ітеративно, отримуючи зворотний зв’язок від реального використання на кожному кроці. Тут роль «спринтів» відіграють цикли провалів і виправлень агентів, а роль «беклогу» — черга інцидентів і квитків, які ще не були пропущені через цей цикл.
Висновок: провали як ресурс, а не як загроза
Demand‑driven context не обіцяє чарівного стрибка від 6% до 100% бізнес‑цінності від AI. Але він пропонує чітку відповідь на питання, чому навіть найпотужніші моделі й найскладніші retrieval‑шари не перетворюються автоматично на продуктивність у Jira й реальні закриті задачі.
Проблема не лише в якості моделей чи інструментів, а в тому, як організації мислять про власне знання. Поки інституційна пам’ять залишається монолітом, наполовину застарілим, наполовину невимовленим, агенти неминуче будуть «як герой з Memento» — сильні в обчисленнях, але безпорадні без підказок людей.
Методологія demand‑driven context пропонує прийняти цю реальність і використати її. Дати агентам реальну роботу. Дозволити їм провалюватися. Зробити ці провали видимими, конкретними й відтворюваними. І перетворити кожен із них на маленький, але чітко окреслений шматок знання, який більше ніколи не доведеться витягувати з чиєїсь голови вночі під час інциденту.
У цьому сенсі майбутнє корпоративних AI‑систем може виявитися не стільки в черговій «супермоделі», скільки в тому, наскільки дисципліновано організації навчаться слухати власні провали — і будувати з них базу знань, якою зможуть користуватися як люди, так і агенти.
Джерело
Demand-Driven Context: A Methodology for Coherent Knowledge Bases Through Agent Failure