Здесь мы решаем несколько практических вещей.
Во-первых, договариваемся о словах. Что называем ИИ-Напарником, чем он отличается от функционального агента, где проходит граница между автономией и контролем человека.
Во-вторых, даём читателю короткий ответ на три вопроса: что мы строим, кому это нужно и какой раздел открыть следующим.
В-третьих, отделяем готовые материалы от черновиков. Это важно для пресейла: неприятно вынести к заказчику мысль, которая ещё держится на честном слове.
В-четвёртых, держим набор формулировок, которые можно переносить в слайды, письма, демо и внутренние документы без переписывания.
Эта wiki не задумана как книга, которую читают от начала до конца. Это рабочая база фактов и формулировок. Из неё собираются производные артефакты под конкретного стейкхолдера: коммерческого директора, CIO, директора по категорийному менеджменту, архитектора, пресейл-команду или будущего пользователя.
Категорийный менеджер крупной торговой сети часто работает в одиночку, хотя вокруг него много систем, отчётов и людей. Он отвечает за P&L категории, ведёт переговоры с поставщиками, следит за полкой, оборотом, маржой и промо. Решения приходится принимать быстро, с неполной картиной и под давлением.
Проблема не в том, что данных нет. Данных много. Проблема в том, что они разбросаны, требуют ручной сборки и редко превращаются в спокойного собеседника, который понимает контекст, помнит прошлые решения и может сказать: «здесь цифры не сходятся, давай проверим».
Та же история повторяется в логистике, ценообразовании, маркетинге и операционной работе.
Корпоративная мультиагентная ИИ-платформа даёт менеджеру новую рабочую модель. В ней есть два слоя:
ИИ-Напарник
Персональный агент конкретного сотрудника. Он помнит контекст, приоритеты и историю решений, работает как единая точка входа к корпоративным данным и системам, сам подключает нужных функциональных агентов и помогает увидеть следующий шаг.
Функциональные агенты
Специализированные ИИ-исполнители для отдельных классов задач: анализ продаж, подготовка к переговорам, OOS, ценообразование, поиск по базе знаний, алерты. Обычно менеджер не вызывает их напрямую. Это делает Напарник, когда понимает, какая помощь нужна.
За этими двумя слоями стоят корпоративная память, интеграции с внутренними системами, безопасность, аудит и правила работы агентов.
Концепт описан vendor-neutral. LLM-провайдеры, агентные runtimes, MCP-коннекторы, мессенджеры и другие технологии считаются заменяемыми компонентами. OpenClaw в документах используется как один из возможных вариантов реализации, потому что он близко ложится на описанную модель. Это не обязательный выбор.
Бизнес получает более быстрые решения, меньше ручной координации, более доказательные коммерческие гипотезы и память о том, как команда принимала решения раньше. Последний пункт особенно болезненный: сейчас большая часть экспертизы уходит вместе с сильными сотрудниками.
Wiki пишется для четырёх групп. У каждой свои вопросы, свой уровень деталей и свой терпимый объём технического языка. Перед сборкой любого артефакта нужно понять, для кого он делается.
Бизнес-заказчики ритейла
Коммерческий директор, директор по категорийному менеджменту, операционный директор торговой сети.
Им нужно быстро понять боль, бизнес-эффект, границы пилота и то, почему это не очередная «магия с ИИ».
Открывать сначала: 01-vision, 02-partner, 04-usecases, 07-roadmap.
Технические лиды заказчика
Архитекторы, CIO/CDO, ИТ-безопасность, compliance.
Их интересуют реализуемость, интеграция в текущий ИТ-контур, права доступа, аудит, безопасность данных и отсутствие vendor lock-in.
Открывать сначала: 05-architecture, 06-integrations, разделы про безопасность и governance.
Внутренние коллеги Glowbyte
Пресейл, архитекторы, аналитики, руководители практик.
Им нужно понимать позиционирование Glowbyte, состав MVP, переиспользуемые блоки, зоны риска и то, что ещё надо дописать перед встречей с заказчиком.
Открывать можно весь концепт. Особенно полезны 01-vision, 03-agents, 07-roadmap.
Конечные пользователи
Категорийные менеджеры, логисты, прайс-менеджеры и другие сотрудники, которые будут работать с платформой.
Их волнуют простые вещи: как это поможет лично мне, не будет ли система контролировать каждый шаг, не заменит ли она меня, можно ли ей доверять.
Для них лучше готовить отдельные артефакты на базе 02-partner и 04-usecases: демо, сценарий «один день с Напарником», короткие истории.
Концепт разнесён по семи тематическим документам плюс эта стартовая страница.
Каждый документ ведётся в два слоя.
Для первой версии нам важнее сильный нарратив, несколько понятных сценариев, 4–5 хорошо описанных агентов и нормальный путь к пилоту. Равномерно глубокая проработка всех разделов сейчас не нужна. Она только замедлит работу.
Маршрут зависит от роли и времени. Ниже пять типовых вариантов.
Этого хватит, чтобы понять общую идею без технических деталей.
Подходит для разговора на 15–20 минут с коммерческим или операционным руководителем.
Маршрут для архитекторов, CIO и ИТ-безопасности.
Маршрут для пресейла, архитекторов и руководителей практик Glowbyte.
Так собираются презентации, one-pager’ы, демо-сценарии и письма под конкретного стейкхолдера.
Здесь собраны термины, которые во всех документах концепта используются в одном смысле. Если где-то термин берётся уже или шире, это должно быть сказано прямо в соответствующем разделе.
ИИ-Напарник
Partner Agent. Персональный ИИ-агент конкретного сотрудника. Он знает контекст, приоритеты и историю решений, даёт единый вход к корпоративным данным и системам, координирует функциональных агентов и может сам инициировать действия. Один сотрудник — один Напарник.
Функциональный агент
Специализированный ИИ-исполнитель для одного класса задач: анализ продаж, подготовка переговоров, поиск по базе знаний, мониторинг аномалий. У него узкая инструментальная политика и доступ только к тем данным, которые нужны для работы. Обычно его вызывает не сотрудник, а ИИ-Напарник.
Корпоративная мультиагентная ИИ-платформа
Управляемая среда, где работают ИИ-Напарники сотрудников, функциональные агенты, корпоративная память, интеграции с системами, безопасность и аудит. Она соединяет персональный пользовательский опыт с организационным контролем.
Оркестрация агентов
Сценарий, в котором ИИ-Напарник делегирует задачу одному или нескольким функциональным агентам, ждёт результаты и собирает итоговый ответ для сотрудника. Несколько агентов могут работать параллельно.
A2A (Agent-to-Agent)
Прямое общение между агентами. Например, Напарник одного сотрудника обращается к Напарнику другого сотрудника или к функциональному агенту соседней команды. Такое общение управляется политиками: кто, кому и по какому поводу может писать.
Организационная память
Слоистое хранилище контекста и опыта. В него входят корпоративная база знаний, личная память агента о решениях сотрудника и коллективная память о рабочих паттернах команды.
Human-in-the-loop
Принцип, при котором рискованные действия проходят через явное подтверждение человека. Сюда относятся внешние коммуникации, изменения в учётных системах, платежи, договорные изменения, листинг и делистинг. Даже если агент технически может сделать действие сам, последнее слово остаётся за сотрудником.
Tool policies
Инструментальные политики. Это правила платформы, которые определяют, какие инструменты доступны конкретному агенту: чтение данных, запись, отправка сообщений, веб-доступ, межагентское общение. Эти правила работают независимо от инструкций модели.
MCP и MCP-like подходы
Model Context Protocol. В концепте это общий интеграционный паттерн: один коннектор подключает внешнюю систему, а пользоваться им могут разные агенты в рамках своих прав.
Tier делегата
Уровень автономии агента. Tier 1 — чтение и черновики. Tier 2 — отправка или изменение после разрешения человека. Tier 3 — автономные действия по расписанию или триггеру в заранее согласованных границах.
Shadow AI
Стихийное использование внешних ИИ-сервисов сотрудниками: личные ChatGPT-аккаунты, переводчики, AI-расширения. ИТ-служба обычно не видит, какие данные туда уходят. Платформа даёт управляемую корпоративную альтернативу.
OpenClaw
Один из возможных вариантов реализации мультиагентной среды. Документы концепта могут ссылаться на OpenClaw как на референсную платформу, но сам концепт остаётся vendor-neutral.
Чтобы wiki не превратилась в склад черновиков, у неё есть несколько правил. Они простые, но без них текст быстро расползётся.
Статусы нужны, чтобы быстро понять, какой материал уже можно использовать, а какой ещё лучше не показывать заказчику.
draft
Каркас, черновые формулировки, незакрытые вопросы. Для внутренней работы.
core
Основное содержание готово. Материал можно брать в презентации и обсуждения, хотя точечная полировка ещё возможна.
ready
Финальная версия. На неё можно ссылаться как на основной источник формулировок и фактов.
| Документ | Статус | Комментарий |
|---|---|---|
| index.mdx / README.md | core | Фиксирует язык, аудитории и правила работы с wiki. Дополняется по мере развития концепта. |
| 01-vision | core | Развёрнутый нарратив на каркасе четырёх эпох. Есть pitch-points для устных презентаций. Vendor-neutral. |
| 02-partner | draft | Скелет создан, требуется наполнение. |
| 03-agents | draft | Скелет создан. Ближайший фокус — 4–5 агентов для MVP. |
| 04-usecases | draft | Скелет создан. Нужны 3–4 подробно описанных сценария. |
| 05-architecture | draft | Скелет создан. Уровень концептуальный, без глубокого solution design. |
| 06-integrations | draft | Скелет создан. Нужны интеграционные паттерны и MVP-набор. |
| 07-roadmap | draft | Скелет создан. Документ должен связать агентов, сценарии и интеграции в этапы внедрения. |
Ниже решения, которые мы принимаем как стартовую линию. Это не догмы. При работе с конкретным заказчиком они могут измениться, но внутри wiki мы отталкиваемся от них.
Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только в контексте конкретного заказчика.
Сейчас концепт опирается на внутренние материалы Glowbyte:
ai-partner slides.txt).project-structure.md).Внешние источники добавляются не общим списком, а рядом с конкретными тезисами в соответствующих документах. Так проще проверить, на чём держится утверждение.
Версия: 2026-05-01. Поддерживается Алексеем Чвановым, департамент Retail, Glowbyte.