Технічний контекст
Я дивлюся на ситуацію з Manus прагматично: факт покупки Meta наприкінці грудня 2025 року підтверджено, а ось деградація якості, «пожирання» токенів і поломка оплати — це поки що користувацькі сигнали, не підкріплені публічними метриками або офіційними статус-сторінками.
Але саме такі сигнали я завжди враховую в AI-архітектурі: у SaaS-ШІ є дві зони болю — білінг і передбачуваність витрат. Якщо користувач пише, що «місячний запас токенів пішов незрозуміло на що», я читаю це як відсутність прозорої телеметрії: немає зрозумілої розбивки за завданнями, кроками агента, ретраями, помилками інструментів та повторними викликами моделей.
Друга червона зона — платіжний флоу. Зламана оплата означає не просто незручність; це ризик зупинки робочих процесів і неможливість швидко докупити ліміти в критичний момент.
Окремо зазначу: Manus історично сприймався як автономний агент для складних завдань (дослідження, код, аналіз даних, збір артефактів). Тому його спроби використовувати «як комбайн» для презентацій логічні, але саме в таких сценаріях вартість помилок максимальна: агент може багаторазово перегенерувати слайди, смикати зовнішні інструменти та випалювати бюджет без явного результату.
Вплив на бізнес та ШІ автоматизацію
Коли продукт потрапляє в орбіту великої платформи, я завжди закладаю період турбулентності: міграції акаунтів, нові політики даних, перезбирання інфраструктури, зміна пріоритетів роадмапу. Якщо при цьому виникають баги, бізнес платить двічі — грошима та простоями.
Хто виграє? Команди, у яких впровадження ШІ зроблено не «на одному сервісі», а через шар оркестрації: маршрутизація завдань, ліміти, кешування результатів, контроль ретраїв, журналювання. Хто програє? Ті, хто прив'язав презентації, звіти та аналітику до одного агента без запасного сценарію і без контролю витрат токенів.
У проєктах Nahornyi AI Lab я зазвичай ставлю просте правило: будь-який зовнішній ШІ-інструмент має бути замінним за 1–3 дні. Це досягається не магією, а дисципліною: єдиний інтерфейс виклику моделей/агентів, ізоляція промптів, контроль версій, і окремий модуль білінгу з лімітами на користувача, завдання та добу.
Що робити із завданням презентацій, якщо Manus «штормить»? Я не сприймаю коментар «треба було Kimi Slides юзати» як доказ переваги Kimi Slides — у мене немає підтверджених даних про продукт. Але сама стратегія правильна: тримати спеціалізований інструмент для слайдів окремо від автономного агента, який може піти в дорогі ітерації.
Стратегічне бачення та глибокий розбір
Мій прогноз на 2026 рік: ринок буде розходитися на два класи рішень. Перші — платформні агенти «для всього», які хороші інтеграціями, але непередбачувані щодо змін та політики. Другі — вузькі інструменти (презентації, продажі, підтримка), які простіше стабілізувати та вимірювати.
Якщо ви будуєте ШІ рішення для бізнесу, я б не ставив на «універсального агента» як на єдину точку правди. Я б проєктував архітектуру ШІ-рішень так, щоб презентації жили в пайплайні: дані → структура → слайди → QA → експорт, і на кожному кроці можна змінити постачальника (Manus, інший агент, окремий генератор слайдів) без переписування всього процесу.
З практики Nahornyi AI Lab: найдорожчі інциденти відбуваються не через якість тексту, а через відсутність guardrails. Ліміт кроків агента, обмеження на зовнішні виклики, заборона на нескінченні «покращення», і обов'язковий звіт про витрати — це не опції, а базова ШІ інтеграція для реального сектору.
Якщо скарги на Manus підтвердяться і стануть масовими, компанії з такою архітектурою просто перейдуть на альтернативи. Компанії без неї будуть «лагодити процес» через ручну працю і втрачати темп.
Цей розбір підготував Вадим Нагорний — провідний експерт Nahornyi AI Lab із впровадження штучного інтелекту та AI-автоматизації в реальному секторі. Я пропоную обговорити ваш кейс: оціню ризики поточних ШІ-інструментів, спроєктую замінну схему (оркестрація, білінг, спостережливість) і допоможу зробити ШІ автоматизацію, яка не ламається через один зовнішній SaaS.