День предпринимателя-автоматизатора: 17 задач с ИИ-агентами без команды

27 мая 2026 года, обычный вторник. Предприниматель Юрий Солар находится на Бали, в 10 часовых поясах от Москвы — без штата, без офиса. За этот день закрыто 17 задач разного масштаба: аномалия в инвестиционной аналитике на 208 миллионов рупий устранена за час, операционная конституция 13 ИИ-агентов обновлена и задеплоена во все 25 файлов инструкций, новый клиент из Москвы получил коммерческое предложение на 460 тысяч рублей — от первого «привет» до PDF-документа за один рабочий день.

Каждая из этих задач ещё год назад требовала бы полной фокусировки команды из трёх человек и нескольких дней работы. Сегодня это один человек, два ассистента и рой ИИ-агентов — мультиагентная система Solar OS, которая работает круглосуточно и закрывает операционку нескольких бизнесов параллельно.

Это не история про «ИИ заменит людей» и не мотивационный пост про продуктивность. Это подробный разбор конкретного рабочего дня как практического кейса по построению автоматизации бизнеса с помощью ИИ-агентов. Что именно происходило, как устроена инфраструктура, почему это работает и как это воспроизвести.

Утро: аномалия в инвестиционной аналитике на 208 миллионов рупий

День начался с дашборда инвесторов — 4bos.online/investor/. Это персональный кабинет для каждого инвестора в портфеле вилл на Бали: P&L по месяцам, статус активных броней, история начислений и выплат. Утром цифры не сошлись. Данные выглядели нелогично — доходность показывала просадку без видимой причины.

Диагностика заняла около 20 минут. Скрипт сбора бронирований из eZee — системы управления объектами недвижимости — периодически помечал активные, живые брони как отменённые. Причина: граничная ошибка в логике сравнения статусов. Когда бронь обновлялась в eZee (менялось количество гостей, дата заезда или сумма), скрипт при следующем запуске воспринимал изменённую запись как «новую отмену» вместо «обновления существующей».

Масштаб искажения: 125 ложных отмен, 208 миллионов рупий аналитики, отображавшейся неверно. Для инвесторов это создавало картину доходности, которая расходилась с реальностью. Не критическая ошибка в деньгах — аналитическая. Но доверие к дашборду это подрывало напрямую.

На восстановление данных ушло ещё 40 минут. Логика скрипта переписана: теперь перед изменением статуса брони система сверяется с актуальными данными из источника eZee и применяет изменение только при подтверждённом несоответствии. Добавлен защитный слой — счётчик аномальных изменений статусов за сессию. При превышении порогового значения скрипт останавливается и логирует причину, вместо того чтобы применять потенциально ошибочные изменения пачкой.

Итого — час от обнаружения до закрытого инцидента с восстановленными данными и защитой от рецидива. В классической схеме «предприниматель → постановка задачи разработчику → приоритизация → выполнение → тестирование → деплой» этот же цикл занял бы 2-3 дня минимум. Прямой доступ к коду и агентный стек для отладки делают такую скорость не исключением, а нормой работы.

«Самое ценное в прямом доступе к системе — не скорость сама по себе, а то, что проблема закрывается в том же контексте, в котором обнаружена. Нет потери контекста при передаче задачи» — Юрий Солар, Solar OS.

Параллельный трек: обновление операционной конституции 13 ИИ-агентов

Пока шла работа с аналитикой, параллельно двигался второй крупный блок — стратегическое обновление всей системы агентов Solar OS.

Что такое конституция ИИ-агентов? Это централизованный документ, который задаёт правила поведения, зоны ответственности, форматы коммуникации и ограничения для каждого агента в системе. По аналогии с корпоративным регламентом — только для ИИ. Без конституции система из десяти и более агентов неизбежно расползается: агенты начинают дублировать функции, противоречить друг другу в коммуникациях с клиентами, выходить за пределы своих зон ответственности.

Полгода Solar OS работала под одну главную задачу: управление портфелем вилл на Бали. В мае 2026 года произошёл стратегический сдвиг: операционное управление виллами передано управляющей компании Vsemdom. Solar OS сменил фокус — финансовые расчёты с инвесторами плюс новый основной продукт, закрытый клуб «Solar — внутрянка».

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

