Отвечатор: ИИ-агент для ответов на отзывы и вопросы на маркетплейсах, построенный на Directual

Кратко

Отвечатор — нишевый ИИ-агент, который пишет живые персонализированные ответы на отзывы и вопросы покупателей на Ozon, Wildberries, Яндекс Маркете и Avito. В этом кейсе мы разбираем, как устроен агент внутри: почему мы выбрали prompt-driven архитектуру вместо модного agentic loop, как работает детерминистический пре-анализатор на Python, и почему Directual закрыл сразу весь бэкенд — оркестрацию, базу данных, SSE-стриминг, права, биллинг и интеграции с маркетплейсами.

Зачем нужен этот продукт

На российских маркетплейсах — Ozon, Wildberries, Яндекс Маркет, Avito — каждый день появляются миллионы отзывов. Продавцы обязаны на них отвечать: от скорости и качества ответов зависит рейтинг карточки, позиции в выдаче и, в конечном счёте, продажи.

Проблема в том, как продавцы отвечают. Мы проанализировали тысячи ответов — и увидели одну и ту же картину: 70–80% ответов — это копипаста. Один шаблонный текст на все отзывы подряд, от пятизвёздочной похвалы до разгромной единицы. «Благодарим Вас за проявленное доверие и высокую оценку нашего товара» — сотни раз, на каждый отзыв, дословно.

Покупатели это видят. Маркетплейсы это видят. Конверсия падает.

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

В этом кейсе мы разберём, как Отвечатор устроен внутри, почему мы выбрали prompt-driven архитектуру вместо модного agentic loop, и как Directual стал инфраструктурной основой для всего этого.

Почему ChatGPT и Claude «из коробки» не подходят

Первый вопрос, который задаёт каждый: «А зачем отдельный продукт, если можно просто скормить отзыв в ChatGPT и получить ответ?»

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

У модели нет контекста вашего бизнеса

ChatGPT не знает вашу политику возвратов, гарантийные условия, ассортимент, историю проблем с конкретным товаром. Он не знает, что 18% отзывов на эту модель кроссовок — жалобы на маломерки. Он напишет «первый раз слышим» там, где нужно сказать «да, мы знаем про эту особенность — рекомендуем брать на размер больше».

Нет системности

Каждый запрос в ChatGPT — это новый контекст с нуля. Вы не можете задать стиль ответов для всего магазина, не можете загрузить базу знаний, не можете настроить правила. Каждый раз вы копируете отзыв, вставляете промпт, редактируете результат, копируете обратно. При 50 отзывах в день это превращается в ад.

Нет аналитики

Модель не скажет вам: «У вас 73% ответов — одинаковая копипаста, канцелярит в каждом втором, а на негативные отзывы вы отвечаете в среднем через 28 часов — это убивает конверсию». Для этого нужен отдельный аналитический слой — и мы его построили.

Нет интеграции с маркетплейсами

Чтобы автоматизировать процесс, нужно тянуть отзывы по API, публиковать ответы по API, управлять правами, настраивать правила автопостинга. ChatGPT — это текстовое окно, а не бизнес-инструмент.

Вот почему нишевые ИИ-агенты — это рыночная ниша. Голая модель — это мозг без тела. А бизнесу нужен готовый агент с руками, ногами и памятью: с интеграциями, базой знаний, аналитикой, интерфейсом и правами доступа. Подробнее о разнице между подходами — в нашем сравнении ИИ-генерации и шаблонных автоответчиков.

Архитектура: общий взгляд

1. Фронтенд — Next.js-приложение на базе стартового шаблона Directual. Трёхколоночный интерфейс с SSE-стримингом ответов.

2. Бэкенд — Directual: оркестрация всего пайплайна, интеграции с маркетплейсами, хранение данных, управление пользователями и правами.

3. ИИ-агент — prompt-driven архитектура: большой структурированный системный промпт + динамический контекст, который собирает бэкенд.

