У світі AI‑розробки всі говорять про мультиагентні системи, але майже ніхто не може чітко пояснити, як їх будувати так, щоб вони справді працювали в бойових умовах. Люк Алвоейро, який очолює core agent harness у Factory (компанії з місією принести автономію в увесь життєвий цикл розробки ПЗ), пропонує просту, але амбітну відповідь: таксономію з п’яти базових стратегій взаємодії агентів.
Ця рамка народилася не в лабораторії, а на практиці — на спробах змусити агентні команди тижнями писати, тестувати й перевіряти реальний код. І її головна обіцянка звучить різко: правильно скомпоновані агентні стратегії дозволяють виконувати завдання на порядки складніші, ніж ті, з якими сьогодні справляється одинокий «розумний» агент у чаті.
Вузьке місце розробки: не інтелект, а увага
Сучасні великі мовні моделі вже здатні розібратися з десятками фіч у беклозі — принаймні на рівні розуміння вимог, архітектури й можливих рішень. Проблема в іншому: людська увага не масштабується. Навіть найсильніший інженер одночасно тягне лише кілька задач, кожен коміт потребує рев’ю, кожна зміна — контексту.
Це створює дивний дисбаланс. Моделі вже досить «розумні», щоб планувати й реалізовувати великі шматки роботи, але немає достатньо людського часу, щоб їх постійно супервізувати. Виникає природне запитання: що, якщо людина визначає, що саме потрібно побудувати, а система сама розбирається, як це зробити — працюючи годинами або днями без безперервної участі розробника?
Саме тут мультиагентні системи стають не модною іграшкою, а потенційною відповіддю на структурне обмеження індустрії. Але є проблема: галузь експериментує хаотично. Кожен будує власний фреймворк, вводить власні терміни, демонструє ефектні демо, але спільного розуміння, які патерни справді масштабуються, немає.
Таксономія, яку пропонує Алвоейро, — це спроба навести лад у цьому хаосі й виділити п’ять базових «будівельних блоків» для мультиагентних систем, орієнтованих саме на складні софтверні воркфлови.
П’ять стратегій: фундамент мультиагентних систем
Запропонована рамка описує п’ять «фронтирних» стратегій взаємодії агентів: делегація, creator‑verifier, пряма комунікація, переговори та широкомовлення (broadcast). Ідея не в тому, що це всі можливі способи координації, а в тому, що саме ці п’ять на практиці виявляються ключовими для побудови стійких команд агентів у розробці ПЗ.
Делегація: базовий інструмент масштабування
Делегація — найпростіша й найінтуїтивніша стратегія. Один агент породжує іншого, передає йому підзадачу й чекає на результат. У розробці це виглядає, наприклад, як «головний» агент, що планує фічу, і «дочірній», якому доручають «розберися зі схемою бази даних» або «згенеруй REST‑ендпоінти для цього ресурсу».
Саме делегація зазвичай з’являється першою в інструментах типу «AI‑кодер»: головний агент викликає «субагентів» для тестів, документації, рефакторингу. Це дає відчутний приріст продуктивності, але швидко впирається в межі: без чіткої структури делегування агенти починають дублювати роботу, втрачати контекст і породжувати хаос.
У таксономії Алвоейро делегація — це лише фундамент, на який накладаються складніші патерни.
Creator‑verifier: розведення ролей і боротьба з «упередженістю автора»
Друга стратегія — creator‑verifier — формалізує те, що давно роблять люди: розділення створення й перевірки. Один агент щось будує (код, тести, міграції), інший — незалежно перевіряє результат.
Ключовий момент тут — усвідомлення «упередженості автора». Агент, який писав код, за визначенням зацікавлений у тому, щоб він «працював»: він пам’ятає свої рішення, раціоналізує компроміси й підсвідомо формує тести так, щоб підтвердити обрану реалізацію. Якщо тести пишуться після коду й тим самим агентом, вони часто лише фіксують уже прийняті рішення, а не ставлять під сумнів їхню правильність.
У людських командах це вирішується код‑рев’ю: свіжий погляд, інший досвід, інші інтуїції. У мультиагентних системах creator‑verifier відтворює цей патерн: верифікатор отримує завдання перевірити результат, не будучи «емоційно» чи контекстно прив’язаним до реалізації.
У софтверних воркфловах це особливо важливо, коли мова йде не лише про синтаксис і тести, а про відповідність бізнес‑логіці, UX‑очікуванням і неявним обмеженням системи.
Пряма комунікація: сила й небезпека «чатів між агентами»
Третя стратегія — пряма комунікація — описує ситуацію, коли агенти спілкуються один з одним без центрального координатора. Це схоже на груповий чат розробників: хтось уточнює деталі API, хтось ділиться знахідкою в коді, хтось просить поради щодо архітектури.
На перший погляд, це природний спосіб зробити систему «більш живою» й гнучкою. Але саме тут ховається одна з головних пасток мультиагентних підходів: фрагментація стану.
Без єдиного джерела правди знання розповзаються по приватних «діалогах» між агентами. Різні частини системи починають оперувати різними версіями реальності: один агент вважає, що ендпоінт повертає одне поле, інший — інше; один думає, що фіча вже реалізована, інший — що вона ще в роботі.
У невеликих демо це може зійти з рук, але в довгих місіях зі складною кодовою базою пряма комунікація без продуманої координації швидко перетворюється на джерело важковловимих багів. Тому в таксономії Алвоейро ця стратегія розглядається як потужний, але небезпечний інструмент, який вимагає обережного застосування.
Переговори: спільні ресурси без війни
Четверта стратегія — переговори — описує взаємодію агентів навколо спільного ресурсу. У розробці такими ресурсами можуть бути API, модулі, файли, таблиці в базі даних, навіть часові слоти деплою.
Інтуїтивно переговори часто сприймаються як конфлікт: агенти «змагаються» за право змінити один і той самий файл або використати один і той самий ендпоінт. Але в продуктивних мультиагентних системах переговори радше нагадують торг у позитивній сумі: агенти шукають win‑win‑комбінації, де координація дає виграш усім учасникам.
Наприклад, один агент може погодитися змінити свій план, щоб використати вже існуючий модуль, який розширює інший агент, замість того щоб дублювати функціональність. Або кілька агентів домовляються про єдину схему подій, щоб аналітика, логування й бізнес‑логіка не роз’їхалися.
У складних софтверних воркфловах, де багато частин системи взаємозалежні, переговори стають критичною стратегією: без них агенти неминуче починають «наступати один одному на ноги».
Broadcast: непомітний клей довгих місій
П’ята стратегія — broadcast — найменш ефектна, але, можливо, найважливіша для довготривалих місій. Це широкомовлення: коли один агент розсилає інформацію багатьом іншим.
У людських командах це виглядає як статус‑апдейти, RFC, зміни в документації, оголошення про нові обмеження чи бізнес‑пріоритети. У мультиагентних системах broadcast виконує ту саму роль: підтримує спільний контекст, синхронізує розуміння цілей, фіксує нові факти, які мають знати всі.
Без широкомовлення довгі місії неминуче «дрейфують»: нові агенти не знають про важливі рішення, старі — працюють за застарілими припущеннями, а система в цілому втрачає когерентність. Саме тому, попри відсутність «вау‑ефекту», broadcast у таксономії Алвоейро описується як критичний механізм для підтримки цілісності багатоденних процесів.
Від патернів до системи: як ці стратегії складаються в бойову архітектуру
Самих по собі п’яти стратегій недостатньо. Їхня сила проявляється лише тоді, коли вони скомпоновані в цілісну архітектуру. У Factory цю ідею втілили в системі Missions — мультиагентному середовищі, яке поєднує делегацію, creator‑verifier, broadcast і переговори в одному воркфлоу для розробки ПЗ.
Missions побудована навколо трьох ролей: оркестратор, воркери й валідатори. Оркестратор спілкується з людиною, уточнює вимоги, ставить стратегічні запитання й формує план: перелік фіч, мільстоуни та так званий «контракт валідації».
Саме контракт валідації — один із ключових елементів, який демонструє, як таксономія стратегій перетворюється на практичну інженерію. Він визначає, що означає «готово» для проєкту, ще до того, як буде написано перший рядок коду. Для складних задач це можуть бути сотні тверджень, які описують очікувану поведінку системи. Кожна фіча прив’язується до одного чи кількох таких тверджень, а сума реалізованих фіч має покрити весь контракт.
Це радикально відрізняється від звичної практики, коли тести й критерії приймання формуються «по дорозі» або постфактум. У мультиагентному середовищі, яке працює днями без безперервної людської уваги, така розмитість неминуче веде до дрейфу: агенти пишуть тести, які підтверджують їхній код, а не бізнес‑очікування.
Воркери в Missions реалізують фічі, працюючи з «чистим» контекстом: кожен новий воркер отримує актуальний код із Git, специфікацію своєї задачі й не несе на собі «втому» попередніх сесій. Після завершення роботи він не просто комітить зміни, а формує структурований хендов: що зроблено, що залишилося, які команди запускалися, з якими кодами виходу, які проблеми виявлено й чи дотримано процедур, визначених оркестратором.
Ці структуровані хендови — практичне втілення broadcast і делегації: вони створюють спільний, формалізований стан, який можуть споживати наступні агенти, не покладаючись на «пам’ять» попередників.
Валідатори в Missions реалізують стратегію creator‑verifier у максимально жорсткому варіанті. Їх два типи. Scrutiny‑валідатор запускає тестовий набір, тайпчекінг, лінтери й породжує окремих агентів‑рев’юерів для кожної завершеної фічі. User testing‑валідатор поводиться як QA‑інженер: піднімає живий застосунок, взаємодіє з ним через «комп’ютерне використання», заповнює форми, клікає кнопки, перевіряє цілісні користувацькі флоу.
Принципово важливо, що жоден із валідаторів не бачить коду до моменту перевірки. Вони не «вростають» у реалізацію, не підлаштовують свої очікування під уже написаний код і тому можуть діяти по‑справжньому «адверсаріально» — шукати невідповідності контракту валідації, а не підтверджувати зроблене.
Помилки фіксуються на межах мільстоунів, а коригувальні роботи оформлюються як нові фічі. Таким чином, система не покладається на те, що агенти «згадають» про проблеми, а примушує їх формально описати й відпрацювати.
Чому композиція стратегій дозволяє братися за задачі «на порядки важчі»
Ключова теза Алвоейро полягає в тому, що не окремі стратегії, а саме їхня композиція в продуману архітектуру відкриває можливість виконувати задачі, які значно перевищують можливості одиночного агента.
Один агент, навіть дуже потужний, завжди працює в межах власного контекстного вікна, власної «уваги» й власних упереджень. Він може планувати, писати код, тестувати й навіть частково себе перевіряти, але в довгих, багатокрокових процесах неминуче накопичує помилки, втрачає деталі й «залипає» в локальних рішеннях.
Композиція п’яти стратегій змінює саму структуру процесу:
делегація дозволяє розбивати великі задачі на підзадачі й розподіляти їх між спеціалізованими агентами;
creator‑verifier забезпечує системну «другу думку» на кожному важливому етапі, розриваючи цикл самопідтвердження;
пряма комунікація (там, де вона контрольовано застосовується) дає гнучкість і можливість локальної координації без перевантаження центрального оркестратора;
переговори дозволяють агентам узгоджувати зміни в спільних ресурсах, мінімізуючи конфлікти й дублювання роботи;
broadcast підтримує єдиний контекст і спільне розуміння цілей упродовж багатьох днів.
У результаті система набуває властивостей, яких не має жоден окремий агент: стійкість до дрейфу, здатність до самокорекції на мільстоун‑рівні, можливість працювати серіями невеликих, але узгоджених кроків.
Factory повідомляє, що найдовша місія в такій архітектурі тривала 16 днів — довше за типовий спринт — і команда вважає реалістичним горизонт у 30 днів. Це не просто «довга сесія чату», а автономний процес, який живе за власними правилами, фіксує стан, перевіряє себе й повертається на курс, коли щось іде не так.
Цікаво, що в такій конфігурації швидкість генерації токенів виявляється другорядною. Значна частина «стіни часу» місій витрачається не на обчислення, а на реальну взаємодію з живими застосунками під час користувацького тестування. Тобто вузьким місцем стає не LLM, а саме середовище виконання — ще один натяк на те, що інтелект моделей уже не головний лімітуючий фактор.
Серійність проти паралелізму: чому «повільніше» означає «швидше» на довгій дистанції
Інтуїтивна реакція на мультиагентні системи — спробувати паралелізувати все, що можна. Якщо є десять агентів, нехай усі десять одночасно пишуть код, тестують, рефакторять. На папері це обіцяє десятикратний приріст пропускної здатності.
Практика в софтверному домені виявилася іншою. Коли багато агентів одночасно змінюють одну кодову базу, вони неминуче конфліктують: перезаписують зміни один одного, приймають несумісні архітектурні рішення, дублюють фічі. Координаційні витрати — злиття гілок, розрулювання конфліктів, узгодження контрактів — з’їдають очікуваний виграш у швидкості, при цьому токени продовжують спалюватися.
Missions робить ставку на іншу стратегію: серійне виконання фіч. У будь‑який момент часу активний лише один воркер або один валідатор. Паралелізм дозволений, але лише всередині окремої задачі й тільки для операцій «тільки читання» — пошук по кодовій базі, дослідження API, паралельний код‑рев’ю в рамках валідації.
На перший погляд це виглядає повільніше. Але на довгій дистанції зниження помилок і конфліктів дає кумулятивний ефект: менше відкатів, менше переробок, менше «прихованих» багів, які вилазять через тиждень. Для місій, що тривають днями, саме ця накопичена коректність стає вирішальною.
Цей підхід добре ілюструє загальну логіку таксономії: мультиагентні системи — це не про максимізацію миттєвого паралелізму, а про структуровану координацію, де кожна стратегія використовується там, де вона дає довгострокову перевагу.
Новий тип інженерії: як обирати моделі для різних ролей
Ще один наслідок запропонованої рамки — усвідомлення того, що жодна окрема модель не є «найкращою для всього». Планування, імплементація й валідація вимагають різних якостей:
планувальник (оркестратор) виграє від повільного, обережного міркування, здатності тримати в голові велику картину й формувати детальні контракти валідації;
воркери потребують швидкої, «вільної» кодової творчості, вміння працювати з існуючою кодовою базою й адаптуватися до зворотного зв’язку;
валідатори мають бути максимально точними в слідуванні інструкціям, без схильності «вигадувати» те, чого немає в контракті.
У такій архітектурі вибір моделі для кожної ролі стає окремою інженерною задачею. Усередині Factory це називають «droid whispering» — вмінням ментально моделювати, як різні LLM поводяться в конкретних ролях, де вони помиляються й як ці помилки накопичуються протягом багатоденної місії.
Це ще один аргумент на користь мультиагентного, а не «монолітного» підходу: система, яка дозволяє підбирати різні моделі (навіть від різних провайдерів) для різних ролей, отримує структурну перевагу. Наприклад, валідація може виконуватися моделлю іншого постачальника, щоб зменшити ризик спільних упереджень у тренувальних даних з моделлю‑імплементатором.
У підсумку архітектура стає модель‑агностичною: вона не прив’язана до конкретного LLM і може еволюціонувати разом із поколіннями моделей, не стаючи застарілою щоразу, коли на ринку з’являється новий флагман.
Висновок: таксономія як мова для наступного етапу AI‑розробки
Мультиагентні системи для розробки ПЗ сьогодні перебувають у стані «дикого Заходу»: багато експериментів, мало узгодженої термінології й ще менше перевірених на практиці патернів. Запропонована Люком Алвоейро таксономія п’яти стратегій — делегація, creator‑verifier, пряма комунікація, переговори й broadcast — не претендує на вичерпність, але дає спільну мову для опису й проєктування агентних команд.
Її головна цінність у тому, що вона безпосередньо прив’язана до реальних софтверних воркфловів: планування фіч, формування контрактів валідації, серійна імплементація, адверсаріальна перевірка, структуровані хендови й довгі місії, що тривають тижнями.
У цій рамці мультиагентність перестає бути абстрактною ідеєю й перетворюється на конкретну інженерію: які стратегії ми використовуємо, як ми їх комбінуємо, які ролі вводимо, які моделі садимо в кожне крісло й як забезпечуємо, щоб система не просто «генерувала код», а доводила роботу до стану «готово» за заздалегідь визначеним контрактом.
Якщо вузьким місцем розробки стає не інтелект, а увага, то наступний етап еволюції інструментів неминуче пов’язаний не лише з потужнішими моделями, а й з кращими способами організувати їхню взаємодію. Таксономія Алвоейро — одна з перших спроб системно описати ці способи. І, схоже, саме такі рамки визначатимуть, які мультиагентні системи справді «шиплять» код днями, а які залишаться ефектними демо.
Джерело
YouTube: Missions: Multi-Agent Systems That Ship for Days — Luke Alvoeiro, Factory