Технический контекст
Я смотрю на ситуацию с 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.