4. LLM-провайдер — GigaChat от Сбера. Под российский B2B выбор очевидный:

   • Хостинг в РФ, 152-ФЗ из коробки. Данные не уезжают за границу, API не отвалится из-за санкций, согласования с ДПО и СБ проходят без танцев.
   • Нативный русский. Понимает идиомы, маркетплейс-сленг и интонацию — в отличие от англоязычных моделей, которые часто палятся дословным переводом.
   • Линейка под бюджет. Lite / Pro / 2 Max — роутим по сложности отзыва. На «всё классно» — Lite, на разгромную единичку — Max. Экономия в разы.
   • Всё нужное для prompt-driven архитектуры. Function calling, structured output, длинный контекст, нативный SSE-стриминг.
   • Оплата в рублях по обычному договору — подключают без проблем хоть ИП, хоть федеральные сети.
   • Совместимость с Directual. Плагин или HTTP-шаг в сценарии, SSE проксируется клиенту без буферизации.

5. Пре-анализатор — отдельный Python-сервис для детерминистического анализа отзывов и ответов. Считает всё, что можно посчитать без LLM.

Разберём каждый компонент подробнее.

Фронтенд: вайбкодинг + Directual

Фронтенд построен на Next.js + Directual Starter Template — нашем стартовом шаблоне, в котором уже есть авторизация (magic link, сброс пароля), WebSocket-подключение к Directual, SSE-стриминг и базовый дашборд.

Шаблон — это мост между вайбкодингом и серьёзным бэкендом. Фронтенд можно собирать быстро — через Cursor, через Copilot, как угодно — а вся бизнес-логика, данные, интеграции и оркестрация живут на Directual. Это принципиально отличается от подхода «всё на фронте»: здесь фронтенд тонкий, а мозги — на бэкенде.

Стек фронтенда:

• Next.js 16 (App Router)
• TypeScript
• Tailwind CSS + shadcn/ui
• SSE для стриминга ответов LLM
• Socket.IO для реалтайм-нотификаций

Трёхколоночный интерфейс

Ключевое UX-решение — три колонки:

• Слева — отзыв покупателя и черновик ответа. Черновик появляется автоматически из стрима LLM, продавец может редактировать его прямо в поле.
• По центру — чат с агентом. Продавец общается с Отвечатором, уточняет, просит правки: «сделай покороче», «добавь про гарантию», «убери извинения, мы тут не виноваты».
• Справа — контекст: карточка товара, документы из базы знаний, политики.

Ответ LLM стримится через SSE в реальном времени — продавец видит, как агент «думает» (extended thinking) и «печатает» ответ. Это не просто красиво — это снижает тревогу: видно, что агент работает, а не завис.

Бэкенд: Directual как оркестратор

Весь бэкенд Отвечатора — это Directual. Не «Directual + ещё пять сервисов». Directual — единственная платформа, которая оркестрирует весь пайплайн от получения отзыва до публикации ответа.

Что делает бэкенд

1. Интеграции с маркетплейсами — Directual тянет отзывы по API с Ozon, Wildberries, Яндекс Маркет, Avito. Новые отзывы появляются в системе автоматически. Ответы публикуются обратно через API площадок.

2. Хранение данных — все отзывы, черновики, чаты, проекты, пользователи, документы — в встроенной базе данных Directual. Каждый проект — отдельный namespace с полной изоляцией данных.

3. Сбор контекста для LLM — при каждом запросе бэкенд собирает полный контекст: текст отзыва, комментарии, карточку товара, документы продавца, результаты пре-анализа, историю чата. Всё это упаковывается в структурированный промпт.

4. Вызов LLM и стриминг — Directual вызывает модель через HTTP, получает SSE-поток и проксирует его на фронтенд без буферизации.

5. Права и роли — встроенная система ролей контролирует, кто что может делать: кто может публиковать ответы, кто только просматривать черновики, на какие отзывы можно постить (подробнее — ниже).