• Конституция v2.0 переписана с нуля: 365 строк, структурированных по секциям — идентичность компании, иерархия агентов, контент-стек, финансовая дисциплина, список запретов
• Автоматический инжект через скрипт constitution_distribute.py во все 25 файлов инструкций агентов
• 6 агентов поставлены на паузу: их задачи перешли к управляющей компании (villas-head, Facebook, телепилот, legacy SEO, design, YouTube)
• 9 новых целей загружены в систему, ориентированных на клуб «Solar — внутрянка»
• Лендинг клуба задеплоен с обновлёнными тарифами: 2 500 ₽/мес или 4 999 ₽/3 мес
• Бот клуба @solar_inside_bot переконфигурирован под два тарифных плана

Аналогия с корпоративным миром: это как за один день переписать регламент компании, централизованно раздать его всем сотрудникам, переопределить KPI нескольких отделов и перезапустить часть функций. С той разницей, что здесь нет совещаний, согласований и часовых встреч. Скрипт автоматической раздачи конституции сделал инжект в 25 файлов за несколько минут — вручную это заняло бы несколько часов с высоким риском рассинхронизации между агентами.

Это хороший пример ключевого системного принципа: когда правила меняются, они должны меняться централизованно и атомарно. Не «обновили 20 файлов из 25», а «обновили все или не обновили ничего».

Почему конституция вообще нужна, а не просто отдельные инструкции для каждого агента? Потому что у 13 агентов, работающих параллельно, неизбежно возникают пересечения. SEO-агент публикует статью — маркетинг-агент должен знать, что это вышло, и не дублировать тему. Telegram-агент адаптирует пост — Threads-агент должен понимать, что CTA ведёт на клуб, а не на услуги. Finance-агент видит входящий платёж — он должен знать, какой тариф клуба активировать. Конституция — это общий язык, который делает координацию между агентами возможной без постоянного ручного вмешательства.

Новый клиент: от первого касания до КП на 460 тысяч рублей за один день

К полудню пришёл входящий лид. Московский риелтор откликнулся на контент — маркетинговая система Solar OS отработала по своему маршруту: регулярные публикации в Telegram-канале @mr_solar_blog и SEO-статьи на 4bos.ru создают постоянный поток людей, которые сами находят контент и пишут напрямую, без холодного outbound.

Через 2 часа после первого сообщения созвон назначен на 16:00. 37 минут разговора. После звонка клиент продиктовал ещё две голосовых записи по 5 минут каждая — дополнительные мысли по задачам, которые он хочет автоматизировать в своём бизнесе.

Дальше включился стек обработки входящего контекста:

1. Вся предыдущая переписка подтянута из CRM-базы данных
2. Запись Zoom-созвона прогнана через локальный Whisper — облачная транскрипция зациклилась на паузах в разговоре и набила «продолжение следует» 70 раз подряд. Локальная модель справилась без сбоев. Это не первый случай, когда локальные инструменты оказываются надёжнее облачных при нестандартных условиях входных данных
3. Голосовые записи по 5 минут транскрибированы отдельно и добавлены к контексту созвона
4. Из собранного контекста сформирована стратегия автоматизации: 3 направления, 6 фаз реализации
5. На основе стратегии составлено коммерческое предложение на 460 тысяч рублей за полный цикл внедрения
6. Отрендерен PDF, отправлен клиенту через Telegram

От первого «привет» до КП в руках клиента — один рабочий день. Для сравнения: в типовой консалтинговой схеме только подготовка коммерческого предложения занимает 2-5 дней — брифинг команды, черновики, внутренние согласования, вёрстка, финальная проверка. В Solar OS весь этот путь сжат: от входящего сообщения система сразу начинает собирать контекст, агент продаж квалифицирует запрос и создаёт карточку клиента, после звонка контекст агрегируется автоматически, и к моменту, когда нужно садиться писать стратегию, 80% информации уже структурировано и доступно в одном месте.

Откуда такая скорость? Не из ИИ-магии, а из системы. Транскрипция звонка автоматическая — не нужно прослушивать запись вручную. Контекст клиента хранится структурированно в базе, а не в голове. Шаблон стратегии и КП отработан на предыдущих десятках проектов. Рендер PDF автоматизирован — не ручная вёрстка в дизайнере. Каждый элемент этой цепочки был когда-то сделан руками, потом задокументирован как процесс, потом автоматизирован. Сегодня вся цепочка работает как единый поток.

