Когда мы начали встраивать AI-агента в BPM-платформу, перед нами встала знакомая enterprise-задача: десятки клиентов, у каждого своя онтология, словарь, роли и ограничения безопасности. В одной компании «заявка на покупку» — это «реестр заявок», в другой — «карточкой закупки». Один клиент работает на изолированном контуре с локальной моделью, другой не даёт ассистенту доступ к почте и репозиториям. 

Традиционный ответ — форк репозитория под каждого клиента — при масштабировании превращается в ад поддержки: багфиксы не попадают автоматически, стоимость растёт экспоненциально, качество падает. Мы решили эту проблему иначе: per-tenant overlay позволяет кастомизировать поведение агента без изменения кода.

Что такое overlay

Overlay — это конфигурация, которая загружается после базовой и переопределяет её значения. Это похоже на CSS-override для веб-страниц: есть базовый стиль, а поверх него можно добавить свои правила, которые меняют цвет, шрифт или отступы, не трогая саму разметку. В нашем случае базовая конфигурация описывает стандартное поведение AI-агента для production-версии, а overlay клиента меняет то, что нужно именно ему.

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

Точки расширения

Мы выделили четыре точки расширения, которые покрывают 90% кастомизаций, необходимых клиентам. Эти границы позволяют менять поведение агента без изменения логики кода.

Первая точка — persona_paths. Это конфигурация соответствия функциональных областей и файлов с промптами. В production-версии агент может использовать стандартные промпты для проектного управления, HR и финансов. На клиентском стенде можно переопределить пути к этим файлам, чтобы использовать кастомные промпты, учитывающие терминологию и специфику клиента. Например, вместо базового промпта для проектного менеджера загружается файл с описанием процессов и терминологии конкретной организации.

{
 "crm": [
 "clients/{client}/boxes/crm/persona-sales.md", // Кастомная экспертиза для CRM
 "boxes/crm/persona-analytics.md" // Стандартная экспертиза
 ]
}

Пример подмены промпта на кастомный уже на клиентской инсталляции

Вторая точка — root_section_map. Это маршрутизатор запросов по категориям. Когда пользователь задаёт вопрос, система определяет, к какой функциональной области он относится, и направляет его в соответствующую «коробку». В production-версии конфигурация может содержать несколько десятков записей: «управление проектами» идёт в коробку pm, «подбор персонала» — в hr, «бюджетирование» — в finance. 

{
"sales": "crm", // Категория «Продажи» → коробка CRM
"clients": "crm", // Категория «Клиенты» → коробка CRM
"meetings": "crm", // Категория «Встречи» → коробка CRM
"proposals": "library" // Категория «Коммерческие предложения» → Библиотека
} 

Пример маршрутизации категории

На крупном клиентском стенде конфигурация может содержать несколько тысяч записей, каждая из которых переопределяет маршрутизацию под терминологию клиента. 

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

• поиск по коду, 

• работа с почтой, 

• веб-поиск, 

• продажи, 

• персональные утилиты, 

• локальные MCP-серверы, 

• контейнеры, 

• интеграция с 1С, 

• доступ к данным, 

• работа с персонами. 

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

Четвёртая точка — model_config. Параметры модели, которые можно переопределить под клиента: провайдер, размер контекстного окна, алиас модели. В production-версии по умолчанию используется облачный провайдер вроде OpenAI с определённым контекстным окном. На клиентском стенде можно переключиться на локальный вывод, увеличить или уменьшить контекст, использовать собственную модель вместо стандартной.

Как это работает на практике

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

Overlay-конфигурация для этого клиента выглядит так:

• В persona_paths прописаны пути к кастомным промптам для проектного управления, HR, финансов и документооборота. 

• В root_section_map добавлены маршрутизации для тысяч терминов, которые используются внутри организации. 

• В disabled_toolsets перечислены восемь наборов инструментов, которые нужно отключить. 

• В model_config указан провайдер local-inference, увеличенный контекст и алиас кастомной модели.

Роутер берёт ID категории вопроса, находит его в конфигурации из 3000 записей и направляет в нужную коробку. Затем через persona_paths выбирается промпт — сначала система ищет кастомный файл в директории клиента, а если его нет, использует базовый. Далее фильтруется набор инструментов и финально переопределяются параметры модели.

Как бороться с расхождениями

Главный риск кастомизации — клиентский стенд постепенно расходится с production и перестаёт принимать обновления. Чтобы этого не произошло, мы контролируем метрики совпадения кодовой базы по хэшу SHA-256. Из основных модулей агента на клиентском стенде 95% файлов полностью совпадают с production-версией. Только три файла имеют намеренные расхождения, и каждое такое изменение закреплено в deploy-tool как патч.

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

Процесс деплоя при выпуске новой версии выглядит так: копируется production-код, применяется overlay клиента (конфигурация, промпты, патчи), запускается health-check. При следующем обновлении production свежий код автоматически подтягивается на все клиентские стенды — overlay накладывается поверх новой базовой версии.

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

Что можно и что нельзя менять

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

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

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

Метрики и roadmap

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

Per-tenant overlay позволяет одной кодовой базе работать на десятках клиентских площадок. Он закрывает 90% потребностей enterprise-кастомизации. Результат: клиент получает адаптированного ассистента, мы поддерживаем единый продукт.