Business OS: эволюция от автоматизации к ядру

Почему автоматизация потеряла силу

Workflow-автоматизация (if X → Y) стала коммодити. Собрать цепочку действий за вечер может кто угодно, но вот что происходит потом:

• Пластырь, не решение: ускоряет лишь один шаг, но не делает бизнес умнее
• Хрупкость до отказа: ломается, как только реальность отклоняется от жёсткого сценария
• Слепота в контексте: бот не знает историю клиента, правила компании, риски и теряется при первом же необычном ответе

Пример: Лид пришёл — бот просто отправит письмо. Но не знает, давали ли этому клиенту скидку раньше, кто за него отвечает и стоит ли вообще его развивать.

Важно: автоматизация как конкурентное преимущество мертва. Все уже собрали одинаковые workflows. Ценность теперь в том, что лежит под ними.

Три типа систем: от чат-бота к агенту

Разница огромная, и её нужно понимать:

Проблема современных агентов заключается не в самих моделях, а в отсутствии контекста. У модели ограниченный бюджет внимания (большой контекст деградирует решение). Агентам не хватает бизнес-ориентиров, правил и доступа к истории решений.

Системы хранят данные (скидка 15%), но не хранят решения (почему её дали? кто согласовал? какой был результат?).

Главный сдвиг: от Automation First к Context First

Вот в чём революция. Два подхода диаметрально противоположны:

Вывод крупных платформ (Salesforce Agent Force, HubSpot Briz, ServiceNow, PWC, EY) однозначен: они встраивают агентов внутрь своих платформ и данных, а не продают их отдельно.

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

Business OS: архитектура ядра вашего бизнеса

Business OS — это не CRM, не чат-бот и не случайный набор интеграций. Это слой, где бизнес хранит объекты, события, правила, решения и контекст так, чтобы и люди, и агенты работали из одной картины мира.

Как устроено ядро (снизу вверх)

1. Контекст компании: кто мы, что продаём, правила, цели, миссия
2. Память: документы, история сделок, переписки, аналитика
3. Объекты: лиды, клиенты, сделки, задачи, счета
4. События: логирование того, что произошло и когда
5. Решения: почему скидка 15%? кто согласовал? какие были альтернативы?
6. Правила: что агент может сделать сам, что требует одобрения
7. Вертикальные агенты: узкие специалисты (продажи, поддержка, финансы)
8. «Дирижёр»: распределяет задачи между агентами
9. Интеграции («руки»): доступ к CRM, почте, ERP (1С, SAP, Bitrix24)
10. Governance: права, логирование, эскалация на человека
11. Приборная панель: любой интерфейс (дашборд, Telegram, мессенджер)

Ключевой слой — «Решения»: логирование не просто факта («скидка 15%»), а полного контекста: почему, кто согласовал, на каком основании, какие были риски.

Если нет слоя решений, агенты никогда не научатся, а люди потеряют контроль. Это источник правды.

Вертикальные агенты вместо зоопарка ботов

Вертикальный агент — это не универсальный помощник, а «один агент — один сотрудник» с чёткой ролью: квалификация лидов, проверка счетов, follow-up, поддержка.

Плохая архитектура: зоопарк

• Каждому агенту — своя память и правила
• Быстрый «вау-эффект» на демо, потом хаос
• 10 агентов = 10 фрилансеров без менеджера
• Нет единой картины; агенты не знают о друг друге

Правильная архитектура: единое ядро

• Одно ядро (объекты, события, память, правила) — в основании всего
• Много вертикальных агентов сверху, работающих из общего контекста
• Агенты видят решения коллег и учатся
• Человек видит, что каждый агент делает и почему

Пример: обработка лида за 2 минуты

Лид пришёл → агент:

1. За 2 минуты исследовал компанию клиента (выручка, индустрия, рынок)
2. Оценил профиль (подходит ли нам?)
3. Подготовил персонализированный ответ с кейсом
4. Поставил follow-up на нужную дату
5. Создал задачу в CRM

