5 рівнів AI-агентів: від промпту до продакшену

Зараз навколо агентів крутяться п'ять слів. Context engineering, loop engineering, Jev engineering, harness engineering, eval engineering.

Здається, ніби це п'ять конкуруючих підходів. Але ні. Це п'ять шарів однієї системи, і кожен відповідає на своє запитання.

Найпростіше зрозуміти їх, якщо уявити, що ви щойно найняли нового працівника:

• Context — що лежить у нього на столі, коли ви про щось просите
• Loop — чи він діє за вашим чеклистом, чи сам вирішує, що робити далі
• Jev — ресепшн, який сортує пошту, щоб до нього потрапляло лише важливе
• Harness — його кабінет. Інструменти, ключі та те, хто перевіряє його роботу
• Evals — однаковий тест щомісяця, щоб ви бачили, чи він справді став кращим

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

По кожному шару я розберу, що це, як воно працює, де застосовувати і як будувати.

А ще для кожного шару я підготував шорткат. Простіший спосіб отримати той самий результат без розробки з нуля — спеціально для новачків. Зібрати ці шорткати мені допомогли друзі з Viktor.

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

Робота з ним виглядає як робота з людиною:

• Ви згадуєте його в каналі чи треді й описуєте задачу.
• Він сам визначає кроки, виконує роботу через ваші інструменти й повертає результат у той самий тред.

Налаштування просте. Додайте Viktor у свій workspace, і він з'явиться в списку учасників як будь-який інший член команди. Якщо хочете спробувати його прямо під час читання, використовуйте код YARCHI100.

pic1. П'ять шарів агента

1. Context engineering

Визначення

Перед кожним запитанням ви кладете папери на стіл працівнику. Покладете три потрібні сторінки — він відповість за секунди. Покладете триста — відповідь загубиться десь посеред купи. Він її просто пропустить.

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

Context engineering — це рішення про те, що саме класти на стіл і куди.

Як це працює

Більше контексту не означає кращих відповідей. Після певної межі це означає гірші.

У Stanford це перевірили напряму. Дайте моделі 20–30 документів, і точність на тих, що посередині, впаде приблизно до 50–57 відсотків. Без жодного документа та сама модель показала 56 відсотків. Відповідь була у вікні, але модель впоралася гірше, ніж коли не мала нічого.

Причин дві:

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

Єдиний механізм, який варто знати — prompt caching. Провайдер зберігає початок вашого промпту і перевикористовує його при наступному виклику, а закешований токен коштує приблизно вдесятеро дешевше за свіжий.

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

Як це будувати

Кожен шматок контексту потрапляє в одне з чотирьох місць:

1. System prompt. Тільки те, що правдиве при кожному виклику: роль, обмеження, формат виводу. Тримайте його ідентичним байт у байт. Ніяких таймстемпів на початку, ніяких JSON-ключів у випадковому порядку.
2. Tools. Не додавайте й не видаляйте їх посеред розмови. Це ламає кеш і змушує модель викликати інструменти, яких уже немає. Щоб обмежити інструмент на якомусь кроці, блокуйте виклик, але залишайте його визначення.
3. Disk. Усе велике або довгоживуче йде у файл, а у вікні залишається лише шлях. Те саме зі сторінкою: залиште URL, приберіть тіло. Приберіть контент, залиште ключ, за яким його можна дістати назад.
4. Tail. Кожні кілька кроків переформульовуйте поточну мету ближче до кінця контексту. Середину ви не виправите, тому тримайте важливе подалі від неї.

В інструментів теж є ліміт. Anthropic нарахували, що 58 визначень інструментів з'їдають близько 55 000 токенів ще до того, як користувач щось надрукує. Коли моделі дозволили шукати інструменти замість того, щоб завантажувати всі одразу, Opus 4 підскочив з 49 до 74 відсотків на їхньому бенчмарку.

До 20 інструментів — тримайте їх завантаженими. Більше — переходьте на пошук.

Ще один трюк для великих задач: відправте сабагента. Він прочитає 50 файлів у своєму вікні й поверне вам резюме на одну сторінку. Ваш основний контекст бачитиме лише це резюме.

