Claude Code, Cursor і Devin за останній рік перетворилися з тонких обгорток над одним API-викликом на системи з десятками рухомих частин: контекст-менеджмент, дозволи на дії, sub-agents, памʼять між сесіями. Цей шар навколо моделі називають agentic harness, і йому присвячений розлогий розбір видання Latent Space.

За даними Latent Space, harness ускладнюється швидше за самі базові моделі, і саме це визначає, чи агент реально працює в проді, чи лишається демо. Агент, що падає на третьому кроці, і агент, що доводить задачу до кінця, рідко відрізняються моделлю всередині — вони відрізняються тим, як побудований шар навколо неї.

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

Що таке agentic harness і чому про нього раптом заговорили?

Harness — це весь інструментальний шар між LLM і реальним світом. Він визначає, як агент отримує контекст, які інструменти йому доступні, хто дає дозвіл на ризиковану дію і як він памʼятає попередні кроки в довгій сесії. Модель у цій конструкції лишається лише одним компонентом, хоч і найпомітнішим.

Ще недавно цей шар був простим: промпт, виклик API, парсинг відповіді. Зараз він включає:

Чому harness часто важливіший за саму модель?

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

Оновлення моделі саме по собі рідко рятує агента, який погано працює. Якщо проблема в тому, як шар навколо LLM формує контекст або передає інструменти, новіша модель просто швидше повторить ту саму помилку.

Що саме ускладнюється всередині harness?

За спостереженням Latent Space, складність зростає одразу в кількох напрямках: у способі подачі інструментів моделі, в управлінні станом довгих сесій і в координації кількох агентів, які працюють над частинами однієї задачі. У відповідь на ринку зʼявляються окремі продукти й фреймворки, чия єдина функція — бути якісним harness над чужою моделлю, а не власною LLM.

Схожу логіку інфраструктурної незалежності від одного постачальника ми вже бачили в іншому контексті. Ramp побудував власний AI-роутер замість підписки на одного провайдера моделей, і це той самий принцип, застосований до маршрутизації запитів, а не до agentic-логіки.

Висновок AiiN: куди AI-білдеру інвестувати зараз

Якщо бюджет обмежений, у 2026 році розумніше вкладати інженерні години в harness (контекст, дозволи, memory, оркестрацію), ніж ганятися за кожним новим релізом моделі. Модель можна поміняти рядком конфігурації за годину. Переписати архітектуру навколо неї, коли вона розповзлася без плану, займає тижні. Команди, які з самого початку проєктують harness як окремий, тестований шар, а не побічний продукт промпт-інжинірингу, отримують агентів, що масштабуються без переписування з нуля щоразу, коли зʼявляється нова модель. Практично це означає окремий бюджет на QA agentic-флоу, а не тільки на API-виклики до моделі.

Чи означає це, що вибір моделі взагалі не має значення?

Ні, модель усе ще задає стелю можливостей: reasoning, довжину контексту, якість tool-calling. Але за інших рівних умов різниця в якості готового продукту частіше пояснюється harness, ніж переходом з однієї фронтирної моделі на іншу.

З чого почати, якщо я будую власного агента?

Почніть з трьох речей: явної системи дозволів для дій із побічними ефектами, стратегії стиснення контексту до того, як вікно переповниться, і логування кожного кроку агента для дебагу. Ці три елементи harness частіше визначають надійність продукту в перші місяці, ніж вибір конкретної моделі.