6. Вебхуки и нотификации — новые отзывы, смена статусов, результаты анализа — всё это события, которые Directual обрабатывает через сценарии и отправляет нотификации через WebSocket.

Почему Directual, а не кастомный бэкенд

Можно было написать бэкенд на Node.js или Python — и потратить три месяца на инфраструктуру вместо продукта. Directual позволил сосредоточиться на бизнес-логике:

• База данных с API — из коробки. Не нужно проектировать схему, писать миграции, настраивать ORM. Создал структуру — получил REST API.
• Сценарии вместо кода — визуальная оркестрация бизнес-логики. Получили отзыв → собрали контекст → вызвали LLM → сохранили результат → отправили нотификацию. Всё это — цепочка шагов в визуальном конструкторе.
• Интеграции через HTTP — подключение к любому API (маркетплейсы, LLM-провайдеры, пре-анализатор) без написания бойлерплейта.
• Облако — не нужно думать о серверах, масштабировании, отказоустойчивости.

SSE-стриминг: то, чего нет ни у кого в low-code

Отдельно стоит рассказать про стриминг, потому что это та штука, которая отличает Directual от всего остального low-code рынка.

ИИ-агент, который молчит 10 секунд и потом выплёвывает стену текста — это плохой UX. Пользователь должен видеть, как ответ генерируется в реальном времени. Для этого нужен SSE (Server-Sent Events) — потоковая передача данных от сервера к клиенту.

Directual поддерживает SSE нативно, через directual-js-api. Причём в двух режимах — и это принципиально.

Режим 1: Single-request stream

Простой вариант: отправляешь POST-запрос, в ответ получаешь SSE-поток. Запрос → стрим. Именно так работает генерация ответов в Отвечаторе: фронтенд пушит запрос, Directual собирает контекст, вызывает LLM и проксирует SSE-поток напрямую к клиенту.

Клиент → POST /stream/{structure}/{method} → Directual → LLM
   ◀── SSE: content_block_delta... ──◀── GigaChat stream ──◀

Режим 2: Init + Subscribe (для автономных агентов)

А вот это уже серьёзно. Двухфазный механизм:

1. Init — POST-запрос инициирует стрим и возвращает streamId
2. Subscribe — клиент подключается к стриму по streamId через GET

Клиент → POST /stream/init/{structure}/{method}
   ◀── { streamId: "abc-123" }

Клиент → GET /stream/subscribe/abc-123
   ◀── SSE: данные по мере готовности

Зачем два этапа? Потому что в реальных агентных системах инициатор стрима и потребитель — это часто разные процессы. Бэкенд-сценарий запускает генерацию (init), получает streamId, сохраняет его в базе — и отдельный процесс (фронтенд, другой сценарий, мобильное приложение) подписывается на результат.

Это критически важно для облачных автономных агентов. Представьте agentic loop, который крутится на сервере: агент вызывает инструмент → получает результат → думает → вызывает следующий инструмент. Каждый шаг — отдельный LLM-вызов, каждый вызов — стрим. Init + Subscribe позволяет отвязать выполнение от подключения: агент работает в фоне, а клиент может подключиться к стриму в любой момент, переподключиться после обрыва, или вообще подписаться задним числом.

Ни один low-code/no-code инструмент на рынке этого не даёт. n8n, Make, Zapier — все работают с request-response. Bubble, Xano — не поддерживают SSE вообще. Directual — единственная платформа, где стриминг LLM-ответов — нативная, продакшн-готовая функциональность с двумя режимами работы.

В Отвечаторе мы используем первый режим (single-request) — потому что у нас prompt-driven архитектура с одним вызовом. Но инфраструктура для полноценного agentic loop уже на месте, и для следующих продуктов на Directual это будет критично.

Prompt-driven архитектура: мозг агента

Это, пожалуй, самая интересная часть. Когда все вокруг строят agentic loops с tool calls, мы выбрали prompt-driven подход. И вот почему.

