Context engineering для Claude 5: нові правила побудови ефективних AI-агентів

Якщо ваш AI-агент регулярно видає дивні результати або "забуває" важливі правила посередині сесії — швидше за все, проблема не в моделі. Проблема в тому, як ви формуєте контекст. Context engineering для Claude 5 — це вже не факультативна тема для розробників; це базова компетенція для будь-якого керівника, який хоче вибудувати AI-систему, якій можна довірити реальний бізнес-процес: від погодження рахунків до моніторингу відповідності.

Anthropic нещодавно зробила щось неочікуване: при переході на моделі Claude Opus 5 та Claude Fable 5 інженери компанії прибрали понад 80% системного промпту Claude Code — і не зафіксували жодних втрат на внутрішніх оцінках якості. Цей факт руйнує одне з найпоширеніших переконань у сфері AI-автоматизації: що більше інструкцій — то краща поведінка агента.

---

Чому prompt engineering більше не рятує

Протягом 2023–2024 років "правильний промпт" вважався ключем до всього. Компанії наймали "prompt-інженерів", які годинами шліфували інструкції, додавали приклади, обмеження, уточнення. Логіка була простою: більше правил — менше непередбачуваності.

Проблема в тому, що ця логіка перестала працювати з появою сучасних великих моделей. За даними DataHub зі звіту State of Context Management Report 2026, 82% технічних лідерів погоджуються, що prompt engineering сам по собі вже не достатній для масштабування AI. Не дивно: класичний підхід розрахований на одноразові запити, а не на складні багатокрокові агентські сценарії, де модель ухвалює десятки рішень підряд.

Prompt engineering відповідає на питання "що сказати моделі". Context engineering відповідає на питання "що модель знає, коли ти це говориш".

Це принципова різниця. AI-дослідник Андрей Карпаті описував context engineering як "тонке мистецтво і науку наповнення контекстного вікна саме тією інформацією, яка потрібна". Аналітичне агентство Gartner у жовтні 2025 року прямо заявило, що AI-лідери мають "пріоритизувати контекст над промптами", будуючи архітектури з динамічними даними замість статичних інструкцій.

Три шари контексту, про які забувають

Коли ви надсилаєте запит до Claude, промпт — лише одна маленька частина того, що бачить модель. Решту збирають автоматично:

• Системний промпт — визначає, у якому продукті й ролі діє модель
• CLAUDE.md та Skills — постійні файли з правилами, процедурами, специфікою репозиторію чи бізнес-процесу
• Пам'ять (Memory) — персистентне сховище, яке дозволяє агенту "пам'ятати" між сесіями
• Інструменти (Tools) — набір функцій, які агент може викликати

Типова помилка: власники бізнес-агентів намагаються вкласти все в системний промпт — і отримують роздутий, суперечливий документ, у якому навіть розбиратися страшно. Claude Opus 5, як і Fable 5, не потребує жорстких рейок там, де раніше вони були необхідні. Більш здібна модель, отримавши конфліктуючі правила, не просто ігнорує одне з них — вона витрачає обчислювальну увагу на вирішення суперечності, і це безпосередньо впливає на якість результату.

---

Чотири принципи context engineering для бізнес-агентів

1. Принципи замість правил

Старий підхід: детальний перелік того, що агент НЕ повинен робити. "Не редагуй файли без підтвердження. Не відправляй email без погодження. Не змінюй бюджети понад X."

Новий підхід: сформулюйте принцип, який охоплює всі ці випадки одразу. "Перш ніж виконати незворотню дію — запитуй підтвердження."

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

2. Дерево файлів замість одного документа

Anthropic явно рекомендує: замість одного CLAUDE.md-файлу як "централізованого репозиторію всього" — будуйте дерево файлів, де кожен завантажується у потрібний момент.

Практично це виглядає так: є базовий файл із загальним описом агента та критичними gotchas. Є окремі файли для кожного модуля: один — для обробки рахунків-фактур, інший — для ескалацій, третій — для звітності. Агент підвантажує лише той файл, який потрібен для поточного завдання.

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

