Роман Поляшенко
Увесь останній рік навколо «AI-співробітників» точиться суперечка у двох площинах: наскільки розумні моделі й хто керує агентами. Ми будуємо такі системи для компаній, тож скажу прямо: у проді агент валиться не там, куди всі дивляться. Найчастіша причина, чому AI-«співробітник» не доживає до кінця довгої задачі, — нудна й механічна. Це не інтелект і не «управління». Це те, що відбувається з контекстним вікном агента, поки задача триває.
І тут закладена контрінтуїтивна пастка. Здається логічним: якщо агент «забуває» — дай йому памʼять. У 2026-му зʼявилися строгі дані, які показують, що наївно «прикрутити памʼять» часто робить агента гіршим, а не кращим. Розберемо, де насправді вузьке місце — і що з цим працює.
«Обрив надійності» на довгих задачах — і він виміряний
Перше, що варто прийняти: довга робота — це інша задача, а не «та сама, тільки довша». У дослідженні «Beyond pass@1» (arXiv:2603.29231, березень 2026) на 396 задачах, 10 open-source моделях і 23 392 прогонах агрегований показник pass@1 просів з 76,3% на коротких задачах до 52,1% на дуже довгих — падіння на 24,3 пункти. Модель та сама; змінюється лише тривалість — і надійність осідає разом із нею.
Для бізнесу це означає просту, але незручну річ: демо на короткому сценарії нічого не каже про те, як агент відпрацює реальний багатокроковий процес. Метрика, якою міряють більшість, — успіх на короткій задачі — систематично завищує очікування.
Чому «дайте йому памʼять» — це не рішення
А тепер найнеочевидніше. У тому ж дослідженні автори перевірили пряму інтуїцію «агент забуває — додаймо памʼять». Результат: памʼятевий каркас (memory scaffold) жодного разу не покращив надійність на довгих задачах і зашкодив 6 моделям із 10 (найгірше — Δ = −0,14 бала «граційної деградації» на Kimi K2.5). Проста базова петля міркування-дії (ReAct) виявилась «строго кращою в агрегаті».
Пояснення для практика: наївно «прикручена» памʼять додає агенту не сигнал, а шум. Агент починає тонути в тому, що колись бачив, замість того щоб рухатися вперед по задачі. Тобто «дайте йому довготривалу памʼять» — не універсальний фікс, а часто регрес. Це і є той висновок, який більшість команд отримує лише після того, як витратить квартал на «розумну памʼять», що робить агента дурнішим.
Що працює: правильно забувати, а не стискати
Якщо накопичувати все — агент задихається; якщо додати наївну памʼять — стає гірше. Робочий вихід лежить між ними й називається негарним словом інженерія контексту: свідомо вирішувати, що агент тримає в робочому вікні, що витісняє, а чого не памʼятає взагалі.
Тут важливо розрізняти два підходи. Поширений — компакція: періодично «стискати» історію в підсумок. Він лосі за визначенням: губить деталі, руйнує причинно-наслідкові звʼязки й породжує «галюцинації від стиснення» — агент упевнено посилається на те, чого в підсумку вже нема. Альтернатива — структурне витіснення (evict): не підсумовувати наосліп, а прицільно прибирати з вікна те, що вже не потрібне, зберігаючи структуру.
Наскільки це працює, показує «Beyond Compaction» (arXiv:2606.11213, травень 2026). Їхня схема життєвого циклу контексту дозволила одній сесії агента виконати 89 послідовних задач, спаливши 80 мільйонів токенів, без помітної деградації якості: на бенчмарку Terminal Bench 2.0 накопичувальна сесія дала 68,25% проти 68,40% в ізольованих запусках по одній задачі — різниця в межах трьох пунктів на всіх бенчмарках. Важіль — не більше вікно й не підсумовування, а дисциплінована евікція.
Це інженерна проблема, а не «магія моделі»
Що показово — до того самого висновку прийшли й самі виробники моделей, вкладаючись не в «розумнішу магію», а в примітиви керування контекстом. За даними Anthropic, поєднання інструмента памʼяті з редагуванням контексту дало +39% до якості на внутрішній агентній оцінці (саме редагування контексту — +29%), а на 100-кроковій оцінці з веб-пошуком редагування контексту скоротило витрату токенів на 84% й дало агенту завершити процеси, які інакше вмирали б від вичерпання контексту.
Меседж однаковий з обох боків — і від дослідників, і від лабораторій: керуй контекстом — і агент доходить до кінця; не керуй — і він падає. Проблема лежить не в «інтелекті» моделі, а в інженерії того, що ця модель бачить у кожен момент.
Масштаб, під який мало хто закладається
І ще одне очікування, яке варто відкалібрувати заздалегідь. Нові бенчмарки памʼяті (наприклад, BEAM) оцінюють агентів уже на 10 мільйонах токенів — це, за їхнім же формулюванням, приблизно «рік щоденних розмов з агентом, весь корпус внутрішньої документації компанії або повний вивід софтверного проєкту за сотні сесій». На такому масштабі «просто запхати все в контекст» фізично неможливо: виживає лише справжня архітектура памʼяті з вибірковим доступом, а не роздутий промпт.
Це не суперечить попередньому пункту, а доповнює його. Наївно «прикручена» памʼять на звичайній задачі шкодить; але коли обсяг переростає будь-яке вікно, потрібна не більша памʼять узагалі, а правильно спроєктована — де вирішено, що дістати, а що лишити поза увагою. І там, і там відповідь одна: це інженерія, а не розмір.
Чому це економіка, а не лише точність
Є ще причина ставитись до контексту серйозно — гроші. Контекст не безкоштовний. За інженерними даними Anthropic, агент спалює приблизно вчетверо більше токенів, ніж звичайний чат, а мультиагентні системи — приблизно в 15 разів більше. На бенчмарку BrowseComp сама лише витрата токенів пояснює 80% розкиду в результатах (усі три фактори разом — витрата токенів, кількість викликів інструментів і вибір моделі — 95%).
Звідси дисципліна: «більше контексту» — це не безкоштовна перевага, а стаття витрат. Мета — витрачати контекст там, де цінність задачі це виправдовує. Anthropic це формулює прямо: мультиагентні системи «потребують задач, цінність яких достатньо висока, щоб окупити зрослу витрату», і застерігає, що «більшість задач кодування мають менше по-справжньому паралелізовних підзадач, ніж ресьорч, а агенти поки що погано координуються й делегують одне одному в реальному часі». Тобто більше агентів і більше контексту — не за замовчуванням, а лише де математика сходиться.
Як на це дивимось ми (інтегратор, не коробка)
Для голосового чи AI-рішення, яке працює цілий день і веде довгі, багатокрокові діалоги, справжня різниця — не в тому, яка модель «під капотом», і не в тому, скільки агентів у «оргструктурі». Різниця — в інженерії життєвого циклу контексту: що агент тримає у вікні, що витісняє, чого не памʼятає зовсім і за яким бюджетом токенів усе це живе. Це нудна, невидима робота — і саме її ми проєктуємо й тестуємо ще до релізу, бо саме вона визначає, доведе агент довгий діалог до результату чи розсиплеться на середині.
З чого почати
- Міряйте надійність на довгих задачах, а не pass@1 на коротких. Демо на трьох репліках нічого не каже про 30-кроковий процес.
- Не «прикручуйте памʼять» за замовчуванням. Спершу доведіть на своєму процесі, що вона допомагає, а не додає шуму. Часто базова петля надійніша.
- Керуйте контекстом свідомо. Витісняйте нерелевантне прицільно; не покладайтесь на сліпе підсумовування, яке губить деталі й вигадує.
- Рахуйте токени як бюджет. Витрачайте контекст там, де цінність задачі це виправдовує, а не «про запас».
- Коли обсяг переростає вікно — довіряйте архітектурі памʼяті, а не розміру. На масштабі корпоративних даних виграє вибірковий доступ, а не «запхати все».
Чому це важливо вже зараз
Модель у 2026-му — це стіл ставок: потужні агенти доступні всім. Перевагу дає не «розумніший» агент, а дисципліна контексту. Агент, який уміє правильно забувати й витрачати контекст за бюджетом, доводить довгу роботу до кінця — поки «розумніші», але недисципліновані тонуть у власній історії. Хто зрозумів це раніше, той будує AI-співробітників, які працюють, а не вражають на демо й падають у проді.
