Технічний контекст
Я люблю такі кейси не за вау-ефект, а за те, що тут вже видно нормальну AI-архітектуру, а не черговий чат із нашвидкуруч написаним промптом. Схема проста й сильна: спільна база знань в Obsidian, у кожного проєкту свій Claude Code, зверху оркестратор, а нижче — субагенти для конкретних завдань.
Мені особливо подобається, що база знань винесена в Markdown. Це дуже практичний хід для інтеграції ШІ: знання, інструкції, контекст проєкту та маршрутизація завдань зберігаються в читабельному вигляді, а не зашиті в код оркестратора. Змінюєш Markdown, а не перепрошиваєш усю систему.
Далі починається найцікавіше. Якщо проєктний агент заходить у глухий кут, він не зависає в нескінченному циклі, а ескалює проблему нагору. Оркестратор вирішує, що робити далі: сам розбирає кейс, передає завдання іншому агенту або розбиває роботу на підзадачі.
Це вже дуже схоже на production-like dev-конвеєр. Я бачу тут знайомі патерни: ізольовані сесії, виділені ролі, передача завдань між агентами, спільний шар пам'яті та управління тривалими завданнями через координатора. По суті, це фундамент для впровадження штучного інтелекту в інженерних командах, де важливий не один розумний агент, а стабільний процес.
Окремо зачепило, що верхніми оркестраторами можуть працювати і Claude Code, і Codex. Ось тут я б уже уважно дивився на межі відповідальності, щоб вони не почали сперечатися один з одним за контроль над пайплайном. Але сама ідея слушна: одна модель сильніша в одному типі завдань, друга — в іншому, і це можна використовувати як шар маршрутизації, а не як битву моделей.
Що це змінює для бізнесу та автоматизації
Перший ефект очевидний: знижується ціна перемикання контексту. Коли у кожного проєкту свій агент і своя пам'ять, я не витрачаю пів дня на повторне пояснення архітектури, багів та домовленостей. Для команд це вже не іграшка, а реальна автоматизація за допомогою ШІ.
Другий момент, де я б поставив жирний плюс, — це ескалація. Замість мовчазного провалу агент піднімає руку, оркестратор втручається, і завдання не вмирає. Для внутрішніх платформ, підтримки розробки та тривалих рефакторингів це критично важливо.
Але програють ті, хто запускає таке без дисципліни. Без ізоляції worktree, логів, лімітів за часом і зрозумілої схеми передачі завдань мультиагентність швидко перетворюється на дорогий хаос на токенах.
Я саме такі речі й люблю розбирати до гвинтика: де залишити одного агента, де будувати оркестрацію, а де не чіпати те, що й так працює. Якщо ваша команда вже грузне в ручній координації, в Nahornyi AI Lab ми можемо зібрати розробку AI-рішення під ваш реальний робочий процес, щоб агенти забрали рутину, а люди нарешті займалися інженерією, а не диспетчеризацією.