3. Дизайн інтерфейсів замість прикладів

Раніше в системний промпт додавали десятки прикладів формату "запит → відповідь", щоб показати моделі, як поводитися. Для Claude 5 це здебільшого зайве — і дороге, у прямому сенсі: кожен токен у контексті коштує грошей.

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

Як формулює принцип команда Anthropic: якщо людина-розробник не може однозначно сказати, який інструмент використовувати в конкретній ситуації — агент не впорається краще. Bloated tool sets з дублюючими функціями — один із найпоширеніших чинників збоїв у бізнес-агентах.

4. Progressive disclosure замість front-loading

Не завантажуйте весь контекст наперед. Надавайте агенту інформацію тоді, коли вона дійсно потрібна.

Це особливо важливо для агентів, що працюють з великими обсягами даних: контрактами, базою клієнтів, архівами листування. Замість того щоб вкладати все у стартовий контекст, використовуйте retrieval — семантичний пошук, що підтягує лише релевантні фрагменти безпосередньо перед запитом. Дослідження 2025 року зафіксувало, що точність моделі падає на 24,2%, коли потрібна інформація "потоплена" у довгому контексті серед нерелевантних даних — навіть коли всі зайві токени технічно замасковані. Це не абстрактна цифра: для агента, який щодня обробляє сотні транзакцій, така похибка матиме пряму вартість.

---

Як це виглядає на практиці: архітектура бізнес-агента

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

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

Шар 2 — Спеціалізовані Skills. Окремий файл для логіки верифікації постачальника. Окремий — для правил погодження по сумі. Окремий — для шаблонів ескалації. Кожен завантажується лише тоді, коли агент входить у відповідний крок процесу.

Шар 3 — Пам'ять. Агент зберігає результати попередніх перевірок, статуси відкритих запитів, нотатки про виняткові ситуації. Після перезапуску він читає свої нотатки та продовжує з того місця, де зупинився. Саме так Anthropic описує поведінку агентів у довгострокових завданнях: можливість читати власні нотатки після скидання контексту — ключова умова багатогодинних автономних сценаріїв.

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

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

---

Помилки, які ламають агентів в корпоративному середовищі

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

Суперечливі правила в різних шарах. Типова ситуація: системний промпт каже "залишай документацію там, де доречно", а CLAUDE.md файл у репозиторії — "НЕ додавай коментарі". Агент обробляє цей конфлікт, але витрачає на це увагу, яка мала б іти на завдання. Для Claude Opus 5 та Fable 5 це особливо гостро: більш здібна модель "педантичніше" виконуватиме конфліктуючі інструкції — і заходитиме у нелогічні місця з більшою послідовністю, ніж слабша.

Застарілий контекст як єдине джерело правди. Ряд команд досі тримає всю "пам'ять" агента в одному CLAUDE.md файлі — підхід, який був нормою у 2024 році. Сьогодні це, за словами фахівців, що аналізують нову архітектуру Claude 5, "вантажний культ минулого": пам'ять, артефакти та спеціалізовані Skills тепер завантажуються і передаються між сесіями нативно, без ручного копіювання в один файл.

Інструменти, що повертають надлишок даних. Якщо виклик інструменту get_contract_data повертає 50 полів, з яких агенту потрібні три — решта 47 займають контекст, знижують точність і збільшують витрати. Токени у контексті — не безкоштовні. Для Claude Fable 5 ціна складає $10 за мільйон вхідних токенів. Архітектурна ощадливість тут безпосередньо впливає на OPEX.

Ігнорування рубрик для перевірки якості. Claude Code підтримує концепцію rubrics — окремих довідкових матеріалів, які агент-верифікатор використовує для оцінки результату іншого агента. Для бізнесу це означає можливість автоматично перевіряти відповіді агента стандартам якості без залучення людини — наприклад, чи відповідає підготовлений договір шаблону компанії, чи чи задовольняє звіт формату для ради директорів.

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

