ИИ-агенты для управления бизнесом: как Solar Property автоматизировала 16 вилл на Бали

В начале 2026 года Solar Property управляла 16 активными виллами на Бали с командой из двух балийских сотрудников и без единого офиса. Бронирования приходили через Airbnb и Booking.com, синхронизировались в eZee PMS, финансовые данные агрегировались в реальном времени — и всё это без менеджеров в офисе с 9 до 18.

Это не потому что мы нашли уникальных людей или магическую SaaS-платформу. Это потому что с февраля 2026 года операционку ведут ИИ-агенты — 18 специализированных систем на базе Claude, каждая со своей зоной ответственности. За пять месяцев работы система обработала 444+ бронирований, синхронизирует цены на двух OTA-платформах, обрабатывает входящие лиды и публикует контент в шести каналах.

Ниже — честный разбор: что было до, как выстроена архитектура, что работает и что ломалось. Без «будущее уже наступило» и без обещаний, что у вас так же получится за неделю.

Что происходило до автоматизации

Управление арендным бизнесом с несколькими объектами — это не сложно технически. Это сложно операционно: много мелких задач, которые нельзя делегировать один раз и забыть.

Типичный день: гость пишет через Airbnb с вопросом про включённый завтрак — ответ уходит через 25-40 минут, потому что координатор занят другим объектом. Другой гость запрашивает ранний заезд в WhatsApp — этот вопрос теряется в потоке сообщений. Параллельно уборщики на вилле хотят уточнить время следующего чекаута — приходится лезть в PMS, сверять, отвечать вручную.

По данным Harvard Business Review, компания, отвечающая на обращение в течение первого часа, в 7 раз чаще конвертирует лид по сравнению с той, что отвечает через сутки. В туристической аренде конкуренция выше: человек ищет виллу на Бали, открывает 5-8 вариантов одновременно. Кто отвечает первым — получает бронь.

При потоке 80-100 входящих обращений в месяц и двух сотрудниках на все объекты физически невозможно отвечать всем быстро. Плюс разница часовых поясов: часть запросов приходит ночью по балийскому времени, когда я сам нахожусь в другом регионе.

Финансовая непрозрачность

Отдельная боль — финансы. Расходы фиксировались в WhatsApp-переписках, выручка агрегировалась из eZee раз в неделю, итоговый P&L по каждой вилле собирался руками в конце месяца — занимал полный рабочий день. Инвесторы, вложившие в объекты, периодически спрашивали статус — конкретного ответа дать быстро было нельзя.

Архитектура: 18 агентов, 6 отделов

Решение, которое мы выбрали, — не автоматизировать задачи по одной, а выстроить структуру, которая имитирует работу полноценной компании с отделами и иерархией.

Система устроена по уровням:

• CEO-агент — получает задачи, распределяет по отделам, собирает результаты
• 6 руководителей отделов: продажи, маркетинг, операции по виллам, финансы, CTO, продукт
• 18 субагентов-исполнителей — по 2-4 на каждый отдел, у каждого узкая задача
• QA-агент — проверяет контент перед публикацией во внешние каналы

Все агенты построены на Claude от Anthropic. Выбор не случайный: Claude показывает высокую точность при следовании сложным инструкциям с множеством условий. Это критично, когда агент должен в режиме реального времени решать: это задача для Sales или для Villas Ops? требует ли это подтверждения или можно сделать самостоятельно?

Принцип автономии: что агент делает сам, что требует согласования

Критически важная часть архитектуры — матрица автономии. Без неё агент либо спрашивает разрешения на каждый шаг (бесполезен), либо делает то, что не следовало (опасен).

У каждого действия есть класс:

• AUTO-1: делает сам, логирует. Ответить на входящий лид, опубликовать пост по утверждённому брифу.
• AUTO-N: dry-run на одном объекте, потом масштаб. Массовая рассылка, правка описаний всех вилл.
• NEED-NOTIFY: делает сам, предупреждает за 10 секунд. Публикация в Instagram.
• NEED-APPROVAL: создаёт задачу, ждёт подтверждения. Изменение цены виллы более чем на 30%, расходы выше порога.
• HARD-STOP: только я лично. Удаление таблицы в базе данных, финансовые переводы.

Эта классификация — не формальность. Без неё агент будет либо парализован, либо наломает дров. За пять месяцев мы несколько раз переписывали правила после реальных инцидентов — о которых подробнее ниже.

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

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

Ещё один принцип: каждая инструкция агента — версионированный документ в системе контроля версий. Изменение правила поведения агента фиксируется как коммит с датой и причиной. Это позволяет понимать, почему агент ведёт себя так, а не иначе, и откатить изменение, если оно привело к нежелательному результату.

Как работает автоматизация бронирований

Сердце операционки — интеграция с eZee PMS (платформа Yanolja). Система подключена к Airbnb и Booking.com через официальный API. Данные синхронизируются каждые 15 минут.

Когда приходит новое бронирование, запускается автоматическая цепочка:

