CX-автоматизация ломается не на LLM, а на плохом стейте и слабых правилах эскалации

CX-автоматизация ломается не на LLM, а на плохом стейте и слабых правилах эскалации

Если агент отвечает за support, retention или lead-nurture, его надо проектировать как state machine, а не как «умный чат». Иначе он теряет контекст на 8–12 шаге, начинает дублировать ответы и путает ветки по одному и тому же клиенту.

Проверьте три слоя:
— идентификация клиента: один canonical ID для CRM, helpdesk и email
— память: отдельный summary-state, а не сырой лог всех сообщений
— guardrails: что агент может менять сам, а что сразу уходит человеку

Для CX-автоматизации полезно разделять actions и suggestions. Агент может подготовить черновик ответа, предложить тег, оценить intent, но финальный send/close лучше оставлять в ручном подтверждении, пока не доказана стабильность на ваших сценариях.

Если поток длинный, ставьте checkpoint после каждого критического шага: создание тикета, изменение статуса, отправка верифицированного ответа, перевод в эскалацию. Это дешевле, чем чинить цепочку, которая «помнит» только последний turn и забывает причину предыдущего решения.

Главное правило: сначала сделайте агенту короткий маршрут с понятным выходом, и только потом расширяйте автономность. В CX выигрывает не самый разговорчивый агент, а тот, который не теряет состояние и предсказуемо передаёт сложные кейсы человеку.