pic2. Що потрапляє в один виклик моделі

Шорткат

Viktor бере більшу частину цього на себе, бо його контекст живе на рівні компанії.

• Memory. Він зберігає постійну пам'ять про ваш бізнес для всієї команди. Те, що він дізнався від вашого кофаундера минулого тижня, сьогодні не треба копіювати у ваш запит.
• Connected sources. Коли підключені Notion, Google Drive або HubSpot, ви перестаєте вставляти файли в чат. Ви називаєте документ чи запис, а він читає джерело. Це правило "disk", реалізоване за вас.
• Skills. Ви один раз записуєте екран під час виконання задачі. Він перетворює запис на письмову процедуру, ви її виправляєте й затверджуєте. Далі ця інструкція зафіксована й перевірена, як хороший system prompt.

Що залишається на вашому боці:

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

2. Loop engineering

Визначення

Ви можете дати працівнику чеклист: відкрий файл, зміни 12-й рядок, збережи. Або можете дати мету: зроби так, щоб тест пройшов.

Маючи мету, він щось пробує, дивиться, що вийшло, і вирішує, що робити далі. Чеклист — це workflow. Мета — це loop.

Як це працює

Loop — це чотири рухи по колу: подумай, дій, спостерігай, виріши. Виправлення багу виглядає так:

1. Запустити тести. Три падають.
2. Прочитати першу помилку. Не вистачає імпорту.
3. Додати імпорт, запустити знову.
4. Один тест досі падає. Прочитати помилку, виправити, запустити знову.
5. Усе проходить. Стоп.

Ніхто не писав ці кроки заздалегідь. Модель обирала кожен із них, побачивши попередній результат.

У цьому вся різниця. Сотня кроків, яку написали ви — це все одно workflow. Три кроки, які обрала модель — це loop.

Використовуйте loop тільки тоді, коли не можете написати кроки заздалегідь. Якщо можете — пишіть. Workflow дешевший, працює паралельно, і якщо падає четвертий крок, ви перезапускаєте четвертий крок, а не все підряд.

Loops також дорогі. Агент витрачає приблизно вчетверо більше токенів, ніж один виклик. Мультиагентні сетапи — у п'ятнадцять разів.

Як це будувати

Loop потребує чотирьох частин. Заберіть будь-яку — і він перестане працювати:

1. Мета з чітким "готово". Не "виправ баг". А: "тест, що падає в auth_test.py, проходить, і нічого іншого не зламалося".
2. Checker. Щось поза моделлю, що каже pass або fail: набір тестів, компілятор, лінтер. Дослідження самокорекції тут одностайні: це працює з реальним зовнішнім фідбеком і ламається, коли модель просто перевіряє сама себе. Немає checker — немає loop, є лише неконтрольовані витрати.
3. Stop rule. Checker дав pass, або ви досягли ліміту кроків, або останні дві спроби дали однаковий результат.
4. Budget. І кроки, і долари.

У коді все це вміщується в кілька рядків:

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # готово
7    if repeated(history, 2):  break   # зайшли в глухий кут
8    if spent() > BUDGET:      break   # занадто дорого
9else:
10    fallback_workflow(goal)

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

Далі loop отримує максимум три цикли. Якщо після трьох упевненість досі нижче 50 відсотків, кермо перехоплює фіксований Python-workflow.

Спочатку фільтруй, потім короткий loop, і запасний варіант.

pic3. Як обрати між workflow і loop

Шорткат

Кожна задача, яку ви даєте Viktor у треді — це loop. Ви пишете мету, він обирає кроки, працює через ваші інструменти й повертається в тред із результатом.

Чотири частини мапяться так:

• Goal. Він сперечається з неповними брифами й перепитує, замість того щоб вгадувати. Але все одно пишіть, що означає "готово". "Звіт про дохід за минулий тиждень, суми збігаються зі Stripe, опубліковано в #finance до 9 ранку понеділка" краще, ніж "зроби звіт".
• Checker. Він позначає цифри, які виглядають дивно, ще до публікації. Зробіть це сильнішим, вказавши джерело для звірки: підсумок Stripe, кількість рядків, набір тестів.
• Stop rule. Чутливі дії ставляться на паузу для людини, а результат завжди повертається до вас.
• Budget. Кредити. Tier міркувань визначає ціну кожного кроку, а для регулярних задач важлива частота. Погодинний звіт коштує значно дорожче за щотижневий.