1. eZee фиксирует бронь и передаёт данные в базу данных
2. Агент Villas Ops проверяет: нет ли двойного бронирования, правильная ли стоимость, совпадает ли канал с ожиданием
3. При аномалии (нулевая стоимость, нестандартная длина пребывания, несоответствие канала) — алерт уходит в рабочий чат координатору
4. Координатор видит только исключения, требующие решения, а не весь поток бронирований

До автоматизации координатор самостоятельно просматривал каждую бронь в PMS. Теперь занимается только нестандартными случаями.

Обработка входящих лидов

Параллельно с PMS работает агент продаж. Когда потенциальный гость пишет напрямую — в Telegram, Instagram или через форму на сайте — агент отвечает в течение нескольких секунд.

Агент ведёт диалог: уточняет даты, количество гостей, предпочтения по объектам, бюджет. Если запрос квалифицирован — формирует карточку «показ согласован» с кнопками для координатора. Финальное решение о показе виллы — за живым человеком.

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

Финансовая автоматизация: P&L без бухгалтера

Финансовый блок — один из самых сложных в реализации, но и один из самых ценных по результату.

Архитектура следующая:

• Все расходы фиксируются через Telegram-бот: сотрудник отправляет сообщение с суммой и категорией, бот записывает в базу данных
• Выручка агрегируется из eZee по departure-based принципу: доход фиксируется по дате выезда гостя
• Раз в месяц скрипт строит P&L по каждой вилле отдельно
• Инвесторы видят живой дашборд через защищённый API: баланс, начисленные дивиденды, историю выплат

Departure-based revenue — осознанный выбор. Он совпадает с реальным cash flow и с логикой начисления комиссий. При booking-based подходе возникала путаница: деньги на счёте ещё не пришли, а в отчёте уже числятся.

Детализация расходов по объектам

Каждая транзакция получает атрибуты: код виллы, категория расхода, период. Это позволяет видеть не только общую прибыльность портфеля, но и ROI каждого конкретного объекта.

Некоторые расходы пересекаются между объектами или между личными и бизнес-нуждами. Такие позиции размечаются явно и попадают в opex только в нужной пропорции. До автоматизации эта детализация была практически невозможна: слишком долго собирать вручную. Теперь она есть по умолчанию — данные структурированы с момента ввода.

Контент-машина: 6 платформ без маркетолога

Параллельно с операционкой работает контент-конвейер. Solar Property публикует материалы в Telegram-каналах, Instagram, Threads, VK, Facebook и на YouTube — из одной точки управления.

Весь процесс:

1. Идея приходит в любом формате: голосовое сообщение, текст, ссылка на референс
2. Ассистент транскрибирует и передаёт в маркетинговый блок агентов
3. Marketing-head создаёт мастер-копию текста — единый источник правды
4. QA-агент проверяет: нет AI-клише, нет непроверенных фактов, стиль соответствует бренду
5. Агенты публикации размещают адаптации на всех платформах параллельно
6. Метрики (просмотры, вовлечённость, переходы) собираются ежедневно

Ключевой принцип: мастер-копия первична. Агенты адаптируют под формат платформы (длина текста, хештеги, структура), но не переписывают содержание. Расхождение с мастер-копией — автоматический реджект QA.

Каскадное удаление

Если пост нужно удалить на одной платформе — агент инициирует удаление на всех остальных. Связи между публикациями хранятся в базе данных. Это избавляет от ситуации, когда пост убран в Instagram, но продолжает жить в VK.

Что ломалось и чему это нас научило

Пять месяцев работы — это не только успехи. Три реальных провала и что мы из них вынесли.

Провал 1: Агент без памяти о диалоге

На старте агент продаж не имел доступа к истории переписки. Гость, который писал месяц назад и вернулся с новым вопросом, получал ответ как новый контакт. Агент снова спрашивал даты, количество гостей — то, что человек уже сообщал.

Решение: добавили базу истории диалогов, агент обязан читать последние 10 сообщений перед ответом. Это позволило делать персонализированные follow-up: «в прошлый раз вас интересовала вилла с бассейном-инфинити, сейчас есть свободный период».

Провал 2: Временная зона без явной настройки

Первая версия крон-задач не учитывала часовой пояс Бали (UTC+8). Уведомления операционной команде уходили в 03:00 WITA. Люди просыпались и видели пачку сообщений из ночи — все срочные.

Решение: во все временные триггеры добавлена явная timezone-конфигурация. Каждое уведомление отправляется в рамках рабочего окна получателя. Потребовало пересмотра 11 крон-задач.

Провал 3: Дублирование задач в чате координации

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

Решение: anti-dedup проверка по уникальному идентификатору задачи перед каждой публикацией. Один task_id — максимум одно сообщение плюс один напоминатель через 6 часов при отсутствии ответа.

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

Мониторинг: как мы видим, что система работает

Децентрализованная система агентов создаёт новую задачу: как убедиться, что всё работает? Если в операционке участвует живой менеджер, он сам замечает аномалии. Если всё автоматизировано — нужен отдельный слой наблюдения.

