88% пилотов AI-агентов проваливаются. Почему и при чем тут governance
Forrester в 2026 году выкатил цифру: 88% пилотов AI-агентов не доходят до production. Не потому что модели слабые. Потому что команды деплоят демо и ждут магии. Дали агенту максимум прав, не настроили мониторинг, не прописали границы. Получили непредсказуемую систему которая делает непредсказуемые вещи.
Есть два подхода к запуску агентов. Capability-first: дать агенту широкую автономию, а потом разбираться с последствиями. Governance-first: сначала firewall, audit log, propose-only паттерн, потом постепенно расширять возможности. Весь первый квартал 2026 организации, которые пошли по первому пути, тратили на перестройку governance layer. Те кто начал с ограничений, наоборот, спокойно масштабировали.
Экосистема MCP это наглядно показывает. В апреле 2026 независимый аудит проверил 2181 публичный MCP-сервер. Результат: 52% мертвы, zero commits месяцами. Только 9% оказались fully healthy. Построить MCP-сервер легко. Поддерживать его в production, с секретами, с token lifecycle, с мониторингом, сложнее на порядок.
По моему опыту, агент полезен не когда он умный, а когда он встроен в систему с контролем, мониторингом и четкими границами. Умный агент без governance это гоночная машина без тормозов. Дальше покажу как я строил это у себя: начиная с фреймворка уровней автономности и заканчивая конкретными production-паттернами.
Лестница автономности L0-L4: фреймворк вместо хайпа
Когда проектировал M.Business (рекламный движок для малого бизнеса), первым делом украл идею у автопрома. У машин есть уровни автопилота от 0 до 5. Я сделал то же самое для AI-агентов, только уровней пять: L0 до L4.
L0, Отслеживание: агент просто собирает данные и показывает дашборд. Никаких действий, только read-доступ. L1, Советчик: агент анализирует данные и выдает готовые предложения, но человек сам жмет кнопку "Запустить". L2, Ассистент: агент сам собирает рекламный юнит, человек только апрувит. L3, Автопилот с тормозом: агент действует сам, но человек может в любой момент остановить. L4, Полная автономия: агент работает без участия человека.
Ключевой принцип: каждый уровень это отдельный продукт, который копит данные для следующего. L1 намеренно обходит самую сложную часть, генерацию визуала. Я сознательно ограничил форматы: Instagram boost уже существующего поста (креатив уже есть, AI его не трогает) и Google поисковая кампания (текстовая, AI пишет объявления). Картинки и видео это L2+, до них надо дорасти.
Этот же паттерн применили в Амелии, AI-студии M.Flow. У нее 14 инструментов, но распределены они так: 6 read (воронка, диалоги, горячие лиды, брони, каталог, затыки), 2 draft (черновик ответа и черновик поста) и 6 propose (предложить изменение в пайплайне, кастомное поле, услугу, статью в базу знаний, шаблон ответа, правило автоматизации). Ни одного write-инструмента. Амелия предлагает, владелец бизнеса подтверждает кликом, система исполняет. Audit log с before-snapshot на каждое действие, чтобы любое изменение можно было откатить.
Human-in-the-loop тут не ограничение и не компромисс. Это осознанное архитектурное решение. Propose-only паттерн масштабируется: агент становится умнее, предложения становятся точнее, но человек всегда остается в контуре принятия решений. Полная автономия не цель, а крайняя точка спектра до которой большинству систем не надо добираться.
MCP-сервер с 22 инструментами: зачем бизнесу свой и как он меняет workflow
MCP Studio, мой локальный MCP-сервер, стартовал в мае 2026. Сейчас в нем 22 инструмента: Meta Ads 7, Instagram 7, Google Ads 5, GA4 3, GTM 5, плюс 2 инструмента для контекста M.Flow. Через него я управляю рекламой 7 Instagram-аккаунтов и 6 Google Ads клиентов. Ни одного клика в Ads Manager за последний месяц.
Идея простая: не плодить лишних UI-кликов в рекламных кабинетах. Спросил Claude, получил ответ. Надо посмотреть CPL по кампании, сравнить с прошлой неделей, приостановить неэффективную, поднять бюджет на рабочую. Все через диалог, все через MCP-инструменты.
Но стратегическое видение шире. MCP Studio это фундамент для рекламного агента, который утром читает GA4 + Google Ads + Meta insights, сверяет CPL по каналам с ROI из M.Flow, и предлагает что выключить, что поднять, что бустнуть. По одному клику исполняет через write-tools. Вся архитектура auth построена с учетом этого: два независимых OAuth client (Google Ads отдельно от GA4+GTM). Если один упадет, второй продолжает работать.
А дальше начинаются нюансы. Stdout в MCP зарезервирован под JSON-RPC, значит любой console.log ломает парсер. Dotenv quiet-mode обязателен, иначе сервер падает на старте. Описания tools, та часть которую все пропускают, на самом деле главная точка отказа. LLM инферит назначение инструмента из его metadata. Плохое описание = модель вызывает не тот tool или передает не те параметры.
По данным отрасли, 86% MCP-серверов не выходят за пределы ноутбука разработчика. OAuth ломается в MCP потому что протокол спроектирован для human-driven flows, а агенты работают часами и днями. Token lifecycle не совпадает с lifecycle агента. Переход в production требует управления секретами, смены транспорта, продуманных описаний инструментов и стратегии обновления токенов. Я решал каждую из этих проблем на практике, и ни одна не была тривиальной.
SEO-отдел на 6 AI-агентах: от идеи до первого прогона за 2 дня
Контекст простой: я физически не успеваю писать три длинных гайда в неделю на блог сам, а с приходом AI Overviews в поисковую выдачу требования к контенту только выросли — нужен материал, который Google цитирует, а не заменяет. Решение: построить AI-команду из 6 отделов, которая по cron публикует контент автономно. Не помогает мне писать, а пишет сама. Background agent в чистом виде.
Пайплайн состоит из 14 этапов от темы до деплоя, сгруппированных в 6 отделов. У каждого мнемоническое имя: Анатолий-Аналитик (выбирает тему, анализирует SERP), Архип-Архитектор (строит outline), Костя-Копирайтер (пишет секции), Рома-Редактор (склеивает в единый поток, инжектирует голос), Семен-Сеошник (мета, ссылки, проверка фактов), Паша-Паблишер (генерирует обложку через DALL-E 3, коммитит, пушит). Cron запускается пн/ср/пт в 04:00 по Алматы.
Первый реальный прогон случился 01.06.2026. Не заглушки, не моки. Живой Claude Code CLI прогнал 6 из 14 этапов: topic-selection за 40 секунд, serp-research за 77, knowledge-mining за 153, trend-research за 121, outline за 73, section-drafts за 149 секунд. Прогон остановил вручную (переключился на другую машину), но главное стало понятно: это уже не демо, машина пишет сама.
Результат одного цикла: markdown-пост + обложка + git push. Vercel ловит push и деплоит. От cron-триггера до опубликованной статьи на milakhin.studio/blog проходит 20-30 минут без участия человека.
Отдельная тема: Confidentiality Firewall. У меня два рабочих контекста: студия и крупный банк в KZ. Утечка банковских данных в публичный контент недопустима. Поэтому в пайплайн жестко зашит forbidden.yaml с тремя уровнями защиты. Hard blocks: при срабатывании публикация отменяется, я получаю Telegram-алерт. Soft redactions: автоматическая замена (название банка - "крупный банк в KZ"). Numeric blocks: пометка на ручное подтверждение. Не написали ни одного поста, зато построили все что надо чтобы они писались сами. И чтобы при этом ничего конфиденциального не утекло.
Провалы и развороты: антипаттерны из первых рук
Первая версия 3D-офиса SEO-отдела выглядела как армия: 14 одинаковых человечков за столами в ряд. Я посмотрел и сказал "армия какая-то". Свели к 6 отделам. Но главная находка была в другом: idle-агенты не должны сидеть за столами. Это противоречит интуиции, "отдыхающий сотрудник сидит за компом" выглядит неправильно визуально. Переделали: работающий агент печатает за компьютером (экран пульсирует), отдыхающий барабанит, играет в теннис, сидит на диване или стоит у кулера. Мелочь, но именно она сделала визуализацию живой.
Техническая ловушка с монорепо стоила 5 проваленных деплоев подряд. MCP-пакет в packages/ имел свой package.json с зависимостями (@modelcontextprotocol/sdk), и Next.js TypeScript check ломался на нем при сборке на Vercel. Локальный tsc --noEmit проблему не показывал вообще. Фикс оказался в одну строку: exclude packages/** в tsconfig.json. Но чтобы до него дойти, пришлось прочитать пять логов деплоя.
Когда встал вопрос "где запускать cron для SEO-пайплайна", первый рефлекс был: поднять VPS, настроить systemd, мониторинг, обновления. Решение: запускать через локальную машину. Просто, без оверинжиниринга. Но появилась новая проблема: у меня две машины (Mac и ПК), и обе могут запустить cron одновременно. Первая итерация, пассивная защита: guard-окно 90 минут (если один прогон не закончился, второй не стартует). Вторая итерация, лучше: явный рубильник в UI. Одна машина запускает, другая молча пропускает.
И самый дорогой разворот: M.Flow из SaaS для салонов в инструмент агентства. Продавать бьюти-салонам по 15-30 тысяч тенге в месяц это копейки, постоянный отток и саппорт толпы за гроши. А потом зашел один дилер грузовиков. Один такой клиент с рекламным движком приносит столько же, сколько 30-50 салонов, но без SaaS-инфраструктуры, без саппорта сотен пользователей, без маркетинга продукта. Агентство + движок дает выручку уже сейчас — как в кейсе beauty-студии с CTWA-воронкой — а не "когда-нибудь наберем 100 салонов".
Архитектура оркестрации: Claude Code + MCP + субагенты как единый production workflow
Все три компонента описаны по отдельности в десятках статей. Claude Code, MCP, субагенты. Но нигде они не связаны в единую production-систему. А именно в связке они дают результат.
Архитектура выглядит так. Claude Code CLI работает как runtime, основной процесс который принимает задачу и оркестрирует исполнение. MCP-сервер это tool layer, через него агент получает доступ к внешним системам (рекламные кабинеты, аналитика, CRM). Субагенты это специализированные workers: один анализирует SERP, другой пишет секцию текста, третий проверяет факты. Оркестратор запускает их параллельно или последовательно в зависимости от зависимостей между этапами.
Мониторинг всего этого идет через Command Center. Heartbeat-механизм простой: каждый компонент периодически шлет ping в Supabase. Панель читает свежесть последнего ping и показывает статус: зеленый (alive), желтый (задержка), красный (не отвечает). MCP-сервер пингует раз в минуту. Auto-refresh панели каждые 45 секунд. Ничего сложного, но без этого ты не знаешь работает система или тихо умерла.
Визуализация: воксельный 3D-офис на three.js + @react-three/fiber + drei. 6 человечков-агентов, каждый привязан к своему отделу SEO-пайплайна. Работающий агент сидит за столом, печатает, экран пульсирует. Отдыхающий играет в теннис или стоит у кулера. Realtime через Supabase подписку. Состояние в Supabase, код в git, заметки в Obsidian, рубильник машины в один клик. Пересел с Mac на ПК и продолжил с того же места.
Что бы я сделал иначе: правила для тех кто начинает с агентами
Governance до capability. Firewall, audit log, propose-only паттерн лучше закладывать с первого дня, не после инцидента. В 2026 году был реальный случай: агент удалил prod-базу с 1206 записями и сгенерировал 4000 фейковых чтобы замаскировать. С firewall это бы не прошло.
Tool descriptions важнее tool implementations. LLM инферит назначение из metadata. Плохое описание = агент вызывает не тот инструмент. Я потратил больше времени на описания 22 tools чем на их код. И это окупилось.
Начинай с read-only. У Амелии 6 read tools, потом 2 draft, потом 6 propose. Write-права это последний уровень, не первый. Такой порядок дает агенту время набрать контекст и доверие, а тебе время понять где он ошибается.
Treat agents as software systems: evaluation, мониторинг, circuit breakers до запуска. Демо это не production. 88% пилотов проваливаются потому что команды не видят разницы.
И последнее: простое решение бьет архитектурное. Локальный cron вместо VPS. Exclude в tsconfig вместо рефакторинга монорепо. Email+password вместо magic links. Каждый раз когда я выбирал скучное но рабочее решение вместо красивого, я экономил дни. А красивое можно добавить потом, когда скучное уже приносит результат.