Параллельная работа с действующим клиентом: несколько задач за один сеанс

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

Активация новой фазы маркетинга. Клиент оплатил следующий этап работ — запуск радара в VK. Это инструмент, который мониторит районные паблики на предмет тематических обсуждений (боль, симптомы, поиск врача) и подставляет нужные публикации в нужный момент. Не таргетированная реклама с CPM — органическое попадание в момент принятия решения.

Исправление бота записи к врачу. При запросе «покажи слоты по всем мастерам» бот уходил в ожидание без ответа. Причина: race condition при параллельной агрегации данных из нескольких источников одновременно. Логика переписана — запросы теперь выстраиваются в последовательную очередь с таймаутом на каждый.

Переработка логики контент-бота. Бот публиковал видеоклипы не в хронологическом порядке, а в случайной последовательности. Причина: очередь публикаций не учитывала timestamp исходного контента при постановке в очередь. Переписана логика сортировки — контент теперь выходит в правильном порядке.

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

Такой формат работы с клиентом — несколько небольших задач за один сеанс без отдельных часовых встреч по каждому пункту — работает потому, что весь контекст клиента живёт в системе. Новый заход — не «давайте вспомним, где остановились», а «смотрим актуальный список открытых задач».

Ещё одна деталь, которую легко упустить: каждая из четырёх задач этого захода раньше потребовала бы отдельного созвона с брифингом. Итого — четыре встречи по 30 минут, два часа только на «рассказать, что нужно сделать». Сейчас весь заход занял меньше часа включая само выполнение. Не потому что задачи стали проще, а потому что контекст не нужно воссоздавать с нуля каждый раз.

Вечер: тихий сбой внешнего API и системный ответ

Вечером — неожиданная точка контроля. В чате Юрия накопился незамодерированный спам, который не должен был пройти. ИИ-модератор, отвечающий за фильтрацию нежелательных сообщений, возвращал ошибку 404 на каждый запрос.

Диагностика показала: поставщик ИИ-сервиса тихо удалил версию API, которую использовала система. Без уведомления на email, без предупреждения в changelog, без grace period на миграцию — просто перестала отвечать. Переключение на актуальную версию API заняло несколько минут.

Это второй такой инцидент за месяц. Паттерн чёткий и системный: внешние сервисы деградируют без предупреждений. Для системы, в которой десятки компонентов завязаны на внешние API — языковые модели, webhook-эндпоинты, системы управления контентом — это структурная уязвимость, присущая самой архитектуре.

Реакция на конкретный инцидент — это минуты. Но мышление автоматизатора идёт дальше: каждый инцидент — не просто задача «восстановить», а сигнал для системного улучшения. Создана задача на сторожевой бот: скрипт, который будет периодически пинговать все используемые версии внешних API и сигналить при деградации любой из них. Время реакции команды — не «когда заметили по симптомам», а «сразу при изменении состояния источника».

В архитектуре распределённых систем это называется observability — способность системы наблюдать за своим собственным состоянием в реальном времени. Без неё любая автоматизация работает «вслепую» и реагирует только постфактум, когда ущерб уже нанесён.

Конкретный чеклист для любой мультиагентной системы: список всех внешних API с текущими используемыми версиями; расписание автоматических пингов каждой зависимости раз в 10-15 минут; алерт-канал (Telegram-бот, email, любой мессенджер) куда приходит сигнал при деградации сервиса. Это три строки конфига и один небольшой скрипт — а защищает от целого класса проблем, который без мониторинга повторяется снова и снова на ровном месте.

Кроме этого вечером закрыты две инфраструктурные задачи. Приложение Just Press Record для голосовых записей на iPhone подключено к системе диктовок Solar OS — записи с телефона теперь автоматически транскрибируются через Whisper и добавляются в задачи. Устранена ещё одна точка ручного переноса данных. И закрыт баг в копилоте звонков: в режиме наушников система не слышала обе стороны разговора, поскольку виртуальный микшер не маршрутизировал оба аудиопотока корректно. После исправления транскрипции звонков содержат полный диалог обеих сторон.

