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

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

Оценки в Langfuse по retrieval и ответам, CSAT, сравнение каждой новой версии флоу с предыдущей перед релизом и еженедельный цикл улучшений на реальных диалогах. RAG-скор, выросший с менее 0,6 до 0,9, — то доказательство, которое я ищу.

Прежде чем строить, я смотрю на лучший продукт в категории — Intercom для виджета поддержки, Zendesk для CRM — и записываю, что значит обойти его для этого клиента. Затем блоки, майлстоуны и QA-тесты следуют этому списку.

Около 50 операторов поддержки вручную обрабатывали примерно 4 000 тикетов в день, с пиками более сотни диалогов за пять–десять минут. При перегрузке первый ответ занимал до 18 минут, а удовлетворённость клиентов держалась на 2,5 из 5. Каждый тикет, включая тривиальные, стоил человеческого времени, а знания, нужные для ответа, были разбросаны по CRM и годам истории сообщений. Задача: виджет, который сам отвечает на большинство тикетов на языке клиента и оставляет людям только случаи, требующие суждения. Бенчмарк, который я задал до начала работы, — Intercom.

Чат-виджет на сайте клиента, развёрнутый через Google Tag Manager, который понимает запрос на любом языке, проверяет аккаунт клиента, если тот авторизован, отвечает из базы знаний, построенной на собственной CRM клиента и истории сообщений, и передаёт сложные случаи оператору в Zendesk с полной расшифровкой и контекстом аккаунта. n8n оркестрирует основной флоу, эскалацию и отчётность; LangGraph выполняет циклическую логику по каждому интенту, так что граф шаг за шагом решает, ответить, уточнить, проверить или эскалировать. У каждого агента свой промпт, GPT-4o mini как основная модель и Gemini 2.5 через OpenRouter как запасная. В Pinecone хранится база знаний, в MongoDB — общая память, в Redis — кэш. Серверы я настроил и защитил сам: всё работает в Docker на собственной инфраструктуре проекта, с мониторингом серверов и каждого узла n8n, чтобы баги всплывали раньше, чем их увидит бизнес.

• Один промпт, одна основная и одна запасная модель на агента. У самого виджета есть запасная версия на случай, если ИИ-путь недоступен.
• GPT-4o mini ради стоимости и задержки: средний ответ ~3 с, длинные диалоги ограничены примерно 7 с, пик 9 с.
• Общая память в MongoDB питает еженедельный цикл улучшений на реальном трафике: качество ответов, промпты, CSAT, безопасность LLM.
• Каждая новая версия флоу перед релизом сравнивается с предыдущей узел за узлом, так что изменения поведения ловятся до того, как их увидят клиенты.
• Vision и OCR: клиент отправляет фото, например чек; данные извлекаются, сохраняются в MongoDB и используются агентами.

• Серверы собраны и защищены с нуля; путь данных между оркестратором, сервером и браузером защищён end-to-end.
• Пентесты через агентов, которых я построил по правилам на основе модели разрешений, grey-box тесты API, задержек и точек входа инфраструктуры, ревью внутренней команды безопасности и black-box тест внешней компанией. Каждая находка исправлена мной.
• Защита от prompt injection и контроль того, что попадает в модель; чувствительные данные не покидают периметр без причины.

• Соло-проект, более шести месяцев до релиза, разбитый на блоки: каждый блок сдавался со своим QA, мониторингом и документацией.
• Все автоматизации версионируются на GitHub с CI/CD-пайплайнами.
• Итоговые артефакты: документация API, плейбук для службы поддержки и технический документ проекта.

Команду поддержки из 50 человек не сократили. Её обучили новому флоу и частично предложили другим компаниям как услугу, так что бизнес превратил центр затрат в новую линию дохода.

Миграция на Qwen 3 с Hugging Face и Qdrant, вместе с командами ML и DevOps, ради приватности, задержки, контроля и возможности дообучать модель. Локальная модель также работает фильтром данных, отправляемых внешним LLM. Готовится fine-tuning, после чего та же модель будет обслуживать внутренние команды и сам виджет.

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