Почему не agentic loop

В agentic loop модель сама решает, какие инструменты вызывать: search_knowledge, get_product_info, get_similar_reviews. Звучит круто, но для задачи ответов на отзывы это overkill:

• Контекст предсказуем. Мы заранее знаем, что нужно агенту: текст отзыва, карточка товара, документы продавца, статистика ответов. Не нужно «искать» — нужно подставить.
• Один вызов LLM вместо пяти. Agentic loop — это 3–7 вызовов модели за один ответ. Это 10–30 секунд вместо 2–5. И это в 3–5 раз дороже.
• Предсказуемость. Agentic loop может зациклиться, вызвать ненужный инструмент, потратить бюджет на бессмысленные запросы. Prompt-driven — один вызов, один результат, никаких сюрпризов.

Как это работает

Вместо того чтобы агент сам искал информацию, бэкенд заранее собирает всё что нужно и инжектит в промпт. Модель получает полный контекст за один раз и выдаёт структурированный ответ.

┌──────────────────────────────────────────────────────┐
│ system prompt: ~600 строк инструкций (статичный)     │
├──────────────────────────────────────────────────────┤
│ user message (динамический, собирается бэкендом):    │
│   <task>A</task>                                     │
│   <review>текст отзыва, рейтинг, дата...</review>    │
│   <comments>история комментариев</comments>          │
│   <product_contexts>карточка товара</product_contexts>│
│   <seller_docs>политики, стиль</seller_docs>         │
│   <seller_analysis>аудит ответов</seller_analysis>   │
├──────────────────────────────────────────────────────┤
│ assistant: структурированный ответ                   │
│   <review_analysis>анализ отзыва</review_analysis>   │
│   <response_strategy>стратегия ответа</strategy>     │
│   <draft>готовый текст ответа</draft>                │
│   <chat_message>сообщение продавцу</chat_message>    │
└──────────────────────────────────────────────────────┘

Системный промпт — спецификация поведения

Системный промпт — это не «ты ассистент, отвечай на отзывы». Это детальная спецификация поведения на ~600 строк, размеченная в XML. Документ описывает:

• Роль и стратегию — кто ты, какая главная цель, воронка работы с негативом (вывод в личные сообщения).
• Три режима работы — задача A (черновик с нуля), задача B (доработка по указаниям продавца), задача C (анализ опубликованного ответа с оценкой по 11 критериям).
• Формат ввода-вывода — какие XML-теги ожидать на входе, какие выдавать на выходе. Это контракт между бэкендом, LLM и фронтендом.
• Правила для текста — живой язык, конкретность, антипаттерны, длина, приглашение в ЛС на негатив.
• Мульти-тёрн поведение — как вести диалог с продавцом, обрабатывать правки, реагировать на обновления базы знаний.
• Безопасность — защита от prompt injection через текст отзывов, jailbreak-атак, конфиденциальность промпта.
• Детекция изменённых отзывов — алгоритм, который по датам комментариев восстанавливает хронологию: если дата отзыва позже первого ответа продавца — значит, отзыв был изменён после решения проблемы в личке.

XML-теги как протокол

Ключевое архитектурное решение — использование XML-тегов как протокола между LLM и интерфейсом. Модель отвечает структурированно:

• <review_analysis> — анализ ситуации
• <sources_used> — какие документы использованы
• <response_strategy> — стратегия ответа
• <draft> — готовый текст ответа
• <chat_message> — сообщение продавцу в чат

Фронтенд парсит эти теги из SSE-потока в реальном времени и раскладывает по секциям интерфейса: черновик — налево, сообщение — в чат, анализ — в сворачиваемый блок. Это одновременно:

• Протокол — фронтенд точно знает, какие блоки ожидать для каждой задачи.
• Chain-of-thought — модель сначала анализирует, потом строит стратегию, потом пишет черновик. Порядок тегов вынуждает «думать» до «отвечать».
• Прозрачность — продавец видит не только результат, но и ход мысли агента.