Гібрид від Atlan працює і без коду. Робота, що повторюється, стає запланованою задачею: він її пропонує, і вона залишається на паузі, поки ви її не схвалите. Це ваш workflow.

Усе, що не має чітких меж, іде в тред — і це ваш loop. Запасний варіант — ви.

3. Jev engineering

Визначення

Експерт в офісі не відкриває кожен конверт. Хтось на ресепшені сортує пошту: рахунки в одну купу, спам у кошик, контракти юристу.

Ваш агент виконує два типи роботи: щось писати і щось вирішувати. Зараз одна велика модель робить і те, і інше, тож ви платите юристу за сортування пошти.

Jev — це ресепшен. Він ніколи не пише. Він лише обирає.

Як це працює

Ви даєте Jev запитання й можливі відповіді заздалегідь. Він повертає одну з трьох речей плюс показник упевненості:

• так чи ні
• один варіант із набору
• число за шкалою

Оскільки він лише обирає, це швидко й дешево. Заявлені цифри — 70–500 мілісекунд проти 3–329 секунд, і $0.042 за мільйон вхідних токенів при безкоштовному виводі.

А тепер чесно. Jev існує два тижні, і незалежні тести лише починають з'являтися.

• На класифікації email звичайна логістична регресія показала 98.9 відсотка проти 98.6 у Jev.
• На виявленні фішингу Jev отримав 62.6 відсотка, тоді як Claude Haiku 4.5 — 81.3.
• Цифра "нуль галюцинацій" іде з власною виноскою авторів: вона не емпірична, а лише означає, що вивід завжди відповідає схемі.

Показник упевненості "з коробки" теж не є справжньою ймовірністю. Ставтеся до нього як до рейтингу й налаштовуйте пороги на власних розмічених даних.

Як це будувати

Розумний сетап — це ворота перед дорогою моделлю:

1. Заходить усе.
2. Jev відповідає на одне вузьке запитання щодо кожного елемента.
3. Впевнене й рутинне: обробляється дешево. Розмічене, маршрутизоване або відкинуте.
4. Невпевнене чи незвичне: йде в основну модель.

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # fail closed: невпевнене йде дорогим шляхом

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

Це тридцять хвилин роботи, і це той базовий рівень, який має перебити будь-яка заява вендора.

pic4. Три типи запитань, на які відповідає Jev

Шорткат

Jev не входить в опублікований стек Viktor, але ідея застосовується у двох місцях, які контролюєте ви:

• Tier міркувань. Він працює на трьох: Smart на Claude Opus, Balanced на Claude Sonnet (приблизно вдвічі дешевше), Ultra на Claude Fable (приблизно вдвічі дорожче). Сортування запитів чи витягування одного числа не потребує топового tier.
• Ворота перед ним. Якщо ви хочете, щоб він обробляв потік на кшталт листів підтримки чи алертів, не віддавайте йому весь потік. Спочатку поставте класифікатор або виклик Jev, щоб лише елементи, які потребують судження, ставали для нього задачами.

Це один із двох шарів, де ваша власна інженерія все ще має значення, навіть із Viktor.

4. Harness engineering

Визначення

Той самий працівник, два кабінети. У першому в нього правильні інструменти, інструкція на стіні, колега, який перевіряє його роботу, і немає ключа від сейфа. У другому — ноутбук і ваш адмінський пароль.

Навички ті самі, результати кардинально різні. Працівник — це модель. Кабінет — це harness.

Agent = model + harness.

Як це працює

Harness — це все, що не є моделлю: інструменти, доступи, пісочниця, файли, що пояснюють проєкт, перевірки виводу.

У 2026 році це стало окремою дисципліною, бо люди почали вимірювати, і модель пояснювала менше, ніж очікувалося:

