Что это за кейс и почему он вымышленный
История, вокруг которой построен этот разбор, помечена автором как выдумка: совпадения с реальными именами, должностями и компаниями случайны. Публичный текст вышел 21 сентября 2026 года (источник на Хабре). Дальше речь идёт о сценарии, а не о подтверждённом опыте внедрения, и это важнее всех цифр внутри.
Сюжет такой. Нетехническая торговая компания, не FMCG, шесть лет теряла продажи и за это время проела свободный кеш. Автора позвали на месяц с оплатой по факту. За месяц он собрал набор агентов: проверку сборки заказов по фото, агента-менеджера, который закрывает около 95% клиентских чатов, агента для мелких правок и деплоя прямо из рабочего чата. Старую логистику на Perl заменил софт на Python, а над всеми агентами поставили главного агента-погонщика, который знает внутренние процессы, пишет отчёты и напоминает сотрудникам о задачах.
Смотреть здесь стоит не на сроки, а на порядок действий: какие процессы пришлось описать, в какой последовательности появлялись агенты и что происходило с людьми, которые остались работать рядом с ними. Цифры и месячные дедлайны условны, поскольку условен сам кейс.
Исходная точка: шесть лет падения и проеденный кеш
Компания начинала агрессивно. Больше десяти лет назад она уронила цены примерно втрое и полгода торговала ниже себестоимости. Три месяца работы примерно на 30% ниже себестоимости полностью вымыли капитал конкурентам, после чего компания забрала 99% рынка и подняла цены сильно выше прежних (описание истории). Дальше несколько лет всё шло хорошо: выручка росла, складов стало десять, штат разрастался вместе с бизнесом.
В какой-то момент в компанию пришёл программист на все руки. Он занимался 1С, SEO и воронками продаж, запускал проекты, которые приводили клиентов, автоматизировал процессы, собрал небольшой штат программистов для поддержки всего этого и уехал. Затем продажи падали шесть лет подряд. В сентябре после сезона отпусков случалось оживление, но сравнение с тем же месяцем прошлого года каждый раз выходило хуже. Себестоимость росла все шесть лет, а цена для покупателя стояла на месте. Штат раздут, зарплаты перегреты.
На рынок пришли крупные игроки, и старый трюк с демпингом с ними перестал работать. К осени продажи просели ещё раз, и свободный кеш закончился. Это и есть точка, в которой появился автор кейса.
Почему предыдущая попытка внедрения ИИ провалилась
Где-то год назад в компании решили внедрять ИИ: поднять продажи, срезать издержки. Шло туго даже у программистов, а про рядовых сотрудников и склад говорить не приходилось. Руководство дало отмашку: кто осилит ИИ, тот гарантированно останется.
За год часть процессов формализовали и автоматизировали. Осенью продажи опять просели, кеш кончился, а человек, который занимался ИИ, ушёл. Автор пришёл в эту пустоту с предложением на месяц и оплатой по факту. Схема с оплатой за результат описывает ключевое отличие второго захода от первого: риск неудачи лежал на исполнителе, а не на бюджете компании.
Агент проверки сборки заказов по фото: как это работало
Склад был автоматизирован слабо, и пересортица в заказах случалась постоянно. Классический путь решения такой проблемы, то есть сканеры, WMS и штрихкод на каждой позиции, требует денег и дисциплины, которых в описанной компании не было. Автор пошёл от имеющегося ресурса: у сотрудника есть телефон с камерой, а состав заказа хранится в системе.
Логика агента простая. Сотрудник фотографирует собранный заказ, агент сверяет изображение с составом и примерно за минуту сообщает результат. Дорогое оборудование в сценарии не нужно, достаточно камеры, доступа к составу заказа и модели, которая распознаёт содержимое коробки.
Ограничения у решения прямые. Точность зависит от качества фото и освещения. При нестандартной упаковке, наложении товаров друг на друга или однотипных позициях модель ошибётся, и проверка превратится в формальность. В кейсе не названы ни точность распознавания, ни доля ложных срабатываний, поэтому минуту на проверку нельзя читать как гарантированный результат. Практический смысл такого агента в другом: он имеет ценность там, где ошибку дешевле поймать до отгрузки, а цена ошибки выше цены выборочной ручной перепроверки спорных заказов.
Агент-менеджер: 95% клиентских чатов без человека
Второй агент работал с клиентскими чатами и закрывал около 95% обращений. Показатель подчёркнуто условный: это часть вымысла, а не измеренная метрика. Конструкция при этом описана правдоподобно: агент берёт на себя типовые вопросы, оформление заказов и уточнение деталей, а оставшиеся обращения уходят людям, когда клиент попадает в нестандартную ситуацию.
Чтобы такой агент заработал, нужны две вещи: описанные процессы и база знаний. Без них он будет отвечать уверенно и мимо. Общая механика корпоративных агентов, включая требования к данным, инструментам и порядку запуска, разобрана в материале про ИИ-агентов как виртуальных сотрудников внутри компании.
Агент для мелких правок и деплоя прямо из чата
Третий агент деплоил мелкие правки прямо из рабочего чата. Сотрудник писал, что нужно поправить текст, цену или формулировку, и изменение уходило в бой без участия программиста. Главная выгода здесь в исчезновении очереди задач на мелкие правки, которые обычно ждут неделями между крупными релизами.
Границы применимости жёсткие. Такой агент годится для правок, которые не меняют логику и не трогают платежи и персональные данные. Ему нужны настроенные права доступа, контроль версий и откат, иначе первая же ошибка станет необратимой. Полезно свериться с разбором того, где AI-агенты в цикле разработки реально ускоряют работу, а где создают иллюзию продуктивности: типовые задачи ускоряются в разы, новая логика почти не ускоряется.
Замена логистики на Perl софтом на Python
Старая логистика работала на Perl. Язык живой, но специалистов на рынке мало, поддержка кода, который годами писал один человек, обходится дорого, а библиотеки для работы с моделями и внешними API на Perl почти никто не пишет. Связка «агент плюс логистика» упиралась в узкое место: агент умеет читать данные, а система не умеет их отдавать в нужном виде.
Новый софт на Python снял это ограничение. Python проще стыкуется с ИИ-агентами и современными библиотеками, и главный агент-погонщик получил доступ к данным о логистике, из которых строятся отчёты. В сценарии миграция проходит быстрым фоном, но переносить это на реальный бизнес без проверки нельзя: замена несущей системы в компании без своей команды разработки обычно тянет за собой параллельную работу двух контуров, сверку данных и период, когда ошибки неизбежны.
Главный агент-погонщик: над всеми агентами
Набор агентов сам по себе превращается в хаос, если никто не следит за их работой и не сводит результаты. В кейсе эту роль играет главный агент-погонщик: он знает внутренние процессы, пишет отчёты и напоминает сотрудникам о задачах, выступая единой точкой контроля над остальными агентами.
Здесь заканчивается техническая часть и начинается организационная. Агент, который раздаёт задачи людям, требует не только доступа к данным, но и описанных процессов, сроков и ответственных. Похожие принципы, где ИИ предлагает, человек утверждает, а применяет детерминированный исполнитель, собраны в методологии Agent-Ops 0.4.0 с её принципом unknown ≠ OK и разделением ролей между человеком, агентом и программой.
Организационные последствия: сокращение штата, рост зарплат и жалобы на ИИ-коллег
Часть сотрудников сократили, оставшимся подняли зарплаты. Логика понятная: повторяемые операции автоматизировали, людей нужно меньше, но те, кто остался, отвечают за более широкий контур и стоят дороже. В кейсе упоминается рост летних продаж, что связывает скорость обработки заказов с выручкой, однако конкретных цифр в истории нет, так что это скорее иллюстрация направления, чем измеренный эффект (описание последствий).
Почему сотрудники жаловались на несуществующих коллег
Отдельная деталь сценария: сотрудники ходили жаловаться на коллег, которых не существовало. Речь про ИИ-агентов, которые воспринимались как начальники: не устают, не ошибаются, всегда правы по факту. Главный агент-погонщик напоминал о задачах, и это раздражало сильнее, чем живой руководитель. Причина прозаичная: у агента есть контроль, но нет роли, с которой можно договориться, объяснить контекст или попросить отсрочку.
Риск тут выше, чем кажется на первый взгляд. Когда контроль исходит от системы, у сотрудников пропадает пространство для манёвра, а вместе с ним и готовность брать на себя ответственность за результат. Похожий эффект описан в разборе того, почему часть разработчиков не хочет отдавать код ИИ-агентам: сопротивление растёт там, где у человека отнимают авторство и контроль, но оставляют ответственность. В торговой компании это проявляется через жалобы и текучку, а не через спор о качестве кода.
Какие уроки можно извлечь из этого сценария
История выдумана, поэтому цифры и сроки в ней условны, а выводы придётся проверять на своих процессах. Порядок действий при этом выглядит осмысленным, и вот что из него переносится в реальность.
- Формализация идёт первой. Агентам нужны описанные процессы и данные, и именно на этом этапе предыдущая попытка застряла. Без описаний агент работает как уверенный, но невежественный сотрудник.
- Начинать стоит с одного процесса с измеримым результатом: пересортица, доля типовых обращений, время на мелкую правку. Проверка сборки по фото как раз такой случай.
- Оплата по факту снижает риск заказчика и заставляет исполнителя показывать работающий результат, а не отчёт о проделанной работе.
- Главный агент-погонщик требует архитектуры. Координатор над остальными агентами нужен, но он же становится точкой отказа и источником конфликтов с людьми, если его полномочия не описаны.
- Организационные изменения готовят заранее. Сокращение, перераспределение задач, новый уровень зарплат и обучение оставшихся обсуждают до запуска, а не после первого отчёта агента.
- Метрики фиксируют до старта: доля чатов, закрытых агентом, число ошибок сборки, время выхода мелкой правки, количество обращений к людям после агента. В кейсе названы 95% чатов и минута на проверку, но это часть вымысла, а не бенчмарк.
Побочные эффекты тоже стоит планировать. Агент нередко приносит пользу не там, где его ждали: в известном кейсе инструмент для разработки провалил боевые задачи, но закрыл больше половины исследовательских запросов аналитиков (разбор этого случая). В торговой компании таким побочным эффектом может оказаться, например, фотофиксация склада, которая попутно даст данные о качестве упаковки.
Ещё один нюанс: доступный текст истории обрывается на описании агента проверки сборки по фото, а детали остальных агентов поданы схематично. Поэтому читать кейс стоит как сценарий для обсуждения внутри своей команды: он полезен вопросами, которые помогает задать, а не готовым планом. Проверять гипотезы придётся на своих данных, своих процессах и с людьми, которые эти процессы ведут.