Клієнта в цьому кейсі немає. Ламалося у нас, цифри — з робочої дошки.
Що саме працює
Grow2.ai веде контент-виробництво як мультиагентну систему на Paperclip: редактор ставить задачі, автор пише майстер-матеріал, дистриб'ютор адаптує під платформи, публікатор викладає, окремий агент збирає метрики. Схожу конфігурацію ми розбирали в кейсі про чотирьох агентів у менеджменті — тут та сама логіка, тільки застосована до власного контенту. Кожен етап — окремий агент з власним контекстом, власним запуском і власною задачею на дошці. Перехід між етапами формалізований через статус задачі та blocker-залежність: агент закриває свою задачу в done, і це будить наступного.
Масштаб на 13 серпня 2026 року: дошка веде наскрізну нумерацію від AUSA-14 до AUSA-2417, перша задача створена 12 березня. У контент-частині 165 матеріалів, з них 82 опубліковані. П'яти місяців вистачило, щоб побачити, що саме ламається насправді.
Головне спостереження: агенти не падали
Очікування було таке, що проблеми будуть усередині агентів. Галюцинації, зіпсований JSON, агент неправильно зрозумів задачу, агент зациклився. Такі речі траплялися, вони дешеві та помітні: агент пише коментар, ти читаєш і виправляєш — і саме під них будується звична обв'язка захисту.
Дорогі збої виглядали інакше. Агент відпрацьовував успішно, звітував успішно, закривав задачу успішно — і робота зникала. Не втрачалася в сенсі видалення файлу, а ставала невидимою для наступного етапу. Матеріал лежить на диску, задача закрита, всі метрики зелені, публікації немає.
Три патерни нижче — найдорожчі з тих, що ми знайшли; найдовший тримався 24 дні. Спільне в них не технологія, а те, що жоден не діагностується перевіркою «чи працює агент».
Патерн 1: схвалений матеріал, який ніколи не вийшов
Апрув у нас проходить через Telegram: приходить картка з матеріалом, користувач натискає «Approve», сервіс-шлюз ловить рішення й створює задачу на публікацію.
Далі був баг припущення. Шлюз створював дочірню задачу «опублікувати», але саму задачу-апрув у done не переводив — у нього банально не вистачало прав на чужу задачу. А наступний етап, який щоранку шукає, що сьогодні публікувати, гейтив публікацію саме за статусом апруву: done чи ні. Апрув залишався в in_review, через сім робочих днів політика застарілих задач зсувала його в backlog, і матеріал ставав невидимим назавжди.
Стан на момент, коли ми це знайшли (скан 9 липня 2026, 2010 задач на дошці):
Показник | Значення |
|---|---|
Задач на публікацію, створених шлюзом з 12 березня по 9 липня | 82 |
З них апрув не в | 34 |
— застрягли в | 18 |
— висіли в | 15 |
— у | 1 |
Тобто 34 матеріали були схвалені живою людиною й одночасно невидимі для системи. Найнеприємніша підгрупа — ті 18 у backlog: політика застарілості справно позначала їх як «висить без рішення понад тиждень», хоча рішення було прийняте в перший день. Система звітувала протилежне тому, що сталося.
Полагодили так: закриття апруву стало окремим кроком редактора у щоденному прогоні. Скан усіх задач на публікацію з маркером апруву, і якщо батьківський апрув не закритий — закрити. Квитанцією апруву вважається сама наявність дочірньої задачі на публікацію.
Якщо квитанція про рішення пишеться одним компонентом, а читається іншим, перевіряти треба не те, що компонент відпрацював, а те, що квитанція справді з'явилася там, де її шукатимуть.
Патерн 2: мовчазний агент — це зламаний рушій, а не доступи
У публікатора був справжній, задокументований блокер: частина токенів соцмереж мертва. Задача на розблокування доступів висіла з червня.
Тому коли задачі на публікацію перестали рухатися, діагноз здавався очевидним. Задачі AUSA-2084 і AUSA-2085 створені 13 липня, стоять у todo, публікацій немає, у публікатора немає токенів — причина знайдена, чекаємо доступів.
Правильна відповідь знайшлася 6 серпня, через 24 дні. У тих задачах було нуль коментарів.
Агент, який упирається у відсутні доступи, залишає коментар: перелічує платформи, які відвалилися, і зупиняється. Агент, який не залишив жодного коментаря, не запускався взагалі. Ламався не доступ, а рушій сесії — агент падав на ініціалізації, до того, як побачити задачу. Лікування виявилося не в токенах, а в конфігурації моделі; після переводу агентів на нову модель публікатор того ж дня опублікував матеріал. Те, що поведінка агента залежить не тільки від промпта, а й від обв'язки навколо нього, ми розбирали окремо — чому той самий AI-агент дає різні результати.
Перш ніж списати застій на відомий блокер, відкрий задачу й подивись, чи є там коментар агента. Немає коментаря — лагодь запуск, а не інтеграцію. Різницю між «агент спробував і не зміг» та «агент не прокинувся» на дошці не видно ніяк, а коштувала вона двадцяти чотирьох днів.
Нюанс, який ми теж не знали: публікатор прокидається на створення задачі, а старі задачі в todo не перевикликає сам. Після полагодження рушія їх треба будити явно.
Патерн 3: фільтр, який відсіює своїх
Щоденна перевірка «що публікуємо сьогодні» відбирає матеріали умовою дата публікації == сьогодні. Строга рівність тут не випадкова: послаблення до <= сьогодні призводить до того, що матеріал із минулою датою й уже закритою задачею на публікацію отримує нову задачу щоранку, а створення задач не ідемпотентне. Дублі щодня — гірше, ніж пропуск.
Наслідок, який із цього правила не випливає очевидно: матеріал без поля дати не збігається з сьогоднішнім числом ніколи. Він невидимий безстроково — і при цьому може бути повністю готовим, з заповненими адаптаціями під платформи та реальним апрувом.
10 серпня таких матеріалів було 32. Розбір за станом апруву показав, що «32 втрачені» — неточне формулювання, і різні підгрупи лікуються по-різному:
Підгрупа | Кількість | Що це означає |
|---|---|---|
Апрув у | 19 | Схвалено користувачем, не вийде ніколи — лікується датами |
Апрув | 2 | Потребує ручного рішення |
Апрув у | 2 | Потребує ручного рішення |
Немає посилання на апрув | 9 | Інший дефект, лікується процедурою пошуку «сиріт» |
На 13 серпня без дати залишається 26 матеріалів: 17 із посиланням на апрув і 9 без нього.
Це не помилка коду. Умова написана рівно так, як задумано, і послабити її не можна. Помилка в припущенні, що дата завжди є, — а поле необов'язкове, і матеріал може дійти до готовності без нього.
Поруч жив ще один дефект тієї ж природи, і коштував окремого дня. Ті самі скани спочатку були написані як обхід теки поточного місяця. Тека — це місяць створення матеріалу, а дата у файлі — місяць публікації, і розходяться вони регулярно. Скан за серпневою текою чесно рапортував «публікувати нічого», поки два готові матеріали з датою на сьогодні лежали в липневій.
Що спільного в трьох патернах
- У першому — шлюз зробив рівно те, на що мав права, а квитанція про рішення не з'явилася там, де її читали.
- У другому — агент не існував як процес, але його статус на дошці був валідним станом «до роботи», не відрізнити від «чекає своєї черги».
- У третьому — фільтр коректно відсіяв усе, що не збігається з умовою, включно з тим, що мало пройти.
Спільний знаменник: агент, який відзвітував про успіх, і робота, яка дійшла до наступного етапу, — це дві різні події. Моніторинг, який перевіряє першу, нічого не знає про другу.
Це формулювання не наше відкриття. Робота Why Do Multi-Agent LLM Systems Fail? (Cemri та ін., NeurIPS 2025) розібрала понад 1600 анотованих трас виконання з семи популярних мультиагентних фреймворків і побудувала таксономію MAST — 14 режимів відмови в трьох категоріях. Одна з трьох категорій — inter-agent misalignment, тобто збій передачі критичної інформації між агентами, а не всередині них. Частота відмов у розібраних фреймворках склала від 41% до 86,7%. Наші три патерни лягають рівно в цю категорію, і те, що вони відтворилися на власному стеку без знайомства з цією таксономією, — радше підтвердження, ніж збіг.
Що моніторити на стиках
Практичний мінімум, до якого ми прийшли. Це не універсальний фреймворк, а те, що закриває наші три патерни.
Перевіряти артефакт, а не статус. Після написання має з'явитися файл, після публікації — URL або ID запису на платформі. Задача в done не доводить, що робота відбулася: наш публікатор чесно закриває задачу в done і тоді, коли пропускає матеріал за датою.
Тиша агента — окремий стан. Задача призначена, минула доба, коментарів нуль — це не «в роботі», це «не запустився». На дошці обидва виглядають однаково, тож розрізняти доводиться явно.
Строгі фільтри мають рапортувати відсів: не тільки що пройшло далі, а й скільки не пройшло і чому. Фільтр дата == сьогодні, який мовчки викидає 26 готових матеріалів, звітує як «сьогодні публікувати нічого».
І окремо — те, що не про код взагалі. Найдорожча з трьох помилок технічною не була: двадцять чотири дні ми будували план навколо правдоподібного пояснення, замість витратити один запит на його перевірку. Відомий блокер у системі — зручна відповідь, до якої симптоми липнуть самі. Це стосується й власних учорашніх висновків, що ми теж перевірили на собі: премісу «закривати апруви батчем не можна, будуть дублі» ми возили в голові тиждень, поки скан не показав, що дублів не буде жодного.
Чесна межа цього матеріалу
Тут немає клієнтських результатів і немає стверджень про те, що це універсально. Це п'ять місяців роботи однієї системи — 18 агентів на одній платформі оркестрації, з них п'ять у контент-ланцюжку. Три патерни — те, що ми знайшли у себе, а не вичерпний перелік режимів відмови; MAST налічує чотирнадцять.
Grow2.ai будує кастомних AI-агентів під процес клієнта, і публікувати список власних поломок — трохи незручний спосіб про це говорити. Але порада «моніторте переходи, а не агентів» без трьох конкретних історій, де ми цього не робили, коштувала б рівно нічого.
Як ми будуємо агентів і де проводимо межу між тим, що варто автоматизувати, а що ні — на grow2.ai.