• Anthropic змінили лише ресурси контейнера — і бал на бенчмарку зсунувся на 6 пунктів.
• LangChain заморозили модель і зсунули той самий бенчмарк на 13.7 пунктів, змінивши лише harness.
• Потім вони налаштували harness навколо відкритої моделі, яка вдесятеро дешевша, поки вона не набрала 0.86 проти 0.87 у Opus 4.8.

Ви більше не купуєте модель. Ви купуєте модель разом із harness.

Він потрібен вам тієї ж миті, коли агент торкається чогось реального: репозиторію, поштової скриньки, платежу, продакшен-бази.

Як це будувати

Будуйте ззовні всередину:

1. Containment. Те, до чого агент фізично не може дотягнутися. Контейнер, окрема гілка, read-only користувач бази, відсутність мережі окрім allowlist. Зробіть це до першого промпту.
2. Guides. Те, що направляє його до дії. Файл у репозиторії на кшталт AGENTS.md, описи інструментів, достатньо зрозумілі, щоб модель обрала правильний, кілька прикладів хорошого виводу.
3. Sensors. Те, що перевіряє його після дії. Лінтер, тайпчекер, набір тестів: швидкі й детерміновані, тому запускайте їх на всьому. Повільніші перевірки, як-от друга модель, що рев'юить diff — лише на тому, що справді важливо.
4. Permissions. Коли агенти просять підтвердження, люди погоджують у 93 відсотках випадків. Запит на апрув майже нічого не захищає. Справжній захист — це дії, які просто недоступні. Залиште апрув для кількох речей, які справді незворотні.

Файл-гід не обов'язково має бути довгим. Чотири рядки вже змінюють поведінку:

1# AGENTS.md
2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Run tests with `make test`. They must pass before any commit
4- Never edit /migrations by hand, use `make migration`
5- DB access is read only. Ask before any schema change

Хуки — це примусова версія тієї ж ідеї. У Claude Code хук — це маленький скрипт, який запускається перед викликом інструменту і може його заблокувати. "Ніколи не пушити в main" працює як хук, а не як рядок у промпті.

Одне попередження. Кожен елемент вашого harness — це ставка на те, що модель чогось не вміє, і ці ставки мають термін придатності. Anthropic видалили цілий компонент скафолдингу після того, як оновлення моделі зробило його непотрібним.

Перечитуйте свій harness кожні кілька місяців і видаляйте те, з чого модель уже виросла.

pic5. Чотири кільця harness

Шорткат

Якщо agent = model + harness, то більша частина того, що ви отримуєте з Viktor — це harness. Під капотом модель — Claude. Усе навколо моделі йде готовим:

• Tools. Понад 3 200 інтеграцій: GitHub, Linear, HubSpot, Stripe, Notion, Google Drive та інші. Для інструменту без готового з'єднання він може зібрати його сам.
• Guides. Skills. Замість того, щоб писати AGENTS.md самостійно, ви записуєте екран, він драфтить процедуру, ви її редагуєте.
• Sensors. Він позначає дані, які не сходяться, і ставить під сумнів брифи з пропущеними деталями. І кожен крок потрапляє в Slack-тред, який може прочитати ваша команда.
• Permissions. Листи клієнтів і фінансові зміни ставляться на паузу для підтвердження. Нові заплановані автоматизації залишаються на паузі, поки хтось їх не увімкне.

Те, що жоден продукт не зможе зібрати за вас — це containment, бо він складається з кредів, які ви передаєте. Пам'ятайте про 93 відсотки й підключайте його з мінімальним доступом, необхідним для роботи:

• read-only користувач бази
• обмежений ключ Stripe
• спільна скринька підтримки, а не ваша особиста
• GitHub-токен, обмежений конкретними репозиторіями

До чого він не може дотягнутися, те він не зламає.

pic6. Harness від Viktor

5. Evals engineering

Визначення

Як зрозуміти, що новачок став кращим? Ви даєте йому той самий тест, що й минулого місяця, і порівнюєте.

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

Як це працює

Є два типи перевірок:

• End to end. Чи правильною вийшла фінальна відповідь? Це каже, що бал змінився, але не каже чому.
• Behavioral. Чи сталася одна конкретна річ? Чи викликав він пошук перед відповіддю. Чи поставив уточнювальне запитання, коли запит був розмитим. Чи перевірив усе, перш ніж сказати "готово".

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

