Знайома ситуація: дві компанії запускають AI-агента на тій самій моделі. В однієї він місяцями стабільно обробляє заявки, в іншої — сьогодні відповідає блискуче, а завтра видає нісенітницю. Власник робить висновок «AI ще сирий». Насправді різниця не в моделі, а в трьох шарах довкола неї: системі обмежень, формулюванні інструкцій і доступі до свіжої документації. Розберімо кожен — а наприкінці буде чек-лист питань до підрядника.
Модель — це двигун, harness — це машина
Princeton дослідив 14 моделей і виявив неприємну закономірність: точність (accuracy) зростає від покоління до покоління, а надійність (reliability) — ні. Модель стає розумнішою, але не стає передбачуванішою. Це різні властивості, й одна не тягне за собою іншу автоматично.
Тому команди, які всерйоз будують агентів, вкладаються не в «кращу модель», а в harness — систему обмежень довкола неї. Manus переписували свій harness п'ять разів за шість місяців: ті самі моделі, п'ять різних архітектур обмежень — і кожна ітерація покращувала результат. Vercel прибрав у свого агента 80% інструментів — і агент запрацював краще: менше опцій, менше місця для помилки. У мене в щоденній роботі 17 агентів, і стабільні вони не завдяки найкрутішій моделі чи «магічним промптам», а завдяки суворим обмеженням, де крок убік неможливий.
На практиці harness — це skill: чітка інструкція з п'яти елементів. Що робити (один абзац, без води). Як робити (максимум три кроки). Критерії приймання (не виконано — результат не зараховується). Точний формат відповіді. І заборони (чого не робити ніколи). Один skill — одна задача; якщо задача занадто широка, її ділять на дві.
Звучить контрінтуїтивно, але більше обмежень означає стабільніший результат: звуження задачі й чіткі критерії піднімають частку успішних виконань до приблизно 90%. Посередня модель у суворому harness надійніша за найрозумнішу в хаосі. Це, до речі, не лише про AI: згадайте найкращого працівника без чіткого ТЗ — результат щоразу інший.
Чому «ти — досвідчений сеньйор» не працює
Другий шар — самі інструкції. Популярний рецепт «дай моделі роль — і вона стане розумнішою» не працює. Anthropic описали цю помилку мислення й назвали її «Claude Mythos Problem».
Роль не додає моделі знань — вона активує стереотип із навчальних даних. «Досвідчений senior engineer» у датасеті — це не досвід конкретного інженера, а LinkedIn-пости про work-life balance, обережні корпоративні вікі та середні відповіді з форумів. Агент звучатиме саме так: усереднено, передбачувано, нецікаво.
Натомість працює функціональна роль:
❌ «Ти — найкращий code reviewer з 20 роками досвіду»
✅ «Ти code reviewer. Отримуєш зміни коду. Повертаєш максимум 5 зауважень з позначками: критично / попередження / дрібниця»
Перше — ідентичність: нуль нової інформації для моделі. Друге — мета, інструкції та критерії приймання. Моделі не треба знати, «хто вона». Їй треба знати, що вона отримує на вхід, що повертає на вихід і де межа якості.
Агент, який живе в минулому
Третій шар найкраще видно на прикладі з розробки. Claude написав getServerSideProps — підхід, від якого проєкт відмовився три роки тому. Агент уважно читає код, розуміє архітектуру, пам'ятає контекст — і водночас застряг у 2023 році, якщо йдеться про документацію.
У кожної моделі є cutoff date — дата, після якої вона не знає нічого. Вийшов Next.js 14 — у моделі ще 13. React 19 приніс нові інструменти — модель пропонує старі. І це не «іноді помиляється», а систематична поведінка: з кожною популярною бібліотекою доводиться перевіряти, чи метод ще актуальний. Технар, який звик довіряти підказкам агента, втрачає на таких перевірках годину на день.
Розв'язання просте. Context7 від Upstash — MCP-сервер, який під'єднується до Claude Code (Cursor і Codex теж) і дає агенту свіжу документацію бібліотек у реальному часі, прямо з джерела, а не з пам'яті моделі. Налаштування — п'ять хвилин: одна команда, далі достатньо додати «use context7» у запит. Реальний приклад: свіжа документація бібліотеки за 30 секунд, модуль переписано на новий API — жодної вигаданої функції, код запрацював з першого разу.
Чек-лист: що спитати в підрядника
Цих трьох шарів не видно в демо — на презентації агент завжди працює. Зате їх легко перевірити питаннями:
Питання | Відповідь, яку варто почути |
|---|---|
Як ви обмежуєте агента? | Кожен має skill: мета, кроки, критерії приймання, формат, заборони |
Скільки задач виконує один агент? | Одну. Широкі задачі ділимо між кількома агентами |
Що буде з неправильним результатом? | Не пройшов критерії приймання — не зараховується |
Чи пишете у промптах «ти — найкращий експерт»? | Ні, ролі функціональні: вхід, вихід, межа якості |
Звідки агент бере документацію? | Жива документація в реальному часі (MCP), не лише пам'ять моделі |
Результати нестабільні — ваші дії? | Звужуємо задачу й посилюємо обмеження, а не міняємо модель |
Якщо на останнє питання лунає «перейдемо на потужнішу модель» — це червоний прапорець: заміна двигуна там, де бракує керма й гальм. Нестабільність — ознака слабкого harness, а не слабкої моделі.
Хочете зрозуміти, чому ваш агент працює нестабільно? AI-аудит Grow2.ai розбирає це на конкретному процесі. Базовий гайд: AI-агенти для МСБ. Якщо агент має жити у ваших процесах і CRM — це домен сестринського Auspex; стратегічний погляд на AI — в Andrew Maryasov.