Пайплайн агентов Hermes на сервере компании: отдельный агент для исследования, один для скрейпинга и компоновки, один для дизайна и финальный скрипт публикации. Два входа. По URL-примеру: агенты исследуют и скрейпят похожий сайт и собирают новый по его мотивам. С нуля: запрос приходит через MCP из Claude Code или Codex, исследование идёт через Perplexity и Anthropic API, система скрейпит то, что попросил оператор, затем проводит короткое интервью, чтобы собрать факты, которые знает только человек, и строит сайт. GPT-6 Astra генерирует изображения. Один клик клонирует сайт с немного другим дизайном или с совершенно другим. База всех запусков растёт с использованием и со временем делает второй режим лучше. На выходе статический HTML, экспортируемый и разворачиваемый на серверах клиента через DevOps-скрипт.

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

• Исследование ключевых слов и их распределение по страницам; title и meta description; иерархия H1, H2, H3.
• Чистые URL, canonical, sitemap.xml, robots.txt; внутренняя перелинковка.
• Alt-тексты и лёгкие оптимизированные изображения для краулинга; Core Web Vitals; mobile first.
• Структурированные данные в schema.org JSON-LD; Open Graph.
• GEO, Generative Engine Optimization: разделы FAQ и llms.txt, чтобы ИИ-поисковики могли читать и цитировать сайт; hreflang для многоязычных сайтов.

Около сотни сайтов в месяц, пять–десять минут на каждый, примерно пять евро за сайт. Сайты — сателлиты одного-двух брендов и направляют трафик на основную страницу бренда; трафик отслеживается на уровне бренда.

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

Одна платформа для поддержки, продаж и менеджмента: те же клиенты, оповещения в реальном времени, голос, SMS и Telegram с одного экрана, база знаний в стиле Notion, встроенная в продукт, аналитика на AWS и Tableau и ИИ-слой, который маршрутизирует запросы и отвечает из базы знаний. Архитектура определена вместе с DevOps, отделом разработки, PM и менеджером по качеству со стороны клиента; микросервисы Kubernetes на серверах компании, по одному сервису на движок, фронтенд полностью на TypeScript с частями на Java. Я руковожу тремя ИИ-инженерами: двухнедельные спринты с резервом около десяти часов на срочные правки, QA-тест в конце каждого майлстоуна против бенчмарка, асинхронные улучшения, работа с блокерами, ежедневное решение проблем вместе со службой поддержки, менеджером по качеству и QA-менеджером.

• Бэкенд и фронтенд.
• Управление доступом: роли и права.
• Рабочее пространство операторов поддержки.
• Аналитика, подключённая к AWS, и рабочее пространство Tableau.
• Бизнес-оповещения, встроенные в CRM, из данных отделов на AWS.
• Оповещения в реальном времени через Kafka, построены вместе с ML-инженером.
• Встроенная база знаний, голос и SMS через Voiso, Telegram для общения с клиентами.

Блоки с майлстоунами; QA-тест в конце каждого майлстоуна и сравнение с бенчмарком; улучшения асинхронно; блокеры снимаются ежедневно. Двухнедельные спринты на инженера, Agile-подход и небольшой резерв в каждом спринте на то, что сломается.

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

On-premise LLM (Qwen 3) с полным доступом к данным CRM и внутренней платформе клиентских данных; агент со своей базой знаний, который помогает поддержке отвечать быстрее; браузерное расширение, через которое поддержка задаёт действия, выполняющиеся для клиента автоматически.

Сотрудники каждый день задавали HR, финансам и юристам одни и те же рутинные вопросы: дни отпуска, лимиты расходов, какой шаблон использовать. Каждый ответ отнимал время у тех, кто должен был его дать, а знания лежали в документах, которые никто не открывал. На сайте компании у посетителей не было самообслуживания и простого способа оставить запрос. Компания уже жила в Microsoft 365, поэтому и решение должно было жить там.

По одному ассистенту на отдел, в том канале Teams, где люди уже работают. HR-агент хранит все общие HR-знания, отвечает на частые вопросы и всё логирует; финансы и юристы работают по той же логике. Агенты построены в Microsoft Copilot Studio, опираются на документы SharePoint, модели — Azure OpenAI, а Databricks отвечает за логи, обмен данными и непрерывное улучшение. Тот же стек питает ассистента на сайте компании: общая информация, прямое подключение к SharePoint и Databricks, и шаг лида, который просит посетителя отправить запрос по email, когда в диалоге виден интерес. Построено сразу после виджета поддержки, в одиночку, для внутреннего заказчика Acrh Software.

Клиент уже жил в Microsoft 365: Teams, SharePoint, Azure. Строить там, где люди уже находятся, сняло трение внедрения; никому не пришлось учить новый инструмент. Опора на SharePoint делает каждый ответ подтверждённым источником и проверяемым, а Databricks хранит логи, которые двигают цикл улучшений.

