Агенти на базі GPT-5, Claude чи Gemini, які ведуть довгі багатогодинні сесії, здатні непомітно «загубити» частину інструкцій користувача в момент, коли система стискає історію діалогу, щоб звільнити місце в контекстному вікні для нових токенів. За даними The Decoder (серпень 2026), саме такий тихий побічний ефект компресії контексту (context compaction) призводить до втрати правил, обмежень і попередньо заданих вимог — без жодного попередження чи логу помилки.

Для розробника, який годинами вибудовував систему промптів, тримав агента в межах чіткого технічного завдання чи забороняв певні дії, це виглядає як тихий регрес: агент раптом починає ігнорувати правило, яке щойно виконував бездоганно. Жодного винятку, жодного логу помилки — просто компресія «з'їла» рядок, який здавався критичним.

Проблема не в тому, що модель «забула» в людському сенсі. Вона в тому, що алгоритм стиску вирішує, які фрагменти діалогу варті збереження в резюме, а які — ні, і це рішення непрозоре для користувача.

Як компресія контексту технічно призводить до втрати інструкцій?

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

• Інструкції, дані одноразово в середині довгого діалогу, ризикують найбільше — модель резюмування не завжди розпізнає їх як окремий клас даних, відмінний від звичайної розмови.
• Чим довший ланцюжок компресій (стиск за стиском у багатогодинній агентній сесії), тим вища ймовірність кумулятивної втрати деталей.
• Системні промпти, закріплені окремим незмінним полем, а не в тілі діалогу, страждають менше — вони, як правило, взагалі не проходять через цикл резюмування.

Кого це зачіпає найбільше?

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

Для короткого чат-запиту «поясни цю функцію» ризик мінімальний — діалог просто не встигає дорости до ліміту. А ось агент, якому доручили тримати десяток бізнес-правил протягом восьмигодинної сесії обробки тікетів, — типовий кандидат на тихе випадіння одного з них десь на третій годині роботи.

Що робити з цим уже зараз?

Повністю усунути ризик користувач інструмента не може — механізм стиску контролює сама платформа. Але кілька практик знижують ймовірність втрати:

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

Висновок AiiN

За нашою оцінкою, тихе випадіння інструкцій під час компресії контексту — це не баг окремого продукту, а системний наслідок того, як агентні AI-інструменти масштабуються на довгі задачі: компресія економить токени й гроші, але платить за це прозорістю. Поки постачальники не додадуть явний механізм «незнищенних» інструкцій (immutable pinned context) з підтвердженням, що правило пережило стиск, відповідальність за перевірку лежить на розробнику, який будує агента. Практичний висновок простий: критичні обмеження варто тримати поза зоною компресії, а не сподіватися, що модель «сама розбереться», що важливо.

Що таке компресія контексту (context compaction) в AI-агентах?

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

Чи можна вимкнути компресію контексту повністю?

У більшості агентних інструментів — ні, оскільки без неї сесія просто впреться в ліміт токенів і зупиниться; натомість можна впливати на те, які дані потрапляють у зону стиску, виносячи критичні правила в окремі незмінні поля.

Чи стосується це лише довгих агентних сесій?

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