Якщо оцінює модель, це judge, і judge теж потребує перевірки. Airbnb виявили, що близько трьох чвертей їхніх згенерованих моделлю еталонних відповідей відрізнялися при повторних запусках на тому самому вході. Їхній eval вимірював власний шум.

Як це будувати

1. Починайте з реальних фейлів. Перегляньте реальні запуски, знайдіть, що пішло не так, перетворіть кожне на тест-кейс. "Золоті набори" Airbnb містять 50–100 прикладів, і наявність помилок там обов'язкова.
2. Пишіть одну поведінкову перевірку на кейс. Один кейс — одна річ для перевірки.
3. Перевіряйте свого judge. Оцініть вибірку вручну й подивіться, як часто ви збігаєтесь із моделлю, перш ніж їй довіряти.
4. Семплюйте продакшен. Airbnb щодня витягує 5 відсотків живого трафіку. Ваш набір evals деградує, коли реальне використання від нього віддаляється.

Один кейс може бути ось таким маленьким:

1input: "Refund order #1042, customer says it arrived broken"
2expect:
3  - looks up the order before replying
4  - asks for approval before issuing the refund
5check:
6  - trace has get_order before send_reply
7  - trace has approval_request before refund

Не слідкуйте за загальним відсотком проходження. Він може зростати, поки одна конкретна поведінка тихо ламається. Слідкуйте за окремими перевірки.

pic7. Звідки беруться хороші eval-кейси

Шорткат

Жоден продукт не зможе доставити цей шар за вас, бо лише ви знаєте, як виглядає правильна відповідь для вашого бізнесу. Але метод переноситься напряму:

• Через два тижні оберіть 20 його тредів, де ви знаєте правильну відповідь. Включіть кожен, де вам довелося його виправляти.
• Напишіть одну просту перевірку на кейс. Чи лінкував він джерело для кожної цифри, чи перепитував, коли бриф був розмитим, чи ставив на паузу перед тим, як щось вийшло за межі компанії.
• Перезапускайте набір після кожної зміни: нова skill, відредагований бриф, інший tier. Перехід зі Smart на Balanced економить приблизно половину кредитів, тому протестуйте це, перш ніж переключитися назавжди.
• Раз на тиждень оцінюйте п'ять випадкових тредів вручну.

Збираємо все разом

П'ять шарів, п'ять запитань. Context — це те, що він бачить. Loop — це те, хто вирішує. Jev бере на себе дешеві рішення. Harness — це те, до чого він може дотягнутися, і хто його перевіряє. Evals — це те, як ви це знаєте.

З Viktor три з них переважно вбудовані: context, loop і harness. Jev, evals і креде, які ви передаєте — залишаються вашою інженерією.

Якщо ви починаєте сьогодні, ось найдешевший корисний крок для кожного:

• Context: перенесіть стабільні інструкції в system prompt і перестаньте їх змінювати.
• Loop: поставте ліміт на кроки й ліміт у доларах, перш ніж залишати його працювати.
• Jev: розмітьте 200 прикладів того, що ваш агент вирішує найчастіше.
• Harness: запускайте агента як користувача, який не може нічого видалити.
• Evals: запишіть свої останні п'ять фейлів як тест-кейси.

З Viktor той самий день виглядає так:

• Context: напишіть бриф компанії й запишіть свою першу skill.
• Loop: додавайте визначення "готово" в кожну задачу й свідомо обирайте tier.
• Jev: фільтруйте будь-який потік, перш ніж він перетвориться на задачі для нього.
• Harness: підключайте його з read-only, обмеженими кредами.
• Evals: збережіть 20 реальних тредів як свій перший тестовий набір.

Це один день роботи, і він покриває всі п'ять.

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

Дякую Viktor за спонсорство цієї статті.

Спробуйте безкоштовно на @viktor_com. $100 у кредитах, без картки. Повне посилання в моїй першій відповіді.

Використовуйте код YARCHI100 при реєстрації.

Paid Partnership