01 · Архитектура платформы Целевая архитектура

Операционная система для бизнеса, а не для агентов

Слово «AI Operating System» на рынке уже занято — но почти всегда оно означает систему, в которой живут агенты: их собирают, тестируют, публикуют и наблюдают. VOIR устроен иначе: операционная система здесь — это сам бизнес. Её единица измерения — не запуск агента, а выполненная задача компании.

Тезис страницы. Систему можно описать тремя слоями — кто имеет право действовать, кто решает и чем действие выполняется. Если все три слоя принадлежат бизнесу, а не отделу разработки, получается операционная система компании. Таксономия «Control / Agentic / Execution» взята как проверенная трёхслойная модель enterprise-платформ; наполнение каждого слоя у VOIR — своё.

Статус честно. На момент публикации ни один из трёх слоёв и ни один из восьми отделов не реализован. Всё описанное ниже — целевая архитектура продукта. Пошаговое проигрывание пути задачи на этой странице помечено как демонстрация и работает на заранее подготовленных сценариях, без обращения к живому AI-сервису и без изменения каких-либо данных. Клиентов, отзывов и метрик внедрения у проекта нет, поэтому они здесь не приводятся.

02 · Разрез

Три слоя, сквозь которые проходит любая задача

Слои описывают не этапы разработки, а то, как задача движется в работающей компании: сначала — имеем ли мы право это делать, затем — кто и как решает, и только потом — чем именно решение исполняется.

L·01 Control — управление и границы

Кто имеет право действовать

Слой правил: что агенту разрешено, какие действия требуют подтверждения человека и как записывается каждое решение. Он не выполняет работу — он задаёт её границы.

В живой компании это устав, должностные инструкции и лимиты подписи. В VOIR слой Control отвечает за то, чтобы автономия отдела не превращалась в непредсказуемость: любое действие с деньгами, клиентами или внешними системами проходит через правило, которое задал владелец.

  • Правила и запреты, сформулированные обычным языком, а не регулярными выражениями
  • Подтверждение человеком для действий с последствиями — отдельный, явный шаг
  • Разграничение доступа: что может отдел отдельно от того, кто им пользуется
  • Журнал решений: кто, когда и на каком основании так поступил
  • Финансовые операции и платежи — только с явного разрешения владельца
Аналогия Регламент компании и лимит подписи руководителя: что можно делать без согласования, а что — только через подпись.
Что этот слой НЕ делает Не принимает решений по задаче и не вызывает инструменты. Он только разрешает, запрещает или отправляет на подтверждение.
Целевая архитектура Реализовано: нет

L·02 Agentic — принятие решений

Кто решает и как задача разбирается

Слой, в котором живут AI CEO и восемь отделов. Здесь задача превращается в план: подзадачи, исполнители, порядок, зависимости и критерий готовности.

Это единственный слой, который «думает». AI CEO принимает задачу от владельца как есть — без промпта и без указания, какой отдел за что отвечает, — и разбирает её сам. Отделы работают в рамках своей функции: у маркетинга, финансов и поддержки разные данные, разные инструменты и разные критерии качества.

  • AI CEO: приём цели, декомпозиция, назначение исполнителей, контроль сроков
  • Восемь отделов как постоянные функции бизнеса, а не как набор отдельных чат-ботов
  • Передача результата между отделами по маршруту, а не вручную копированием
  • Детерминированный граф там, где процесс известен, и автономия внутри отдельного шага
  • Эскалация владельцу, когда отдел не может решить задачу в своих границах
Аналогия Руководитель и руководители отделов: задача приходит одной формулировкой, а уходит планом с ответственными.
Что этот слой НЕ делает Не хранит секреты доступа и не ходит во внешние системы напрямую — для этого есть слой Execution.

Подробно этот слой описан на странице AI CEO

Целевая архитектура Реализовано: нет

L·03 Execution — исполнение

Чем решение выполняется

Слой инструментов: коннекторы к почтам, CRM, таблицам и календарям, вызовы моделей, детерминированные шаги и результат, который возвращается в отдел.

Здесь нет принятия решений — только точное исполнение того, что решил слой Agentic и что разрешил слой Control. Ключевое требование к этому слою: учётные данные не должны попадать в модель. Инструмент получает доступ сам, модель видит только результат.

  • Нативные коннекторы: почта, мессенджеры, CRM, таблицы, календарь
  • Учётные данные хранятся в шлюзе и не передаются модели
  • Детерминированные шаги для процессов, где последовательность известна заранее
  • Несколько моделей на выбор вместо привязки к одному вендору
  • Запись каждого вызова: что сделано, сколько стоило, успешен ли шаг