Персонализация: клиент загружает всё

Каждый проект в Отвечаторе — это отдельное пространство со своей базой знаний. Продавец загружает:

• Каталог товаров — описания, характеристики, известные проблемы
• Документы — политика возвратов, гарантийные условия, стандарты ответов
• FAQ — ручные записи: «если спрашивают про доставку в Казахстан — мы не доставляем»
• Стиль и тон — как общаться с покупателями (на «ты» или на «вы», с эмодзи или без, с юмором или строго)

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

Пре-анализатор: Аудит Отвечатора

Одна из самых мощных фич — Аудит Отвечатора. Это детерминистический Python-сервис, который анализирует существующие отзывы и ответы продавца до того, как LLM начнёт работу.

Зачем нужен отдельный сервис

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

Пре-анализатор — это FastAPI-сервис на Python. Никаких LLM-вызовов. Всё считается локально: TF-IDF, cosine similarity, DBSCAN-кластеризация, морфологический анализ через pymorphy3. Чистая математика.

Что считает

По API затягиваются отзывы и ответы продавца за последний месяц, пачкой отправляются в пре-анализатор. Он обрабатывает от 10 до 2000 пар «отзыв — ответ» и выдаёт отчёт:

12 модулей анализа:

1. Копипаста — DBSCAN-кластеризация ответов по TF-IDF триграммам. Находит группы одинаковых ответов, считает долю шаблонов.
2. Канцелярит — словарь маркеров бюрократического языка, который убивает продажи: «проявленное доверие», «доставленные неудобства», обращение на «Вы» с большой буквы.
3. Реклама в ответах — детекция промо-контента, внешних ссылок, промокодов. Особенно критично в ответах на негатив.
4. Несоответствие тона рейтингу — благодарность на 1-звёздочный отзыв, агрессия на жалобу.
5. Персонализация — насколько ответ привязан к содержанию конкретного отзыва (пересечение ключевых слов после лемматизации).
6. Скорость ответов — среднее и медианное время ответа, с разбивкой по рейтингу. На негатив отвечают медленнее — это проблема.
7. Неотвеченные отзывы — доля и паттерн пропущенных отзывов.
8. Словарное разнообразие — уникальность лексики, однородность длины ответов.
9. Выдуманный контекст — когда продавец пишет «рады, что вам понравился X», а покупатель X не упоминал.
10. Отписки — слишком короткие ответы на развёрнутые или негативные отзывы.
11. Шаблонные вступления и концовки — одинаковые первые/последние 15 слов в 60%+ ответов.
12. Проигнорированные вопросы — покупатель задал вопрос в отзыве, продавец не ответил.

Результат — часть контекста для агента

Результат пре-анализа инжектится в промпт как <seller_analysis> — агент видит полную картину:

• Статистика — распределение оценок, средняя скорость ответа, доля отвеченных
• Кластеры — какие шаблоны продавец использует, какую долю ответов они покрывают
• Антипаттерны — конкретные проблемы с примерами: «73% ответов — одна и та же фраза», «благодарность на негатив в 40% случаев»
• Сильные стороны — что продавец делает хорошо (чтобы агент сохранял удачные приёмы)

Благодаря этому агент не повторяет ошибки продавца. Если продавец в 73% ответов писал «Благодарим за обратную связь» — агент найдёт другую формулировку. Если жалоба на маломерки — системная (18% всех отзывов) — агент не напишет «первый раз слышим».

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

Как работает генерация ответа

Задача A — черновик с нуля

Продавец открывает отзыв и жмёт «Поехали!». Дальше:

1. Фронтенд отправляет запрос в Directual
2. Directual-сценарий собирает контекст: текст отзыва + комментарии, карточку товара из базы знаний, документы и политики продавца, результат пре-анализа
3. Формируется промпт: статичный system prompt + динамический user message с XML-блоками контекста
4. Один вызов LLM (GigaChat), результат стримится через SSE
5. Фронтенд парсит XML-теги из потока и раскладывает по секциям UI

