> For the complete documentation index, see [llms.txt](https://kotovich.gitbook.io/ua/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kotovich.gitbook.io/ua/3-shari-ai-agentiv-yaki-vsi-plutayut.md). # 3 шари AI-агентів, які всі плутають Agent Harness Engineering vs Loop Engineering vs Graph Engineering: три шари, які всі плутають + 2 відео-курси від Google Більшість людей говорять про AI-агентів так, ніби це одна річ.\ Це не так. Коли агент виходить за межі іграшкового демо і починає чіпати файли, API, документи, клієнтів чи продакшн-код — ви вже не просто «промптите модель».\ Ви проєктуєте систему. І в цій системі три ідеї постійно змішують: * **Agent harness engineering** * **Loop engineering** * **Graph engineering** Вони всі крутяться навколо однієї моделі.\ Вони всі впливають на надійність.\ І так — у всіх можуть бути цикли. Але вони вирішують **різні проблеми**. Якщо їх змішати — ви почнете дебажити не той шар. #### 30-секундна відповідь Ось чиста версія: * **Harness engineering** будує середовище навколо моделі * **Loop engineering** проєктує повторюваний цикл «робота → зворотний зв’язок» * **Graph engineering** робить топологію workflow явною Проста ментальна модель: **Середовище → Зворотний зв’язок → Потік** * Harness дає моделі інструменти, пам’ять, контроль і робочий простір * Loop вирішує, як роботу повторювати, перевіряти і покращувати * Graph визначає, який крок дозволений наступним Ось і вся різниця. #### Чому ці терміни важливі саме зараз Сира модель сама по собі не може виконувати реальну роботу.\ Вона не вміє: * зберігати стан проєкту між сесіями * безпечно викликати інструменти * дивитися в браузер * контролювати дозволи * повторювати невдалі спроби * перевіряти якість результату * розподіляти задачі між спеціалістами * зупинятися в потрібний момент Усе це дає система навколо моделі. Коли агентне ПЗ дорослішає, формується практичний стек: 1. Harness дає моделі умови роботи 2. Loops роблять роботу повторюваною і перевірюваною 3. Graph робить складні workflow явними і керованими Як тільки ви бачите ці три шари окремо — більшість плутанини в архітектурі AI зникає. #### 1. Що зазвичай входить у серйозний harness **1. Context Injection**\ Що модель бачить перед дією:\ інструкції, retrieved knowledge, стан розмови, пам’ять, політики, task-specific правила. **2. Action Surfaces**\ Що модель може робити:\ API-виклики, дії в браузері, shell-команди, виконання коду, MCP-інструменти, бази даних, кастомні функції. **3. Persistence**\ Що зберігається в часі:\ файли, чекпоінти, стан сесії, логи прогресу, git-історія, довгострокова пам’ять. **4. Execution Control**\ Як керується запуск:\ ретраї, таймаути, бюджети, вибір моделі, створення субагентів, approval gates. **5. Safety And Governance**\ Що тримає систему в безпеці:\ least-privilege дозволи, ізоляція, allowlists, робота з секретами, human approval. **6. Observability**\ Що дозволяє дебажити:\ трейси, входи/виходи інструментів, переходи стану, latency, вартість, результати eval. #### Чому harness engineering критично важливий Дві команди можуть використовувати **одну і ту саму модель** і отримувати абсолютно різні результати. Чому? Одна дає моделі:\ чисті інструменти, стабільний стан, структуровану пам’ять, чіткі дозволи, спостережувану роботу. Друга дає:\ розмитий промпт, брудні інструменти, шумний контекст, відсутність пам’яті, відсутність верифікації. Модель однакова.\ Умови роботи — ні. Harness engineering потрібен, коли агент:\ не має доступу до потрібної можливості, втрачає контекст між сесіями, поводиться непослідовно, не піддається аудиту, має занадто багато прав або не може чисто відновитися після переривання. Якщо модель не може надійно працювати — **перше місце, куди дивитися, — harness**. #### 2. Loop Engineering Кожен агент, який використовує інструменти, вже має маленький вбудований цикл: виклик моделі → спостереження результату → запуск інструментів → повернення спостережень → повтор до завершення. **Loop engineering** починається тоді, коли ви **свідомо** проєктуєте додаткові цикли навколо цієї поведінки. Не просто «спитай ще раз».\ Не просто «retry». А справжня система «робота + зворотний зв’язок». **Анатомія хорошого циклу** * **Trigger** — що запускає новий цикл (запит користувача, failed test, новий документ, scheduled run, webhook, feedback від evaluator) * **Goal** — конкретна умова, яку треба досягти (не «просто покращувати») * **State** — що потрібно знати наступному циклу * **Action Policy** — що агенту дозволено робити * **Evidence** — як ми дізнаємося, що спрацювало (тести, schema validation, citations, diffs, метрики, approval) * **Feedback** — що саме пішло не так (компактно і actionably) * **Stop Rule** — коли зупинятися (успіх, timeout, budget, max retries, irrecoverable failure, escalation до людини) **Найважливіший принцип** **Не зациклюйтеся на confidence.**\ **Зациклюйтеся на evidence.** «Агент каже, що він закінчив» — це не stop condition.\ Справжній stop condition виглядає так: * тести пройшли * схема валідується * citations резолвляться * reviewer схвалив * policy check чистий Це і є loop engineering. Промпт каже моделі, що робити **під час** виклику.\ Цикл визначає, що система робить **після** виклику. Промптинг покращує відповідь.\ Цикл покращує процес. #### 3. Graph Engineering Graph engineering робить структуру workflow явною. Він відповідає на інше питання:\ не «що агент має робити?»,\ а «що дозволено статися наступним?». У graph engineering: * кроки = nodes * переходи = edges * branching явний * parallel work явний * joins явні * retries явні * human interrupts явні Граф стає control map системи. **Що саме проєктують graph-інженери** * Межі nodes (детермінована функція / LLM-виклик / спеціаліст / human review) * State schema (що кожен node може читати/писати) * Routing conditions (коли йти вперед, назад, вбік або на escalation) * Concurrency (що може йти паралельно) * Cycles і exits (де дозволені retries і як вони зупиняються) * Durability (де чекпоінти і як відновлюватися після переривання) Графи корисні, коли є: * meaningful branching * approvals * handoffs між спеціалістами * parallel work * recovery paths * multi-step workflows з явними control points Вони менш потрібні, коли задача проста:\ «Дай одному агенту кілька інструментів і хай працює». У такому випадку солідний harness + кілька loops часто вистачає.\ Граф додає ясність, але також додає структуру.\ Занадто багато структури занадто рано робить систему крихкою. #### Як три шари працюють разом Уявіть research-and-publishing агента, який має: * окреслити тему * зібрати джерела * перевірити citations * написати чернетку * пройти legal review * опублікувати тільки після approval **Harness** дає:\ доступ до браузера, search tools, file workspace, пам’ять, citations, approvals, traces, routing моделей. **Loop** відповідає за:\ повторний збір джерел, коли evidence слабкий; виправлення citation failures; grader checks; оновлення роботи при зміні ринку. **Graph** контролює шлях:\ scoping → research → screening → synthesis → drafting → review → publication\ (з human gate перед релізом). Тому три шари **не взаємозамінні**.\ Вони працюють разом, але це різні речі. #### Діагностуйте failure перед тим, як вибирати fix Практичне правило: * Якщо агент **взагалі не може працювати** → фіксіть **harness**\ (немає інструменту, stale state, слабка пам’ять, погані дозволи, немає observability) * Якщо агент **майже працює, але ненадійно** → фіксіть **loop**\ (перша чернетка близька, але слабка; success непослідовний; retries неконтрольовані; немає доказу завершення) * Якщо **сам процес складний** → фіксіть **graph**\ (багато спеціалістів, approvals, branching, parallel paths, structured handoffs) #### Найпоширеніші помилки 1. **Будувати граф занадто рано**\ Спочатку зробіть простіший harness, зберіть traces, знайдіть стабільні патерни — і тільки потім формалізуйте те, що справді потребує контролю. 2. **Давати одній і тій самій моделі і писати, і оцінювати без safeguards**\ Self-review допомагає, але має ті самі сліпі зони. Краще deterministic checks + окремий reviewer context + external evaluators + human approval для high-impact дій. 3. **Використовувати «просто пробуй далі» як цикл**\ Це не design циклу. Це неконтрольований витік грошей.\ Кожен цикл потребує measurable goal, real evidence, лімітів retries і правил escalation. 4. **Перетворювати harness на смітник**\ Більше інструментів ≠ кращі агенти. Занадто багато інструментів створює помилки вибору, шумний контекст, слабку надійність і ширшу surface ризику. Хороший harness — точний, а не перевантажений. 5. **Звинувачувати модель в orchestration failures**\ Модель не компенсує зламані API, stale state, відсутність exit conditions, розмиті tool schemas і невидимі failure modes.\ Фіксіть шар, якому належить failure. #### Простий production-чеклист **Harness**\ Чи інструменти вузькі і задокументовані? Чи стан durable? Чи дозволи least-privilege? Чи можна pause / inspect / resume? Чи трейси видимі? **Loop**\ Яке evidence доводить success? Який feedback повертається при failure? Скільки retries дозволено? Яке stop rule? Що відбувається, коли budget закінчується? **Graph**\ Які шляхи мають бути детермінованими? Що може йти паралельно? Де human gates? Який state shared? Де починаються recovery paths? **Evaluation & Operations**\ Чи можете replay real traces? Порівнювати версії? Відстежувати cost, latency, failure rate, intervention rate і task success у продакшені? #### Найпростіший спосіб запам’ятати різницю Якщо запам’ятаєте лише одне: * **Harness engineering** робить модель **операційною** * **Loop engineering** робить роботу **ітеративною і перевірюваною** * **Graph engineering** робить шлях виконання **явним і контрольованим** Жоден не замінює інші. Ідеальний граф не врятує слабкий harness.\ Сильний harness все одно зливатиме гроші без хороших loops.\ А чисті loops стають важкими в управлінні, коли branching і approvals ховаються в ad-hoc коді. Надійні agent-системи з’являються тоді, коли **всі три шари** спроєктовані навмисно. Це і є справжній architectural stack. #### Фінальний takeaway Люди досі говорять про AI-агентів так, ніби breakthrough — це модель. У продакшені це рідко буває справжнім диференціатором. Справжній диференціатор — система навколо моделі: * harness, який дозволяє їй працювати * loops, які дозволяють їй покращуватися * graph, який дозволяє їй працювати під контролем Саме так іграшкові агенти стають реальними системами. #### Схеми **1. Три шари (високий рівень)** ``` ┌─────────────────────────────────────┐ │ GRAPH (Потік) │ │ Явна топологія: nodes + edges │ │ Що може статися далі │ └──────────────────┬──────────────────┘ │ ┌──────────────────▼──────────────────┐ │ LOOP (Зворотний зв’язок) │ │ Цикл: дія → evidence → feedback │ │ Як повторювати і перевіряти │ └──────────────────┬──────────────────┘ │ ┌──────────────────▼──────────────────┐ │ HARNESS (Середовище) │ │ Інструменти + пам’ять + контроль │ │ + safety + observability │ └─────────────────────────────────────┘ │ ▼ [ LLM / Модель ] ``` **2. Як працює хороший Loop** ``` Trigger │ ▼ ┌─────────────┐ │ Goal │ ← конкретна ціль └──────┬──────┘ │ ▼ ┌─────────────┐ ┌──────────────┐ │ State │────▶│ Action Policy│ └──────┬──────┘ └──────┬───────┘ │ │ ▼ ▼ ┌─────────────┐ ┌──────────────┐ │ Action │────▶│ Evidence │ └──────┬──────┘ └──────┬───────┘ │ │ └───────Feedback────┘ │ ▼ Stop Rule? / \ Yes No → новий цикл │ ▼ Кінець ``` **3. Приклад Graph (research-and-publish)** ``` [Scoping] ──▶ [Research] ──▶ [Screening] │ ▼ [Synthesis] │ ▼ [Drafting] ──▶ [Legal Review] │ ┌─────────┴─────────┐ │ │ Approve Reject │ │ ▼ ▼ [Publish] [Rewrite Loop] ``` **4. Діагностика збою** ``` Агент не працює взагалі? │ ▼ Так → Фіксіть HARNESS Агент майже працює, але нестабільно? │ ▼ Так → Фіксіть LOOP Процес складний (багато кроків, approvals, specialists)? │ ▼ Так → Фіксіть GRAPH ``` Ось і весь стек.\ Модель — це двигун.\ Але різницю в продакшені робить система навколо нього. *** Відео курс 1: Як зробити і монетизувати {% embed url="" %} *** Відео курс 2: Якщо вже працюєте з AI-агентами {% embed url="" %}