Аналогия Рабочие инструменты сотрудника: доступ к системе, шаблоны документов и право выполнить операцию.
Что этот слой НЕ делает Не решает, нужно ли действие, и не меняет план. Провал шага возвращается в отдел, а не обходится молча.
Целевая архитектура Реализовано: нет

03 · Путь задачи

Одна задача через всю систему

Вместо абстрактной схемы — путь конкретной единицы работы: от формулировки владельца до ответа, который он получает. Каждый этап подписан слоем, в котором он происходит.

Демонстрация

Три сценария ниже — заранее подготовленные тексты, а не работа системы. Они не выполняются живым AI-сервисом, не обращаются к сети и не меняют никакие данные. Проигрывание этапов нужно только для того, чтобы показать порядок, в котором задача проходит сквозь слои. Весь текст этапов присутствует в HTML и доступен целиком без JavaScript.

Сценарий

Ожидание: выберите сценарий и нажмите «Проиграть»

Этапы можно проходить и без таймера: наведите фокус внутрь списка этапов и используйте стрелки ↑ ↓.

Клиент просит вернуть деньги за непоставленный заказ

Формулировка владельца: «Клиент N просит возврат, поставка сорвана. Разберитесь и скажите, что делаем». Одна единица работы — обращение клиента — проходит все три слоя.

  1. Обращение принято как задача Agentic Владелец передаёт формулировку как есть. AI CEO фиксирует цель: решить обращение клиента и вернуть владельцу вывод, а не переслать письмо в поддержку.
  2. Цель разобрана на подзадачи Agentic Три подзадачи: восстановить факты по заказу (Операции), оценить финансовые последствия возврата (Финансы), подготовить ответ клиенту (Поддержка). Критерий готовности — решение по возврату и текст ответа.
  3. Проверка: разрешено ли это делать Control Слой Control сверяет план с правилами: возврат денег — действие с финансовыми последствиями, поэтому оно требует подтверждения владельца. Сбор фактов и подготовка текста ответа подтверждения не требуют.
  4. Отделы собирают данные Execution Операции поднимают статусы доставки по заказу, Финансы — оплаты и удержания, Поддержка — историю обращений клиента. Учётные данные остаются в шлюзе: модель видит только полученные значения.
  5. Подтверждение владельца Control AI CEO выносит решение на подтверждение: сумма возврата, причина, что уже сделано и что изменится для клиента. Без подтверждения возврат не выполняется.
  6. Один сводный ответ владельцу Agentic Итог формулируется бизнес-языком: что произошло, кто что сделал, какое решение принято и что стоит исправить в процессе, чтобы сорванная поставка не повторилась. Технические вызовы в этот ответ не попадают.

Расходы на маркетинг выросли, а заявок больше не стало

Формулировка владельца: «Тратим больше, заявок столько же. Найдите, где теряется». Задача проходит слои в том же порядке, но исполнители другие.

  1. Задача принята в одной формулировке Agentic Владелец не указывает канал и не формулирует промпт. AI CEO принимает задачу как вопрос о расхождении двух показателей и определяет, какие отделы держат нужные данные.
  2. План: расходы, конверсия, сравнение с рынком Agentic Финансы сводят расходы по каналам за период, Маркетинг — показатели привлечения и конверсии в заявку, Исследования — как менялась стоимость контакта в отрасли. Порядок задан так, чтобы выводы не зависели друг от друга.
  3. Проверка границ: только чтение Control Все три подзадачи — чтение и расчёт, внешних действий нет, поэтому подтверждение не требуется. Любое изменение рекламного бюджета потребовало бы отдельного согласования.
  4. Отделы получают данные из своих систем Execution Платёжные и рекламные источники, счётчики на сайте, публичные данные рынка. Каждый вызов записывается: что запрошено, успешно ли, во сколько обошлось.
  5. Расхождение найдено и проверено Agentic AI CEO сопоставляет результаты отделов и отбрасывает версии, которые данные не подтверждают. Если расхождение не объясняется, задача возвращается в отдел с уточнением, а не закрывается вероятным ответом.
  6. Отчёт с вариантами и их последствиями Agentic Владелец получает объяснение расхождения и два-три варианта действий с последствиями каждого. Перераспределение бюджета система не выполняет — это решение владельца.

Нужно закрыть вакансию в отделе продаж

