Почему корпоративные AI-агенты буксуют: рабочий контур vs демо

В начале июля 2026 года рынок получил два трезвых сигнала.

Марк Цукерберг, по сообщению TechCrunch, сказал сотрудникам, что AI-агенты продвинулись не так быстро, как он рассчитывал.

Через несколько дней Microsoft объявила о сокращении около 4 800 сотрудников, в том числе в коммерческих продажах, называя среди причин переход на AI.

Оба сообщения удобно читать как сенсацию, но полезнее - как коррекцию ожиданий.

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

Для заказчика вывод простой - вопрос уже не «умеет ли агент», а «доведён ли он до рабочего процесса».

Разница между «агент умеет» и «агент работает» - это не мощность модели, а инженерная дисциплина вокруг неё.

Рабочий контур начинается с данных: их чистят от мусора до того, как показать модели.

Дальше идут проверяемые промпты и понятные термины - чтобы бизнес и разработчик говорили об одном и том же.

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

Это ровно те слои, которых нет в демонстрации, и ровно они определяют, доживёт ли агент до эксплуатации.

Подробнее про выбор между агентом, RPA и ассистентом мы разобрали в статье [«AI-агенты, RPA и ассистенты: что выбрать под задачу»

](/blog/ai-agents-vs-rpa-vs-assistants-business-automation), а про типичные причины провала пилотов - в статье «AI в бизнесе: как не провалить пилот».

Один из топ-3 девелоперов РФ разбирал тикеты поддержки вручную: сотрудники маршрутизировали обращения по командам и услугам, поэтому скорость и качество зависели от человеческого разбора.

Для демонстрационного контура KT.Team взяла массив из 12 тысяч закрытых тикетов за квартал и сначала очистила их от пустых описаний, цепочек писем и непригодной разметки.

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

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

На воркшопе зафиксировали термины, промпты, запуск, Telegram-уведомления и методику дальнейшего внедрения.

Разбор кейса целиком - на странице [«LLM-классификация тикетов поддержки»

](/cases/fsk-llm-ticket-classification).

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

Исследование DORA показывает, что лучшие команды опережают худших по скорости выкладки на прод в 106 раз - за счёт слабой связанности и инженерной зрелости, а не численности.

По оценке QSM, оптимум для средней системы - команда 3-7 человек.

Именно поэтому разрыв между хайпом и поставкой - это окно для малой ai-native команды: она отвечает за бизнес-результат, доводит контур до эксплуатации и меряет TTU, а не количество слайдов.

Как мы устроены внутри и как это переносится на AI-контур клиента - на страницах AI для бизнеса и AI-native разработка.