Итого: ~7–13K токенов на входе, ~1–2K на выходе. Один вызов. 2–5 секунд.

Задача B — доработка в диалоге

Продавец пишет в чат: «Сделай покороче» или «Добавь про гарантию» или «Убери извинения, мы не виноваты».

Бэкенд добавляет сообщение в историю чата, подставляет текущий черновик, обновляет контекст (если документы изменились) — и снова один вызов LLM. Модель видит всю историю + правку продавца и выдаёт обновлённый черновик.

Задача C — анализ опубликованного ответа

Продавец уже ответил на маркетплейсе. Отвечатор анализирует ветку и даёт честную оценку по 11 критериям: скорость ответа, конкретность, краткость, канцелярит, тон, полнота, обещания, эффект для читателя, вывод в личку, копипаста, контекстуализация. Ставит оценку от 1 до 10 — без завышений.

Если оценка низкая (1–4) — предлагает follow-up комментарий, который продавец может опубликовать следом, чтобы исправить ситуацию. Не «перепиши ответ» (его уже нельзя отредактировать), а «допиши дополнение».

Команда и права: агент как член команды

Одна из концепций, которой мы гордимся: Агент Отвечатор — полноправный член команды.

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

И вот ключевое: агент — это тоже участник с настраиваемыми правами. Он работает в тех же рамках, что и люди.

Гибкие правила публикации

Можно настроить:

• Автопостинг — агент сам публикует ответы на определённые отзывы (например, только на 4–5 звёзд, где риск минимален).
• Ограничение по рейтингу — менеджер может публиковать ответы только на отзывы 4–5 звёзд. На негатив (1–3 звезды) — только с аппрува владельца.
• Полный контроль — ни один ответ не уходит без ручной проверки.

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

Стек технологий

Компонент	Технология	Зачем
Бэкенд	Directual	Оркестрация, данные, API, интеграции, права
Фронтенд	Next.js + Directual Starter Template	UI, SSE-стриминг, WebSocket
UI-компоненты	shadcn/ui + Tailwind CSS	Быстрая сборка интерфейса
LLM	GigaChat (Сбер)	Российская инфраструктура, отличный русский, нет санкционных рисков, оплата в рублях
Пре-анализатор	Python, FastAPI, scikit-learn, pymorphy3	Детерминистический анализ без LLM
Стриминг	SSE (Server-Sent Events)	Потоковая передача ответов LLM
Нотификации	Socket.IO	Реалтайм-обновления статусов

Стоимость одного ответа

• System prompt: ~3–4K токенов
• Контекст (RAG + пре-анализ): ~3–6K токенов
• История чата: ~1–3K токенов
• Output: ~500–1K токенов
• Итого: ~8–14K токенов ≈ $0.01–0.03 за ответ

При 1000 отзывов в день — $10–30 на LLM. Менеджер обходится дороже.

Что внутри Directual

Для тех, кому интересны детали реализации на платформе:

Структуры данных

• WebUser — пользователи, роли, пермишены
• Projects — проекты продавцов с настройками, стилем, подключениями к маркетплейсам
• Reviews — отзывы со статусами (new → generating → draft → approved → published)
• ChatMessages — история диалога с агентом
• KnowledgeBase — документы, FAQ, карточки товаров
• SellerAnalysis — результаты пре-анализа

Сценарии

• Синхронизация отзывов — по расписанию или по вебхуку тянет новые отзывы с маркетплейсов
• Генерация ответа — собирает контекст, формирует промпт, вызывает LLM, стримит результат
• Публикация — отправляет одобренный ответ обратно на маркетплейс через API
• Пре-анализ — запускает Python-сервис и обрабатывает результат через вебхук
• Биллинг — приём платежей, списание подписок, учёт потребления (подробнее ниже)