Формулировка владельца: «Нужен человек в продажи». Задача длинная: она не завершается одним ответом и требует контроля сроков по этапам.

  1. Принята задача с горизонтом в недели Agentic AI CEO фиксирует не ответ, а процесс с этапами и сроками: профиль роли, вакансия, бюджет, поток откликов, выход на работу. Задача остаётся открытой между этапами.
  2. Этапы распределены по отделам Agentic Продажи описывают задачи роли, Люди готовят вакансию и критерии разбора откликов, Финансы подтверждают бюджет, Операции составляют план выхода на работу.
  3. Внешние действия вынесены на подтверждение Control Подготовка текста вакансии подтверждения не требует. Публикация на внешних площадках и любое предложение кандидату — требуют, потому что это действия вовне от имени компании.
  4. Исполнение этапа и сбор откликов Execution Инструменты публикуют вакансию после подтверждения и собирают отклики. Результат этапа сохраняется, поэтому через неделю система продолжает с той же точки, а не начинает разбор заново.
  5. Контроль сроков и эскалация Agentic Если этап стоит дольше планового срока или откликов недостаточно, AI CEO сообщает владельцу, на каком этапе задача застряла и что можно изменить, — вместо того чтобы молча ждать.
  6. Отчёт по найму одним документом Agentic Профиль роли, текст вакансии, критерии разбора, подтверждённый бюджет и план первых задач — одной цепочкой, с указанием, какой отдел что подготовил и где решение осталось за владельцем.

04 · Состав

Восемь отделов в разрезе системы

Для каждого отдела указано, какой слой за него отвечает, что он получает на вход и что обязан вернуть. Отдельные страницы отделов ещё не опубликованы — они появятся позже, поэтому здесь нет ссылок на них.

DEPT·01 / MKT

Маркетинг

страница отдела: скоро
Вход Цель по спросу, данные о продукте, ограничения по бюджету и тону коммуникации
Выход Материалы и каналы привлечения, показатели по кампаниям, вывод о том, что работает
Слой принятия решений Agentic — отдел сам выбирает связку каналов внутри заданных границ
Что требует подтверждения Запуск и оплата рекламных кампаний, любая публичная коммуникация от имени компании
Целевая архитектура Реализовано: нет
DEPT·02 / SLS

Продажи

страница отдела: скоро
Вход Обращения и лиды от маркетинга, условия по продукту, ограничения по скидкам
Выход Квалифицированные обращения, подготовленные предложения, состояние воронки
Слой принятия решений Agentic — приоритизация обращений и оценка вероятности сделки
Что требует подтверждения Отправка сообщения клиенту, условия и скидки вне утверждённого диапазона
Целевая архитектура Реализовано: нет
DEPT·03 / OPS

Операции

страница отдела: скоро
Вход Заказы, обязательства, регламенты и сроки, документы по процессам
Выход Фактический статус исполнения, узкие места, план работ с ответственными
Слой принятия решений Гибрид — известные процессы идут детерминированным графом, отклонения разбирает отдел
Что требует подтверждения Изменение сроков перед клиентом и любые действия, затрагивающие обязательства компании
Целевая архитектура Реализовано: нет
DEPT·04 / FIN

Финансы

страница отдела: скоро
Вход Данные об оплатах и расходах, бюджет, вопросы о рентабельности направления
Выход Расчёты, отчёты по направлениям, оценка последствий решений, прогноз кассы
Слой принятия решений Agentic — оценка вариантов и их последствий, а не только пересчёт цифр
Что требует подтверждения Все финансовые операции и платежи без исключения — только с явного разрешения владельца
Целевая архитектура Платежи — только с разрешения владельца
DEPT·05 / HR

Люди

страница отдела: скоро
Вход Потребность в роли, задачи позиции, ограничения по бюджету и формату занятости
Выход Вакансия, критерии разбора откликов, план онбординга, внутренние инструкции
Слой принятия решений Agentic — разбор откликов по заданным критериям с объяснением оценки
Что требует подтверждения Публикация вакансии, любое обращение к кандидату, решение по человеку
Целевая архитектура Реализовано: нет
DEPT·06 / RES

Исследования

страница отдела: скоро
Вход Вопрос о рынке, конкурентах или данных, границы поиска и срок, к которому нужен ответ
Выход Сводка с указанием источников и даты среза, честная отметка «данных нет» там, где их нет
Слой принятия решений Agentic — выбор источников и оценка достоверности найденного
Что требует подтверждения Ничего: отдел работает только с публичными источниками и не выполняет внешних действий
Целевая архитектура Реализовано: нет
DEPT·07 / DEV

Разработка

страница отдела: скоро
Вход Требование к продукту, описание дефекта, задача на интеграцию с внешней системой
Выход Изменение с проверкой, техническая документация, оценка трудоёмкости и рисков
Слой принятия решений Agentic — выбор способа решения внутри требования
Что требует подтверждения Выкатка изменения в рабочий контур и доступ к продуктивным данным
Целевая архитектура Реализовано: нет
DEPT·08 / SUP