Принцип за всем этим: «автоматизировано или готово к автоматизации»

17 задач. Один день. Бали. 10 часовых поясов от Москвы.

Когда смотришь на этот день снаружи, кажется, что между его блоками нет никакой связи: инвестиционная аналитика по виллам, обновление конституции агентов, новый клиент из Москвы, медицинский центр в Питере, тихий сбой стороннего сервиса, голосовые записи с iPhone. На самом деле связь одна — и она работает на уровне принципа проектирования, а не расписания.

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

Новый клиент → структурированный контекст в CRM → шаблонная стратегия → автоматизированный рендер КП.
Аномалия в данных → исправленный скрипт с защитой от рецидива → счётчик аномалий как превентивный мониторинг.
Внешний сбой API → переключение за минуты → задача на сторожевой бот.
Голосовые заметки → автоматическая транскрипция → задачи в трекере.

Каждый элемент этих цепочек когда-то был полностью ручным действием. Стал задокументированным процессом. Потом — автоматизированным шагом. Мультиагентная система Solar OS — это не продукт, купленный за один вечер. Это накопленный слой автоматизации, в котором каждый новый кейс добавляет очередной кирпич в фундамент.

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

Как начать строить свою систему автоматизации бизнеса с ИИ-агентами

Система Solar OS строилась не за один день и не с нуля в один прыжок. Но точка входа — значительно проще, чем кажется снаружи.

Шаг 1: аудит задач за две недели. Запишите всё, что делали. Разделите на три категории: повторяется регулярно с похожими входными данными; можно задокументировать как алгоритм с чётким входом и выходом; требует живого человека в каждой итерации по уникальным причинам. Первые две категории — кандидаты на автоматизацию. Третья — пока нет.

Шаг 2: один агент, одна задача. Не пытайтесь сразу построить систему из 13 агентов. Выберите одну задачу с чётким триггером и чётким ожидаемым выходом. Хорошие стартовые точки: ответы на типовые вопросы в Telegram-чате, первичная квалификация входящих лидов из форм, черновики стандартных документов по шаблону. Один агент, запущенный и откалиброванный на реальных данных — это опыт, который масштабируется на следующие.

Шаг 3: конституция с первого дня. Даже для одного агента напишите правила: что он делает, что категорически не делает, как себя ведёт в нестандартных ситуациях, кому эскалирует. Кажется излишним в начале — становится незаменимым через три месяца, когда поведение агента начинает расходиться с ожиданиями и вы не можете быстро понять почему.

Шаг 4: мониторинг внешних зависимостей с первого дня. Каждый внешний API, каждый сторонний сервис — потенциальная точка тихого отказа. Два инцидента за месяц с молча удалёнными версиями API — это не невезение, это структурное свойство внешних сервисов. Заложите наблюдаемость в архитектуру с первого дня, не после второго или третьего инцидента.

Шаг 5: инциденты как системные улучшения. Каждый сбой — сигнал об уязвимости в архитектуре. Привычка переводить «что не сработало сегодня» в «что теперь работает надёжнее навсегда» — это и есть операционное мышление автоматизатора. Это именно то, что отличает систему, которая становится надёжнее с каждым месяцем, от системы, которая просто ломается и чинится в одном и том же месте снова и снова.

Всё из этого дня — реальные артефакты из живой системы: скрипты сбора данных, конституция агентов, архитектура стека, промпты, шаблоны КП и стратегий — живут в закрытом клубе «Solar — внутрянка». Не учебные материалы и не курс. Рабочие файлы, которые сегодня крутятся в проде. Формат — «бери и адаптируй под свои задачи». От 2 500 ₽/мес: https://4bos.ru/inside/

Если хотите разобраться в деталях архитектуры мультиагентных систем или посмотреть другие разборы — другие материалы в блоге 4bos.ru.

И последнее, что важно понять про такой день: он не уникален. Это не «хорошо получилось», это стандартный рабочий день с нормальной нагрузкой. Когда система выстроена правильно, 17 задач разного масштаба — это просто ещё один вторник. Не подвиг, не перегрузка — операционная норма. Именно к этому ведёт последовательная автоматизация: не к «я работаю меньше», а к «я делаю больше того, что важно, при том же количестве часов».