В Solar Property мониторинг выстроен на нескольких уровнях:

• Логи каждого действия. Любое автоматическое действие агента записывается в лог с временной меткой, результатом и ID задачи. Это позволяет ретроспективно разобрать любой инцидент.
• Ежедневный дайджест. Раз в день агент маркетинга готовит краткую сводку: топ-3 поста по вовлечённости, что провалилось, рекомендации. Это для внутреннего анализа — Юрию не пушится, хранится в топике для ретроспективы.
• Алерты на аномалии. Watchdog-агент мониторит ключевые метрики: количество сообщений в рабочий чат (норма — не более 50 в день), дублирование задач, таймауты API-вызовов. При выходе за границы — алерт.
• SEO-дайджест. Каждое утро в 08:00 WITA собираются метрики по сайту из Google Search Console: клики, показы, средняя позиция, топ растущих ключей.

Главный инсайт по мониторингу: нельзя следить за всем. Нужно определить 5-7 ключевых метрик, отклонение которых сигнализирует о проблеме. Все остальные данные — в лог для разбора по запросу.

За пять месяцев работы watchdog дважды поймал ситуации, которые без мониторинга стали бы полноценными инцидентами: один раз — петля задач между двумя агентами, которая создавала по 200+ записей в час; второй раз — агент контента начал публиковать дубли из-за ошибки в логике dedup.

Инструменты в стеке

Полная технологическая база системы:

• Claude (Anthropic) — базовая языковая модель для всех агентов. Разные версии (Sonnet, Haiku) в зависимости от сложности задачи.
• Python 3.11 — все скрипты, боты, интеграции. Ruff — линтер, обязателен перед каждым деплоем.
• PostgreSQL — основная база данных: бронирования, финансы, лиды, метрики контента, история диалогов.
• Telegram Bot API — основной канал коммуникации агентов с командой. Отдельные боты для операционки, финансов, контента.
• eZee PMS / Yanolja API — официальный API системы управления. Синхронизация с OTA каждые 15 минут.
• Airbnb + Booking.com — OTA-каналы через eZee.
• n8n — визуальный оркестратор для части простых автоматизаций, где LLM избыточен.
• systemd — управление сервисами. Каждый бот-агент — отдельный сервис с автоперезапуском.

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

Как начать: практический порядок действий

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

Шаг 1: Инвентаризация повторных задач

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

Шаг 2: Найдите самую дорогую задержку

Из списка выберите одну задачу, где задержка стоит денег или клиентов. Для нас это был первый ответ на лид по аренде виллы. Для интернет-магазина — обработка возврата. Для клиники — напоминание о визите. С этой задачи начинайте — она даст измеримый результат.

Шаг 3: Сначала скрипт без LLM

Напишите простой Python-скрипт с жёсткой логикой «если X — делай Y». Убедитесь, что бизнес-логика правильная. LLM добавляйте только после того, как механика работает без неё. Это важно: LLM не исправит плохую бизнес-логику — она её усилит и сделает менее предсказуемой.

Шаг 4: Определите матрицу автономии

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

Шаг 5: Стройте иерархию с самого начала

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

Частые ошибки при первом запуске

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

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

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

Ошибка: доверить агенту задачи с необратимыми последствиями без проверки. Удаление данных, финансовые переводы, публичные заявления от имени компании — это всегда HARD-STOP. Не потому что агент плохой, а потому что цена ошибки слишком высокая. Автоматизируйте сначала то, что легко обратимо.

Ошибка: не объяснять агенту «почему», только «что». Claude лучше справляется с задачами, когда понимает контекст и цель. Инструкция «не пиши клиенту после 22:00» работает хуже, чем «не пиши клиенту после 22:00 — это балийское время, наши гости часто в другом часовом поясе, и ночные сообщения воспринимаются как спам». Причина помогает агенту принять правильное решение в ситуации, которую вы не предусмотрели.

Итоги

Solar Property сегодня — это 16 активных вилл на Бали, два человека в операционной команде и 18 ИИ-агентов, которые делают всё остальное. Не потому что мы переизобрели бизнес-процессы. Потому что взяли существующую структуру компании — отделы, роли, правила — и перенесли её на агентов.

Юрий Солар, основатель Solar Property: «Я не искал способ сократить людей. Я искал способ не нанимать больше людей по мере роста портфеля. Разница принципиальная: в первом случае ты экономишь, во втором — выстраиваешь масштабируемую модель.»

Главное, что мы поняли за эти месяцы: автоматизация не убирает сложность, она её перемещает. Раньше сложность была в операционке: кто и когда это сделает. Теперь — в проектировании системы: как агент должен принимать решения в этом сценарии. Второй тип сложности решается один раз и держится долго. Первый возвращается каждый день.

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

Если вы управляете бизнесом с повторными процессами и хотите разобраться конкретно — напишите мне в Telegram @yuriy_solar. Не для продажи консалтинга, а потому что конкретный разбор вашего случая интереснее абстрактной теории.

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