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

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

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

Три места, где чаще всего разваливается пайплайн:
— нет нормальной схемы сущностей: один и тот же клиент хранится в трёх системах по-разному;
— слишком длинный контекст: агент тащит лишнее и теряет релевантные сигналы;
— нет границы автономии: агент сам меняет статус, хотя должен только предлагать действие.

Для устойчивой CX-автоматизации нужен guardrail-слой: whitelist действий, обязательные поля для каждого шага и fallback на человека при низкой уверенности. Полезно хранить не только финальный ответ, но и trace: какие поля агент прочитал, какие tool calls сделал, где остановился.

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