F·01
Принимать задачи от владельца
Вход — обычная формулировка результата: «найти причину кассового разрыва», «запустить продукт», «закрыть вакансию». Владелец не пишет промпт, не выбирает модель и не указывает, какой отдел за что отвечает.
02 · Центр системы Целевая архитектура
Руководитель, которого нет ни у кого на рынке
Мы исследовали двадцать платформ: у всех есть либо техническая оркестрация агентов, либо один специализированный сотрудник. Ни одна не предлагает руководителя компании как продукт — того, кто принимает цель на языке бизнеса, распределяет её по отделам, держит сроки и отвечает владельцу отчётом, а не логом.
10
функций в целевой архитектуре
3
уровня автономии отдела
8
отделов, которым он назначает задачи
Статус честно. AI CEO не реализован: на момент публикации это целевая архитектура, ни одна из десяти функций не работает. Пример отчёта на этой странице помечен как демонстрация и написан вручную — он не получен от живого AI-сервиса. Клиентов, отзывов и метрик внедрения у проекта нет, поэтому они не приводятся. Референсы конкурентов взяты из нашего исследования публичных материалов и даны с указанием источника.
01 · Обязанности
Десять функций центрального руководителя
Это полный список обязанностей AI CEO в целевой архитектуре. Каждая карточка помечена слоем системы, в котором функция выполняется, и ни одна не заявлена как работающая.
F·02
Анализировать цели компании
Задача сверяется с целями бизнеса: если она им противоречит или дублирует уже идущую работу, AI CEO сообщает об этом до начала исполнения, а не после.
F·03
Разбивать задачу на подзадачи
Декомпозиция с критерием готовности для каждой части и с явными зависимостями: что можно делать параллельно, а что — только после результата предыдущего шага.
F·04
Назначать исполнителей
Каждая подзадача уходит в профильный отдел: маркетингу, продажам, операциям, финансам, людям, исследованиям, разработке или поддержке — вместе с входными данными и сроком.
F·05
Контролировать сроки
Задачи длиной в дни и недели остаются открытыми между этапами. Просрочка, застрявший этап или нехватка входящих данных видны владельцу сразу, а не в конце.
F·06
Проверять результаты
Ответ отдела сверяется с критерием готовности. Вывод, который данные не подтверждают, отклоняется и возвращается на доработку — вместо того чтобы попасть в отчёт владельца.
F·07
Формировать отчёты
Итог сводится в один ответ по задаче: какой отдел что сделал, какое решение принято, что осталось на стороне владельца. Формат — бизнес-нарратив, не системный лог.
F·08
Выявлять проблемы
Повторяющиеся сбои и системные причины выделяются отдельно от разовой задачи: если пять обращений клиентов объясняются одной ошибкой в процессе, это попадает в отчёт как проблема процесса.
F·09
Предлагать решения
К каждой выявленной проблеме — два-три варианта действий с последствиями каждого. Выбор остаётся за владельцем: система не принимает решений о деньгах, людях и клиентах самостоятельно.
F·10
Передавать задачи другим агентам
Большая задача может быть разделена между несколькими исполнителями внутри отдела и между отделами одновременно, с общим контролем хода и одним сводным результатом вместо нескольких несвязанных ответов.
Все десять функций — целевая архитектура. Реализовано: ни одной. Список соответствует техническому заданию проекта (раздел 4.1) и не расширен возможностями, которых в плане нет.
02 · Механика
Управление — это цикл, а не прямая
Автоматизация заканчивается результатом. Руководство — нет: отчёт владельца порождает следующую задачу. Поэтому контур AI CEO замкнут, и шестой этап возвращает систему к первому.
Приём цели
intake
Задача фиксируется вместе с ожидаемым результатом и контекстом компании. На этом этапе ничего не исполняется — только принимается и проверяется на противоречие текущим целям.
Декомпозиция
decompose
План из подзадач с критерием готовности каждой. Здесь же определяется, что можно выполнять параллельно, а что — последовательно, и где потребуется подтверждение владельца.
Назначение
assign
Подзадачи уходят в отделы с входными данными, сроком и уровнем автономии. Отдел видит не всю задачу, а свою часть — но с контекстом, зачем она нужна.
Контроль сроков
watch
Отслеживание этапов во времени: что идёт по плану, что застряло, где не хватает входящих данных. Застревание эскалируется владельцу сразу, а не в момент, когда срок уже сорван.
Проверка результатов
verify
Ответы отделов сверяются с критерием готовности. Недостаточно обоснованный вывод возвращается на доработку; противоречия между отделами разбираются до сведения в один ответ.
Отчёт владельцу
report
Один сводный ответ: что сделано, какой отдел за что отвечал, какие проблемы найдены и какие решения предлагаются. Дальше — решение владельца, которое становится следующей задачей.
Цикл замыкается: решение владельца по отчёту становится новой задачей на этапе 1
03 · Доверие
Шкала автономии: L1 → L2 → L3
Главный страх бизнеса — «агент наделает ошибок». Ответ на него не assurances, а явные уровни: каждый отдел начинает под контролем человека и поднимается выше только тогда, когда его результаты проверены. Уровень автономии задаёт владелец, а не система.
L1
под надзором
Отдел работает под надзором человека
Каждое действие с последствиями предварительно показывается владельцу или уполномоченному сотруднику и выполняется только после подтверждения. Отдел готовит — человек решает.
- Любое внешнее действие — только после подтверждения
- Черновики и расчёты видны до отправки
- Полный журнал: что предложено, что одобрено, что отклонено
- Подходит для старта и для регулируемых процессов
Человек: каждое действие
уровень по умолчанию
L2
независимо
Отдел работает самостоятельно в заданных границах
Рутинные действия выполняются без подтверждения, но строго внутри правил, которые задал владелец: лимиты, допустимые сценарии, запрещённые темы. Всё, что выходит за границы, автоматически возвращается на L1 — на подтверждение.
- Типовые операции — без ожидания человека
- Выход за границы правил = обязательное подтверждение
- Эскалация при нехватке данных или противоречии
- Владелец видит итоги и отклонения, а не каждое действие
Человек: исключения
после проверки результатов на L1
L3
управляет
Отдел ведёт многошаговую работу через другие отделы
Отдел сам ставит подзадачи исполнителям, координирует этапы длиной в недели и перестраивает план по ходу. Ответственность за результат остаётся на AI CEO: именно он отчитывается владельцу за всю цепочку.
- Многошаговые задачи с этапами и сроками
- Делегирование исполнителям внутри и между отделами
- Перестроение плана при изменении входных данных
- Финансовые операции — по-прежнему только с разрешения
Человек: цели и деньги
максимальный уровень
Как это работает как путь. Уровень назначается для каждого отдела отдельно: маркетинг может быть на L2, а финансы — оставаться на L1, потому что цена ошибки разная. Повышение уровня — решение владельца, принимаемое после того, как результаты отдела на предыдущем уровне проверены. Понижение доступно в любой момент.
Идея шкалы заимствована как проверенная продуктовая модель: у Artisan уровни автономии описаны как «L1 — под надзором человека, L2 — работает независимо, L3 — управляет многошаговыми кампаниями» (публичный блог компании, см. research/extra-10.md, раздел 7.4). Наполнение уровней у VOIR — своё, применительно к отделам и к роли AI CEO. Сама шкала является целевой архитектурой и в продукте не реализована.
04 · Объяснимость
Владельцу нужен не трейс, а ответ
Наблюдаемость есть почти у всех: логи вызовов, задержки, статусы. Всё это написано для инженера. Незанятым осталось другое — перевод той же информации на язык владельца: что сделано, почему так решили, что это стоило и что дало.
Демонстрация
Обе панели ниже — вымышленный пример формата, написанный вручную для иллюстрации. Это не вывод работающей системы: AI CEO не реализован, поэтому реальных логов и реальных отчётов у проекта нет. Числа, имена и идентификаторы в примере условны.
Что видит инженер: системный трейс
- 09:14:02 INFO task.created id=T-2291 intake="клиент просит возврат, поставка сорвана"
- 09:14:03 INFO planner.decompose task=T-2291 subtasks=3 deps=[s2<-s1, s3<-s1]
- 09:14:05 INFO assign s1 -> dept.operations tool=oms.orders.lookup
- 09:14:09 OK tool.call oms.orders.lookup 412ms status=200 rows=6
- 09:14:11 INFO assign s2 -> dept.finance tool=billing.payments.query
- 09:14:14 WARN policy.check action=refund amount=* requires=human_approval
- 09:14:14 INFO approval.requested channel=telegram task=T-2291 blocks=[s3]
- 09:16:40 OK approval.granted by=owner decision=refund
- 09:16:42 INFO assign s3 -> dept.support tool=kb.draft_reply
- 09:16:47 OK report.compose task=T-2291 tokens_in=4180 tokens_out=612 cost=*
Формат намеренно технический: идентификаторы, задержки, коды ответов, количество токенов. Так трейс выглядит у большинства платформ наблюдаемости, и читать его должен инженер.
Что видит владелец: отчёт бизнес-языком
По обращению клиента N. Заказ действительно не доставлен: по данным системы заказов статус поставки не менялся пять дней. Оплата получена полностью, удержаний не было. Возврат обоснован, я вынес его на ваше подтверждение — вы одобрили, деньги возвращаются.
Кто что сделал
Операции восстановили факты по заказу, Финансы подтвердили оплату и отсутствие
удержаний, Поддержка подготовила текст ответа клиенту. Все три части проверены на
соответствие критерию готовности.
Что потребовало вашего решения
Только возврат денег — по правилам это действие с финансовыми последствиями, поэтому
оно не выполняется без подтверждения. Сбор данных и текст ответа шли без ожидания.
Найденная проблема
Срыв поставки — не единичный случай: за тот же период статус не менялся ещё по
нескольким заказам того же направления. Это похоже на проблему в процессе, а не на
ошибку одного клиента.
Что предлагаю
Два варианта: проверить процесс отгрузки в Операциях или добавить правило раннего
оповещения, чтобы такие заказы всплывали до жалобы клиента. Решение за вами — я
подготовлю детали по выбранному варианту.
Тот же набор событий, но без идентификаторов вызовов и токенов: что произошло, кто работал, где понадобилось ваше решение и что стоит исправить. Технические детали при этом не теряются — они остаются в журнале для тех, кому нужны.
Почему это отдельная задача
Перевод трейса в нарратив нельзя получить, просто «красиво отформатировав лог»: нужно знать, какие из десятков вызовов имеют значение для решения владельца, а какие — служебные. Это работа слоя Agentic, а не отчёта.
Что остаётся у инженера
Полный журнал вызовов, стоимости и статусов не заменяется нарративом, а существует рядом: владелец читает отчёт, специалист при необходимости открывает трейс той же задачи. Оба представления относятся к одной работе.
05 · Референсы
Кто уже делает похожее — и где граница
Идея центрального оркестратора не нова, но у каждого из референсов она живёт внутри технической или отраслевой задачи. Ниже — три ближайших зародыша из нашего исследования и то, чем подход VOIR отличается.
Salesforce Agentforce
Atlas Reasoning Engine
Движок, который «разбивает исходный запрос на меньшие задачи, оценивает каждый шаг и предлагает план дальнейшего движения, пока не будет получен полный ответ или выполнено действие». Это многошаговое планирование с самооценкой — архитектурно то же, что VOIR закладывает в декомпозицию и проверку результатов.
Граница
Работает внутри CRM-контекста и ролевых агентов Salesforce (Service, SDR, Sales
Coach). Это reasoning-движок продукта, а не руководитель компании, распределяющий
работу по восьми отделам бизнеса.
Источник: research/extra-10.md, раздел о Salesforce Agentforce (публичное описание Atlas Reasoning Engine)
Cognition · Devin
Swarm: оркестратор и параллельные исполнители
Большая задача делится между параллельными облачными агентами: один Devin выступает оркестратором, управляет исполнителями и отчитывается о результате. Компания прямо формулирует это как «инженеры работают как архитекторы и делегируют исполнение рою агентов». Это ближайшая рабочая модель функции F10.
Граница
Домен — разработка ПО. Оркестратор делит инженерную задачу между такими же
инженерами-агентами; бизнес-ролей, отделов и отчёта владельцу на языке бизнеса там нет.
Источник: research/extra-10.md, разделы 10.3 и «Berём» по Cognition (публичные блоги Series E и описания Devin swarms)
Sierra
Horizon: планирование на дни и месяцы
«Long-horizon planning — разбивать сложные результаты на конкретные шаги, которые улучшаются в течение дней или месяцев», плюс память, связывающая диалоги, системы и точки контакта. Это подтверждает требование к функции F5: контроль сроков имеет смысл только для задач, которые живут дольше одной сессии.
Граница
Продукт — один клиентский агент, развёрнутый на многих каналах (чат, SMS, WhatsApp,
email, голос). Долгий план ведёт один исполнитель в сфере клиентского опыта, а не
руководитель, координирующий восемь отделов.
Источник: research/extra-10.md, раздел о Sierra (публичное описание Horizon и заявление о single agent across channels)
Что из этого следует для VOIR
Разница не в технологии, а в предмете
Декомпозиция, параллельное исполнение и долгие планы уже существуют — по отдельности и в своих доменах. Незанятым осталось другое: тот же механизм, направленный на бизнес целиком, с входом на языке владельца и выходом в виде отчёта владельцу. Это продуктовая модель «организация как система», а не новый алгоритм.
Проверено исследованием
В сводке по двадцати исследованным компаниям центральный оркестратор с бизнес-языком
не заявлен ни у кого: ближайшие зародыши — Devin swarm и Atlas Reasoning Engine, оба
в своём техническом или CRM-контексте (research/extra-10.md, сводная таблица;
research/OPPORTUNITY-MAP.md, ниша N1).
Источник: research/OPPORTUNITY-MAP.md (N1) и research/extra-10.md (сводка по 20 компаниям)
06 · Границы
Чего AI CEO не делает никогда
Полномочия руководителя ограничены так же явно, как и его обязанности. Эти границы задаются правилами слоя Control и не зависят от уровня автономии отдела.
Не выполняет платежи и финансовые операции
На любом уровне автономии, включая L3. Финансовый отдел готовит расчёт и оценку последствий; платёж, перевод и любая операция с деньгами происходят только после явного разрешения владельца.
Не принимает окончательных решений о людях
Найм, увольнение, оценка сотрудника и распределение нагрузки между людьми остаются за владельцем или руководителем. AI CEO готовит материалы и критерии, но не выносит решение о человеке.
Не выдаёт неподтверждённый вывод за факт
Если данных недостаточно, в отчёте так и пишется — с указанием, чего именно не хватает и где это можно получить. Ответ «данных нет» считается корректным результатом, а не сбоем работы.
Не скрывает от владельца свои действия
Каждое назначение, каждое отклонённое решение отдела и каждое действие, потребовавшее подтверждения, попадают в журнал. Нарративный отчёт — это представление журнала, а не его замена.
Не повышает свой уровень автономии сам
Переход отдела с L1 на L2 или с L2 на L3 — решение владельца. Система может показать результаты, на основании которых такое решение разумно, но не меняет уровень автоматически.
Не работает сегодня
AI CEO — целевая архитектура. Ни одна из десяти функций, ни один уровень шкалы автономии не реализованы; пример отчёта на этой странице написан вручную как иллюстрация формата и помечен как демонстрация.
07 · Что дальше
Куда идти из этой страницы
Архитектура
AI Operating System
Три слоя Control / Agentic / Execution, в одном из которых работает AI CEO, и путь
конкретной задачи сквозь всю систему.
Открыть страницу
Главная · демонстрация
Как выглядит делегирование
Четыре бизнес-задачи с разбором на подзадачи и назначением отделам — на заранее
подготовленных сценариях, с явной пометкой «Демонстрация».
К демонстрации
Ещё не опубликовано
Страницы отделов
Отдельные страницы восьми отделов готовятся. Список задач каждого отдела уже есть на
главной — ссылка выше ведёт туда же.
скоро