---

Як перейти на нову архітектуру: покроковий план

Context engineering — це не разова технічна задача для розробника. Це операційна дисципліна, яку варто запровадити системно.

Крок 1: Аудит поточного контексту. Зберіть усі файли конфігурації ваших агентів — системні промпти, CLAUDE.md, будь-які інструкції. Знайдіть дублі та суперечності. Правило: якщо два правила можуть конфліктувати — вони рано чи пізно конфліктуватимуть.

Крок 2: Переведення правил у принципи. Для кожного блоку "не роби X, не роби Y, не роби Z" — сформулюйте один вищий принцип, що їх усіх покриває. Скорочення обсягу системного промпту на 50–70% без втрати якості — реалістична ціль.

Крок 3: Декомпозиція на Skills. Виділіть ті частини логіки, що стосуються конкретних підпроцесів. Кожен підпроцес — окремий файл, що завантажується на вимогу.

Крок 4: Аудит інструментів. Для кожного інструменту задайте два питання: чи може агент переплутати його з іншим? Чи повертає він більше, ніж потрібно? Якщо відповідь "так" хоча б на одне — інструмент потребує переробки.

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

Крок 6: Побудуйте eval-цикл. Будь-які зміни контексту повинні проходити через перевірку на вашому внутрішньому наборі тест-кейсів. Антропіківський принцип: "їхні eval — їхні; ваші можуть відрізнятися". Не приймайте зміни на основі лише загальних бенчмарків — тестуйте на реальних завданнях вашого бізнесу.

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

---

FAQ

Що таке context engineering і чим воно відрізняється від prompt engineering? Prompt engineering — це робота над формулюванням конкретного запиту до моделі. Context engineering — це архітектура всього, що модель отримує: системний промпт, пам'ять, інструменти, завантажені файли, результати попередніх кроків. Prompt engineering є частиною context engineering, але не навпаки.

Чи справді можна прибрати 80% системного промпту без втрати якості? Anthropic зробила саме це при переході на Claude Opus 5 та Fable 5 у своєму власному продукті — Claude Code. Ключ у тому, що нові покоління моделей краще розуміють принципи і не потребують детального переліку правил для кожного можливого сценарію. Але завжди тестуйте на власних даних.

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

Що таке Skills у контексті Claude 5 і як їх використовувати? Skills — це окремі файли з інструкціями для конкретних підзавдань, що підвантажуються динамічно. На відміну від CLAUDE.md, який завжди присутній у контексті, Skill активується лише тоді, коли агент виконує відповідну дію. Це дозволяє тримати базовий контекст легким, а специфічні процедури — доступними при потребі.

Як рубрики (rubrics) допомагають у бізнес-агентах? Рубрика — це довідковий документ, що описує критерії якісного результату (наприклад, "як виглядає хороший договір постачання"). Агент-верифікатор отримує рубрику і перевіряє результат основного агента за цими критеріями. Це дозволяє автоматизувати контроль якості без постійного залучення людини-рецензента.

Чи потрібен технічний директор, щоб впровадити context engineering? Для базового впровадження — ні. Аудит промптів, перегляд правил і декомпозиція на файли — це робота, яку може провести операційний менеджер з базовим розумінням того, як влаштовані AI-агенти. Для складних архітектур із кастомними інструментами та RAG — так, потрібна технічна компетенція або зовнішня експертиза.

---

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

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

Ради директорів та інвестори дедалі частіше оцінюють не лише AI-стратегію на папері, а реальну зрілість операційного впровадження. CEO, що може показати не "ми впровадили AI", а "ось архітектура, ось eval-цикл, ось метрики надійності" — виглядає в цих розмовах зовсім інакше, ніж той, хто досі демонструє скриншоти промптів.

З яким конкретним процесом у вашій компанії ви б хотіли першим перевірити ці принципи на практиці? Напишіть у коментарях або зверніться до нас — розберемо вашу ситуацію разом.