Без агента это 40 минут ручной работы. С агентом и правильным ядром — 2 минуты плюс одобрение человека.

Баланс автономности: агент предлагает, человек решает

Никакого беззакония. Цепочка всегда контролируема и прозрачна:

1. Агент анализирует ситуацию и предлагает действие
2. Ядро записывает предложение (что, когда, почему)
3. Человек одобряет (все рисковые решения: цены, договоры, деньги, исключения)
4. Инструмент исполняет (отправить письмо, обновить статус)
5. Ядро логирует результат (успех, ошибка, время)

Уровни автономности задаются явно и зависят от рисков:

• Уровень 0: подсказки (агент предложил, человек сам выбирает)
• Уровень 1: подготовка (агент собрал данные, человек решает)
• Уровень 2: автоматизация безопасных действий (отправить письмо-шаблон)
• Уровень 3: полная автономность (только для мелких, обратимых действий и по явным правилам)

Ядро — источник правды. Человек — хозяин рисковых решений. Агент — исполнитель, работающий в границах, которые задал человек.

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

Как начать: минимальное ядро «на коленке»

Не нужно быть корпорацией-гигантом или инвестировать миллионы. Минимальное ядро можно собрать за выходные на базе инструментов, которые уже есть в вашей компании.

Семь компонентов минимального ядра

1. Таблица объектов (Notion, Airtable, Google Sheets): лиды, клиенты, сделки, задачи, счета
2. Лог событий: кто, когда, что сделал, результат, время выполнения
3. Лог решений: скидки, исключения, согласования, обоснования (почему именно эта цена?)
4. Файл правил: что агенту можно сделать самому, что требует согласования, лимиты
5. Инбокс агента: агент создаёт предложения, человек их одобряет или отклоняет
6. Ежедневный бриф: что изменилось, где застряло, какие тренды
7. Один вертикальный агент: для одного ключевого процесса (например, follow-up лидов)

Старт: начинаем с одного процесса, охваченного ядром. Чем больше процессов в ядре — тем больше специализированных «сотрудников»-агентов можно добавить.

Совет: если у вас есть CRM (Bitrix24, Salesforce, HubSpot), вы уже отчасти построили ядро. Нужно только добавить лог решений и первого агента.

Модель внедрения: FDE-инженер + AI-мультипликаторы

Проблема классических подходов к внедрению цела:

• Коробочное решение: «вот ваш готовый GPT» — не работает, потому что не знает вашего бизнеса
• Разработка с нуля: дорого и долго, не все готовы платить за год разработки
• Консультанты: часто уходят с пустыми обещаниями

Решение: Forward Deployed Engineer (FDE) + AI

Модель (по образцу Palantir, но дешевле):

• Forward Deployed Engineer: инженер приходит внутрь компании клиента на 3–6 месяцев, работает с реальными данными и процессами
• AI-агенты как мультипликаторы: делают чёрную работу (интеграция, генерация сценариев, код), а инженер курирует и закрывает «последнюю милю» (доменное знание, правила, исключения)
• Технически: приносится полуфабрикат ядра с готовыми коннекторами (CRM, ERP, мессенджеры). Ценность не в коннекторах (их много), а в онтологии и сценариях поверх них
• Результат: не платформа, а операционная система конкретного бизнеса

Self-Improving System и революция оплаты

Система учится сама

Вот как это работает:

1. Ядро накапливает контекст, события, решения
2. Агенты на этом контексте учатся, уточняют правила, расширяют сценарии
3. Аналитический слой анализирует результаты (маржа, сегменты, удержание) и обновляет плейбуки
4. Система улучшает саму себя в границах, заданных человеком

Чем дольше работает система, тем умнее она становится. Не потому, что переобучилась модель, а потому что накопила смысл.

Новая модель оплаты

Это принципиально революционный сдвиг:

Это честный подход, проповедуемый Y Combinator для AI-компаний. Вместо продажи часов — продаёшь результат.

Вывод: компании, которые переходят на результат-ориентированные контракты, растут в 3–5 раз быстрее, чем те, что остаются на почасовке.