Технічний контекст
Я зачепився тут не за саму суперечку, а за дірку в архітектурі: оркестратор породжує субагента, а той тягне модель батька без нативного перемикача. Для AI automation це погана історія, тому що навіть простий інструмент раптово починає працювати на дорогій моделі там, де вистачило б mini-класу.
І ось тут я зазвичай гальмую проєкт і лізу в механіку. Якщо в інструмента немає параметрів вибору моделі, то жодна гарна інструкція в промпті не перетворюється на реальний роутинг. Агент може «знати», що треба економити, але технічно вибрати нічого.
З того, що видно з обговорення, проблема не в якості моделі як такої, а у відсутності шару керування конфігурацією при спавні субагентів. Це важлива різниця. Коли вибір моделі є лише на рівні батька, нащадок стає дорогою копією, а не спеціалізованим виконавцем.
Я такі речі зазвичай перевіряю дуже приземлено: беру один і той самий сценарій, де оркестратор вирішує, чи потрібен ресерч, сумаризація або форматування, і дивлюся, які виклики реально йдуть в API. Якщо кожен дочірній крок летить у важку модель, токени згорають не тому, що завдання складне, а тому, що AI integration зроблено без нормального роутингу.
Пошук у відкритих матеріалах тут, чесно кажучи, мало допомагає: у загальних оглядах LangChain, AutoGen та CrewAI багато розмов про гнучкість, але майже немає нормальної відповіді на питання, як уникнути такого успадкування в реальному проді. Тож дивитися треба не в маркетинг фреймворку, а в конкретний код ініціалізації агента, node-level model binding та фабрики субагентів.
Що це змінює для бізнесу та автоматизації
Перший удар очевидний: бюджет. Якщо сапорт, ресерч і валідація ганяються через одну важку модель, вартість пайплайну зростає без користі.
Другий удар тихіший, але болючіший: ви втрачаєте передбачуваність. Не можна нормально рахувати unit economics, якщо субагенти не вміють перемикатися між дешевим і потужним режимом залежно від завдання.
Виграють ті, хто будує AI solutions for business із явним контролем моделей на кожному вузлі. Програють команди, які вірять, що оркестратор сам «якось зрозуміє» і оптимізує ціну без параметрів.
Ми в Nahornyi AI Lab якраз такі вузькі місця й вичищаємо: розкладаємо оркестрацію за ролями, ставимо явний роутинг моделей і прибираємо прихованих пожирачів токенів. Якщо у вас AI implementation уже працює, але рахунки зростають швидше за користь, давайте подивимося на граф викликів і зберемо AI automation так, щоб система думала там, де це потрібно, а не в кожному чиху підряд.