Поддержка

страница отдела: скоро
Вход Обращения клиентов, база знаний, правила тона и границы того, что можно обещать
Выход Ответы по типовым случаям, классификация обращений, системные причины, переданные в отделы
Слой принятия решений Agentic — оценка случая и выбор: ответить, уточнить или передать в другой отдел
Что требует подтверждения Обещания клиенту, компенсации и всё, что выходит за утверждённые правила ответов
Целевая архитектура Восьмой отдел — добавлен к списку из ТЗ

05 · Позиционирование

Слово «операционная система» уже используют. Речь о другом

Ниже — как называют свои платформы компании, которые мы исследовали, и что именно является их единицей работы. Формулировки взяты из публичных страниц и материалов, собранных в исследовании; сравнение описывает предмет каждой платформы, а не её качество.

Beam AI

«The Operating System for AI Transformation»

Единица: процесс

Платформа картирует процессы отдела, оценивает их объём и стоимость и ставит агентов на самые дорогие. Слой называется AgentOS. Это система управления преобразованием процессов компании в автоматически исполняемые.

Источник: research/extra-10.md, раздел о Beam AI (публичная главная страница)

Sierra

«Agent OS»

Единица: клиентский агент

Операционная система для команд клиентского опыта и разработчиков, которые строят агентов: сборка, наблюдение, долгие планы улучшения. Предмет системы — жизненный цикл агента, работающего с клиентами.

Источник: research/extra-10.md, официальный блог-анонс Sierra

Dust

«Multiplayer AI for human-agent collaboration»

Единица: рабочее пространство

Люди и агенты работают в общих пространствах с общим контекстом; на сайте есть раздел Departments. Координация идёт через общее рабочее пространство и упоминания, отдельного центрального руководителя нет.

Источник: research/extra-10.md, dust.tt (главная, блог Series B)

Workato

«Neutral control & execution platform for Enterprise AI»

Единица: интеграция и рецепт

Источник трёхслойной таксономии Control / Agentic / Execution, которую мы используем как каркас. Предмет платформы — управление интеграциями предприятия и слой агентов поверх них.

Источник: research/06-workato.md, страница pricing Workato, 30.10.2026

VOIR AI

«Весь бизнес. Одна AI-операционная система»

Единица: задача бизнеса

Предмет системы — не агент, не процесс и не рабочее пространство, а задача компании от формулировки владельца до сводного ответа. Поэтому в центре стоит AI CEO, который принимает цель и распределяет её по восьми отделам, а не каталог агентов, который владелец собирает сам.

Целевая архитектура, продукт в разработке

Почему это отличие существенное

Если единица работы — агент или процесс, владельцу бизнеса приходится самому разбираться, каких агентов собрать, в каком порядке их запустить и как свести их ответы. Если единица работы — задача бизнеса, то разбор, назначение, порядок и сведение результата становятся обязанностью системы. Именно это различие определяет, кто выполняет управленческую работу: человек с конструктором агентов или платформа с руководителем в центре.

Подробно роль центрального руководителя описана на странице AI CEO

06 · Границы

Что эта система не делает

Границы описаны так же подробно, как возможности: по ним видно, где заканчивается автономия отдела и начинается решение владельца.

Не выполняет платежи и финансовые операции

Финансовый отдел готовит расчёты, отчёты и оценку последствий. Платежи, переводы и любые операции с деньгами не выполняются без явного разрешения владельца — на уровне правил слоя Control, а не как настройка по умолчанию.

Не заменяет владельца в решениях о людях и клиентах

Отделы готовят материалы: вакансию, критерии разбора откликов, текст ответа клиенту, условия предложения. Решение по человеку и обещание клиенту остаются за владельцем или уполномоченным сотрудником.

Не выдаёт догадку за результат

Если данных для вывода не хватает, задача возвращается в отдел с уточнением или уходит на эскалацию владельцу. Ответ «данных нет» считается корректным результатом работы отдела, а не сбоем.

Не обходит защиту сайтов и не нарушает правила сервисов

Сбор информации из внешних источников ведётся легитимно: соблюдаются robots.txt и условия сервисов, агент представляется как автоматизированный клиент. Обход блокировок и маскировка под человека в целевой архитектуре не предусмотрены.

Не работает сегодня

Это целевая архитектура. Ни один из трёх слоёв и ни один из восьми отделов на момент публикации не реализован. Демонстрация пути задачи на этой странице использует заранее подготовленные тексты и не подключена к живому AI-сервису.