Биллинг и монетизация — полностью на Directual

Отдельная история — монетизация. Биллинг Отвечатора — это связка ЮKassa + Directual. ЮKassa принимает деньги, а вся логика учёта, подписок и балансов живёт на Directual:

• Приём платежей — ЮKassa как платёжный шлюз, интеграция через HTTP-запросы из сценариев. Вебхуки от ЮKassa приходят в Directual, сценарий обрабатывает статус платежа, обновляет подписку пользователя.
• Учёт токенов и ответов — каждый вызов LLM логируется: сколько токенов потрачено, на какой отзыв, какой пользователь инициировал. Сценарий списывает «ответ» с баланса пользователя после успешной генерации.
• Подписки — регулярные списания по CRON-сценарию: проверяет дату следующего платежа, инициирует списание, обновляет статус. Просрочка → уведомление → блокировка генерации.
• Пакеты ответов — пользователь покупает N ответов, баланс хранится в структуре данных, при каждом использовании декрементится. Когда остаётся мало — нотификация через WebSocket.

ЮKassa отвечает за приём денег — всё остальное (логика подписок, балансы, списания, уведомления) живёт на Directual как обычная бизнес-логика. Никакого кастомного billing-микросервиса.

API-эндпоинты

Directual автоматически генерирует REST API для каждой структуры. Фронтенд общается с бэкендом через стандартные GET/POST-запросы и SSE-стримы. Всё это работает через единую точку авторизации — никаких отдельных auth-сервисов.

Почему именно Directual

Мы строим продукт на собственной платформе — и это не просто «собака ест свою еду». Directual реально закрывает все потребности Отвечатора:

1. Сложный бэкенд без кода — оркестрация пайплайна генерации, интеграции с четырьмя маркетплейсами, стриминг, вебхуки, CRON-задачи. Всё это — визуальные сценарии.

2. Подключение к любым LLM — GigaChat, YandexGPT, Claude, GPT, Gemini — через стандартные HTTP-запросы. Не привязаны к одному провайдеру, можем переключать модели в зависимости от задачи, бюджета и регуляторных требований.

3. Нативный SSE-стриминг — два режима: single-request для простых пайплайнов и init + subscribe для автономных агентов. Ни один конкурент в low-code это не предлагает — подробности в directual-js-api.

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

5. Права и роли из коробки — система пермишенов, которая позволила реализовать концепцию «агент как член команды» без написания auth-логики.

6. Облако — не думаем о серверах. Отвечатор обрабатывает тысячи отзывов в день, Directual масштабируется автоматически.

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

Итоги и что дальше

Отвечатор — это пример того, что происходит, когда нишевый ИИ-агент строится на правильной инфраструктуре:

• Prompt-driven архитектура вместо дорогого и непредсказуемого agentic loop — один вызов LLM, 2–5 секунд, $0.01–0.03 за ответ.
• Пре-анализатор — детерминистический Python-сервис, который считает всё что можно без LLM и кормит результатами агента.
• Directual — полный бэкенд без единой строчки серверного кода: данные, API, сценарии, интеграции, стриминг, права.
• Next.js + Directual Starter — фронтенд, который можно собрать быстро через вайбкодинг, не жертвуя архитектурой.
• Агент как член команды — не отдельная тулза, а участник рабочего процесса с пермишенами и правилами.

Что дальше

• Пакетная генерация — ответы на 100 отзывов за один клик
• Расширенные правила автоответов — настраиваемые условия для автоматической публикации
• Аналитический дашборд — динамика качества ответов, время ответа, satisfaction score
• Дельта-анализ — «было 73% копипасты, стало 12%» — отслеживание прогресса

Если вы продаёте на маркетплейсах и устали от шаблонных ответов — попробуйте Отвечатор.

Если вы хотите построить своего ИИ-агента для другой ниши — начните с Directual. Бесплатный курс по ИИ-агентам — 60 минут, и вы построите первого агента с RAG-системой.