Коротко. AI-агент надёжно работает там, где сделка простая, комитет маленький, а ошибка стоит недорого: квалификация входящих, бронирование встреч, обновление данных. Он ломается на длинных цепочках действий, сложных комитетах и в ситуациях, где цена репутационной ошибки высока. Решает не мощность модели, а профиль сделки.
Где проходит граница
Спор «заменит или не заменит» бесполезен, потому что ответ зависит от типа сделки. Полезнее рамка из четырёх факторов.
| Фактор | Агент справится | Агент сломается |
|---|---|---|
| Средний чек | До ~$25 000 | От ~$100 000 |
| Комитет | 1–2 человека | 6–10 стейкхолдеров с разными интересами |
| Тип потока | Входящий, много однотипных обращений | Сложный исходящий, работа через отношения |
| Цена ошибки | Высокая терпимость: неудачное письмо просто проигнорируют | Низкая: одна формулировка бьёт по репутации у всего рынка |
| Пример | Квалификация лида, бронирование демо, напоминания | Переговоры с закупкой, нестандартный контракт, эскалация |
Как устроен рабочий агент
Производственный агент — не чат-бот, а система из нескольких слоёв. Ему нужны описанные интерфейсы к данным и действиям — здесь помогает MCP как способ не писать интеграцию под каждую систему заново. Ему нужна подгрузка инструментов по требованию, а не весь набор в контексте разом: иначе растут и стоимость, и число ошибок. И ему нужна инфраструктурная часть — ограничения по частоте запросов, повторные попытки, очереди, лимит расходов. Это не технические детали, а то, от чего зависит, переживёт ли агент первый настоящий день работы.
Как именно он ломается
- Длинные цепочки. Вероятность ошибки накапливается: пять шагов по 95% надёжности дают уже примерно 77% на выходе.
- Придуманные факты. Агент уверенно сообщает клиенту то, чего в продукте нет.
- Сломанные инструменты. Изменился ответ API или вёрстка страницы — агент продолжает действовать, будто всё в порядке.
- Циклы. Агент застревает, повторяя одно и то же действие, и тратит бюджет.
- Стоимость длинных запусков. Автономная работа часами обходится дороже, чем кажется на демо.
Теневая CRM — главная ошибка внедрения
Типичный сценарий: агент ведёт свою базу и синхронизируется с CRM раз в час. Через месяц у вас два списка контактов, дубли сделок и отчёт, которому никто не верит. Правильная схема — агент работает напрямую с живыми данными CRM: читает оттуда и пишет туда же. Если платформа так не умеет, это довод против платформы, а не повод завести вторую базу.
Что проверить до запуска
- Что агент делает, когда не уверен? Ответ «продолжает» — плохой. Нужна передача человеку с полным контекстом.
- Кто отвечает за то, что агент сказал клиенту?
- Есть ли лимит расходов на один запуск?
- Как вы узнаете, что агент сломался, — из мониторинга или от клиента?
- Что видит клиент: понимает ли он, что говорит с машиной?
Автономию имеет смысл вводить снизу — с самых дешёвых и однотипных задач, — а не сверху, с самых заметных. Ошибка агента на квалификации входящих стоит одного потерянного лида. Ошибка на переговорах стоит сделки и репутации.