• HR: отпуска, политики, вопросы онбординга, за которыми стоят все общие HR-знания.
• Финансы: правила расходов, лимиты, процедуры.
• Юристы: шаблоны, версии, когда пункт требует проверки человеком.
• Каждый диалог логируется, так что отделы видят, что люди действительно спрашивают, и исправляют документы, а не только ответы.

Ассистент сначала отвечает и просит отправить запрос по email, только когда посетитель проявляет намерение купить. Лиды приходят в продажи с приложенным диалогом, так что первый ответ человека уже опирается на контекст.

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

Диалоговый виджет, встроенный в сайт клиента, со всей информацией об объектах и зданиях на продажу. Код бота и промпт живут на Replit, модель — OpenAI, диалог спроектирован в Voiceflow, Airtable — CRM, Make выполняет автоматизации. Виджет собирает имя, телефон и email покупателя — ключевое поле. Сценарий один: как только лид сохранён, менеджер получает уведомление в Telegram с лидом. Сценарий два: покупатель получает персональное письмо с доступными объектами под его запрос и кнопкой записи на встречу. Сценарий три: клик открывает запрос в Google Calendar и Meet менеджера, менеджер принимает, покупатель получает подтверждение. Проактивные сообщения срабатывают, когда посетитель нажимает ключевые кнопки, что подняло лиды ещё на пять пунктов.

Email был ключевым полем: письмо с подходящими объектами продавало, пока менеджер был занят. Проактивные сообщения на ключевых кликах — ипотечный калькулятор, планировка — сами добавили пять пунктов лидов. А менеджеры перестали копировать данные руками, потому что они приходили уже структурированными.

• Автоматизации контента и автопостинга в Facebook, Instagram, VK и X через Make, для агентства и для клиентов.
• Весь способ работы агентства перестроен в ClickUp, пока команда росла с 50 до 200 человек: HR-интеграции с автоматическим онбордингом и оффбордингом, аналитика из клиентской CRM внутри ClickUp, структурированные обсуждения с ролями и правами, таск-менеджер и кастомная платформа планирования и встреч.
• Более 20 клиентских сайтов, построенных под ключ на JavaScript, Next.js и Astro, с API-подключением к CRM, развёрнутых на серверах клиентов.

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

Бот, который стартует по ключевому слову в WhatsApp, Instagram или Telegram, ведёт заданный флоу с LLM внутри, квалифицирует контакт по точному промпту, написанному под этого клиента, и заносит его в кастомную CRM на Google Apps Script, где лид переходит от холодного к тёплому и горячему по завершённым шагам. Боты обслуживали и клиентскую поддержку, общаясь напрямую с конечным пользователем, и команду самого клиента. С 2022 года те же клиенты получили голосовых агентов: голосового секретаря и HR-агента, собирающего данные кандидатов, на Twilio и ElevenLabs; исходящих агентов на Vapi и Retell, которые звонят лидам из списков клиента и задают квалифицирующие вопросы. Оркестрация в Make и n8n с кастомным кодом; модели OpenAI, Anthropic и OpenRouter.

• Один промпт на клиента, с критериями квалификации, записанными как явные вопросы, а не оставленными на усмотрение модели.
• Стадии воронки меняются только по завершённым шагам: лид не может стать горячим без контактов.
• Каждый бот работает 24/7; когда кампания взлетает, диалогов становится больше, но ни один канал не остаётся без ответа.

• Голосовой секретарь на Twilio и ElevenLabs: отвечает, маршрутизирует, принимает сообщение.
• Голосовой HR-агент: собирает данные кандидата в диалоге, который следует промпту.
• Исходящие агенты на Vapi и Retell: звонят лидам, задают квалифицирующие вопросы, передают результат в CRM.
• Агент продаж и финансовый агент, обрабатывающий внутренние данные, на той же оркестрации.

Автомобильная группа в Риме, более 1 000 сотрудников, парк около 200 000 автомобилей. KPI-дашборды в Power BI на SQL, выгрузках из AWS и внутренних API вместе с IT-отделом, для всего отдела продаж и для менеджмента с оповещениями. Неликвидный сток снижен на 25%, потому что данные двигались быстрее и подержанные машины продавались раньше. Контроль KPI и счетов поставщика на два–три миллиона евро в год. Четыре новых аналитика подключены и обучены.