Разборы: как ИИ-агенты работают на самом деле

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

Снимок «до»: один проект в четырёх лицах

Агент нашёл на рабочем столе четыре разные папки, которые на самом деле были одним и тем же проектом. Их назвали по-разному: одну — заглавными латинскими буквами, другую — строчными, третью — по-русски, четвёртую — с приставкой про «настольную» версию. Человеку кажется, что это разные вещи. На деле — это один проект, размноженный при попытках «навести порядок» и «сделать копию на всякий случай».

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

Чему это учит:

• Похожие имена у папок («Проект», «проект», «Проект-2») — это не порядок, а ловушка: глазом их не различить.
• У любого проекта должно быть ровно одно «настоящее» место. Копия «на всякий случай» — это будущая путаница, а не страховка.

Матрёшка из папок: проект внутри проекта внутри проекта

Внутри «главной» объединённой папки агент обнаружил вложенные подпапки с говорящими приставками: «документы», «общее», «архив», отдельно «русская версия» и «английская версия». А внутри них — снова копии тех же самых мини-проектов. Проект лежал внутри проекта, который лежал внутри ещё одного проекта.

Такая матрёшка рождается из благих намерений: «сложу черновики в _архив», «а общие куски — в _общее», «а переводы разложу по языкам». Но без единого правила каждая такая папка становится ещё одной параллельной реальностью, где живёт свой слегка отличающийся набор файлов.

Чему это учит:

• Раскладывать по папкам полезно только когда есть одно ясное правило, где что лежит. Иначе «архив» и «общее» просто удваивают беспорядок.
• Если, чтобы найти нужный файл, приходится гадать «а в какой из копий он свежее» — структура работает против вас.

Файлы-двойники и пустые бумажки

Агент умеет сравнивать файлы по «отпечатку» — если содержимое совпадает до буквы, он видит это, даже если файлы лежат в разных местах и названы по-разному. И таких точных двойников он насчитал десятки групп. Одни и те же служебные заметки, настройки и описания были скопированы по два, по три, а кое-где и по семь раз.

Отдельно показательна большая группа из семи «одинаковых» файлов — одинаковых потому, что все они были пустыми. Заготовки под задачи и решения (вроде «список дел» и «принятые решения») создали, но так и не заполнили. Пустой файл выглядит как работа, но не содержит её. Семь пустых файлов — это семь обещаний, ни одно из которых не выполнено.

Чему это учит:

• Скопировать файл — не то же самое, что сохранить работу. Копия живёт своей жизнью и почти сразу расходится с оригиналом.
• Пустая заготовка создаёт ложное чувство, что дело сделано. Лучше один живой документ, чем десять пустых «правильных» табличек.

Секреты нараспашку

Самое тревожное в снимке — файлы с паролями и ключами доступа (их называют «секретами»). Агент отметил больше десятка таких файлов, и, что хуже, некоторые из них были продублированы вместе с папками. То есть один и тот же пароль лежал сразу в нескольких местах на обычном рабочем столе, без всякой защиты.

Логика простая и жёсткая: чем больше копий секрета вы делаете, тем в большем числе мест его могут случайно увидеть, переслать или потерять. Секрет, размноженный «за компанию» с проектом, — это утечка, которая ждёт своего часа.

Чему это учит:

• Пароли и ключи доступа не хранят рядом с рабочими файлами и уж точно не копируют пачками. У них должно быть одно защищённое место.
• В обычной переписке и рабочих папках вместо самого секрета держат только ссылку-напоминание: «пароль лежит там-то», а не сам пароль.

Невидимый балласт: гигабайты, которые считать не надо

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

Агент поступил правильно: он не стал тратить время на эти тяжёлые папки, а просто отметил их как «мусорные, пропущены». Разница в масштабе огромна: сама работа — крошечная, а балласт вокруг неё — в сотни раз тяжелее. Если не отделять одно от другого, можно потратить весь день, «наводя порядок» в том, что вообще не имеет значения.

Чему это учит:

• Размер папки не говорит о её ценности. Часто самое важное — самое маленькое, а самое тяжёлое можно смело игнорировать.
• Умный помощник экономит ваше время тем, что заранее отсекает заведомо ненужное и не заставляет вас в этом копаться.

Снимок «после»: принцип каноничного пространства

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

Суть в четырёх правилах. Первое: у проекта есть ровно одна главная папка-вход, и все начинают работу именно с неё, а старые двойники больше не трогают. Второе: секреты переезжают в отдельное защищённое хранилище, а в проекте остаются лишь ссылки на них. Третье: тяжёлые автоматические папки в расчёт не берут — их даже не заглядывают. Четвёртое, и главное для работы с ИИ: перед любой большой задачей агент сперва читает короткие файлы-памятки о проекте, а не пересматривает весь диск заново.

Последнее правило — ключевое. Именно эти памятки заменяют бесконечное «переоткрывание» всего подряд: агент один раз разобрался, записал выводы в память — и дальше опирается на неё, вместо того чтобы каждый раз блуждать среди копий.

Чему это учит:

• «После» — это не когда всё идеально разложено, а когда есть одно согласованное место правды и все ему следуют.
• Хорошая память проекта важнее уборки: если у ИИ есть короткая честная сводка, ему не нужно каждый раз перерывать весь диск.

Короткий вывод

Хаос на диске почти всегда возникает не от лени, а от избытка усилий: лишние копии «на всякий случай», лишние папки «чтобы аккуратнее», лишние пустые заготовки «чтобы было». Порядок наводится не тем, что вы всё раскладываете красивее, а тем, что выбираете одно настоящее место и одну память, которой доверяете. Снимок «до» — это анти-паттерн размножения двойников. Принцип «после» — одна правда, один вход, одна память. С этого и начинается нормальная работа с ИИ-агентом.

Что это за кейс. Недавно, за одну неделю лета 2026, один человек навёл порядок в своём рабочем «цифровом хозяйстве»: он собрал единый набор инструментов для ИИ-помощников и подключил его сразу к нескольким разным ИИ-приложениям. Этот разбор показывает главный принцип на понятном языке: не нужно настраивать инструменты отдельно под каждую программу — достаточно один раз собрать общую «шину», и к ней подключаются все. Всё, о чём рассказано ниже, взято из реального служебного отчёта; ничего не придумано.

Что такое «шина инструментов» простыми словами

Представьте удлинитель с розетками. К нему можно подключить чайник, лампу, зарядку — что угодно. Сам удлинитель не зависит от того, что именно вы в него воткнёте. В мире ИИ такую роль играет MCP — общий стандарт, по которому ИИ-помощник получает доступ к инструментам: к файлам, к базам, к внешним сервисам. Инструменты живут отдельно, «на удлинителе», а ИИ-приложение просто подключается к нему. В нашем кейсе один такой набор инструментов был собран один раз — и дальше стал общим для всех.

Чему это учит:

• Инструменты для ИИ можно держать отдельно от самих ИИ-программ.
• Общий стандарт (MCP) — это как единый разъём: воткнуть можно любое совместимое приложение.

Один сбор — сразу для нескольких ИИ-приложений

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

Чему это учит:

• «Настроил один раз — работает везде»: это и есть принцип «один mesh — много клиентов».
• Разные ИИ-приложения могут делить один и тот же набор инструментов, у каждого лишь своя маленькая точка входа.

Каждому проекту — своя понятная «карточка»

Прогон нашёл 28 рабочих проектов. Для каждого из них автоматически создали три одинаковых по смыслу файла-спутника: краткое описание проекта, заметку для отладки и настройку подключения к инструментам. Плюс каждому проекту выделили свой отдельный служебный номер-адрес внутри компьютера — как отдельная розетка для каждого прибора, чтобы они не путались между собой. Порядок один и тот же для всех проектов, поэтому в любом из 28 человек ориентируется одинаково.

Чему это учит:

• Единый шаблон для всех проектов экономит силы: не надо запоминать 28 разных схем.
• Общая шина не мешает каждому проекту иметь свою изолированную «розетку».

Инструменты просыпаются только по требованию

В отчёте отдельно подчёркнуто: отладочные сервисы работают только по запросу. Никаких постоянно висящих в фоне программ не запускали. Это как настольная лампа: она не горит круглые сутки — вы включаете её, когда садитесь читать, и гасите, когда уходите. Так система не тратит ресурсы впустую и остаётся под контролем человека.

Чему это учит:

• Хорошая настройка не значит «всё включено постоянно».
• Запуск по требованию бережёт ресурсы и оставляет управление в руках человека.

Секреты — отдельно от переписки

Отдельная линия в отчёте касается паролей и ключей доступа. Их сознательно не хранят в тексте заданий и не вписывают в переписку с ИИ. Вместо этого создали лишь пустой шаблон-заготовку для секретов, а реальные значения человек вписывает у себя локально, отдельно. На момент отчёта настоящий файл с секретами ещё не был заполнен — то есть система по умолчанию собрана «без ключей на виду».

Чему это учит:

• Пароли и ключи не место в чате с ИИ — им отводят отдельное защищённое хранилище.
• Правильная система заранее устроена так, чтобы секреты в неё нельзя было случайно «просыпать».

Управление — через простые команды-рычаги

Чтобы обычному человеку было удобно, поверх всей этой машинерии сделали набор коротких команд-рычагов: показать список проектов, открыть нужный, запустить его в работу, остановить, проверить здоровье системы, отдать задачу ИИ-агенту. Пользователю не нужно вникать во внутренности — он дёргает понятный рычаг, а сложная шина под капотом делает остальное.

Чему это учит:

• Мощную систему стоит прятать за простыми командами — тогда ей может пользоваться не только инженер.
• Хороший интерфейс — это когда сложность спрятана, а наружу торчат понятные кнопки.

Короткий вывод

Один раз собранная «шина» инструментов оказалась общей сразу для нескольких разных ИИ-приложений и для всех 28 проектов сразу — с единым порядком, отдельными изолированными «розетками», запуском по требованию, секретами в стороне и простыми командами сверху. Это и есть принцип «один mesh — много клиентов»: не настраивай каждую программу по отдельности, а построй общую основу — и подключай к ней кого угодно.

Что это за кейс. Одной летней ночью 2026 года ИИ-система сама, без человека за пультом, проверила целую группу рабочих проектов и к утру положила на стол готовый отчёт. Самое интересное здесь не «что нашла», а «как она себя вела»: строго в режиме «только чтение», ничего не меняя и не ломая. Этот кейс показывает на живом примере, из чего складывается безопасная автономия ИИ-агента.

Задача: проверить всё, пока люди спят

Ночью нет смысла будить человека ради рутины. Поэтому системе поручили простую по смыслу, но большую по объёму работу: пройтись по десятку рабочих проектов и посмотреть, всё ли с ними в порядке. Люди легли спать, а ИИ-агент только начал смену. Никто не сидел рядом и не подтверждал каждый шаг — в этом и была суть эксперимента: может ли система работать сама и при этом остаться безопасной.

Важно, что ей заранее очертили границы: не что-то «сделать» с проектами, а именно «посмотреть» и «рассказать». Разница огромная. Одно дело — доверить ночному помощнику ключи от всего, другое — попросить его только обойти помещение с фонариком и утром доложить.

Чему это учит:

• Автономию стоит включать там, где работа рутинная и объёмная, а человек всё равно недоступен.
• Прежде чем отпускать ИИ работать одного, ему чётко задают роль: «проверить и доложить», а не «делать что угодно».

Правило «только чтение»: список запретов до старта

Ещё до начала смены системе выдали короткий, но железный свод запретов. В нём было прямо перечислено, чего делать нельзя: ничего не публиковать в «боевые» рабочие системы, не менять данные клиентов, никому ничего не отправлять, ничего не удалять и не выводить наружу секреты (пароли, ключи, токены). По сути это был режим «руки за спину»: смотреть можно на всё, трогать — ничего.

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

Чему это учит:

• Безопасная автономия начинается с явного списка запретов, а не с надежды на «здравый смысл» машины.
• Режим «только чтение» позволяет доверить ИИ даже важные системы: он физически ничего не портит, потому что ему запрещено что-либо менять.

Пульс и статус: как понять, что система «жива»

Пока шла работа, система не молчала. Она вела рабочий журнал, куда записывала своё состояние: когда стартовала, сколько всего задач взяла в работу, сколько уже выполнено, сколько ошибок. Этот журнал обновлялся по ходу дела — своего рода «пульс» (heartbeat), по которому в любой момент видно: процесс идёт, система не зависла.

В нашем случае цифры были такими: десять проектов, по 50 проверок в каждом, итого пятьсот задач. И журнал честно показывал прогресс: выполнено 500 из 500. Благодаря такому статусу человеку утром не нужно гадать, «а доработала ли она до конца» — достаточно взглянуть на счётчик. Кстати, вся смена заняла меньше двух минут: для машины это огромный объём проверок за считанные мгновения.

Чему это учит:

• Автономная система должна постоянно показывать «пульс» и статус — иначе со стороны не отличить работающий процесс от зависшего.
• Простые честные счётчики («сделано X из Y, ошибок Z») дают доверие лучше, чем красивые слова об успехе.

Что именно искали

Проверки были не случайными. Среди прочего система целенаправленно искала две опасные вещи. Первое — не «утекли» ли где-то секреты: пароли, ключи и токены, которые случайно оставили прямо в коде или файлах (в отчёте это отмечено как «возможные попадания секретов»). Второе — незакрытые пометки «сделать потом» (в работе их называют TODO): места, где кто-то оставил себе напоминание доделать, да так и забыл.

По итогам обеих проверок счётчики показали нули: подозрений на утёкшие секреты — ноль, забытых «сделать потом» — ноль. Это как раз тот случай, когда «ничего не нашли» — хорошая новость. Система не стала ничего придумывать ради красивого отчёта: если находок нет, она честно пишет ноль.

Чему это учит:

• У проверки должны быть конкретные цели («ищем утёкшие секреты и забытые задачи»), а не размытое «посмотри, всё ли хорошо».
• Честный отчёт с нулями лучше выдуманных находок: доверять можно только той системе, которая не приукрашивает.

Утренний отчёт: коротко и по делу

К утру человека ждал готовый документ. В нём — не сырая гора данных, а аккуратная сводка: какой режим работы был, какое действовало правило безопасности, по каждому проекту в одну строчку итог (задачи, ошибки, подозрения на секреты, забытые задачи) и отдельный раздел «важные находки». В нашем случае в этом разделе стояло честное «серьёзных находок при этом проходе нет».

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

Чему это учит:

• Хороший итог автономной работы — это короткая понятная сводка сверху и ссылки на подробности снизу, а не свалка данных.
• Роль ИИ-агента здесь — подготовить решение, а последнее слово и любые изменения оставить человеку.

Вывод

Эта ночная смена — маленький, но показательный пример того, какой должна быть безопасная автономия. Система работала одна, быстро и без надзора — но не потому, что ей «доверяли на слово», а потому что вокруг неё выстроили правильные рамки: чёткая роль «проверить и доложить», железный список запретов, режим «только чтение», честный пульс с прогрессом и понятный утренний отчёт. Запомнить стоит главное: доверять ИИ-агенту работать самому можно тогда, когда он не может ничего сломать, постоянно показывает, что он делает, и не приукрашивает результат.

Что это за кейс. Одна команда захотела «максимально мощный» результат от ИИ и решила, что для этого нужно запустить как можно больше ИИ-агентов — чем больше, тем лучше. Разбор реального рабочего документа, подготовленного за одну неделю лета 2026 года, показал обратное: ценность даёт не количество агентов, а продуманные роли, проверки и границы. Этот кейс учит рациональной оркестрации — умению распределять работу так, чтобы не тратить силы и деньги впустую.

Соблазн «сотни агентов»

Когда человек слышит «ИИ-агент», возникает интуитивная идея: если один помощник хорош, то сто помощников будут в сто раз лучше. Отсюда желание «развернуть» большую армию агентов на любую задачу. Но каждый запущенный агент — это отдельный работник, которому надо заплатить (время, вычисления, деньги) и которого надо координировать. Итоговый вывод разбора был сформулирован прямо: правильная стратегия — не порождать сотни дорогих агентов по умолчанию.

Представьте, что вы наняли сто курьеров, чтобы отнести одно письмо. Письмо всё равно дойдёт в одном экземпляре, а платить придётся за всех сто. Массовость сама по себе не создаёт качества — она создаёт расходы и хаос согласования.

Чему это учит:

• Количество исполнителей не равно качеству результата.
• Каждый запущенный агент стоит денег и требует координации.
• «Больше агентов» — это чаще всего трата, а не сила.

Ценность в ролях-ревьюерах

Вместо армии одинаковых исполнителей в документе описан набор из 15 недорогих ролей-проверяющих (ревьюеров). Это не сто отдельных запущенных агентов, а список ролей, через который один помощник прогоняет свою работу как через чек-лист: критик, проверяющий факты, оценивающий риски и так далее. Роли применяются внутренне — тогда, когда пользователь просит «максимально» или «глубоко» проработать вопрос.

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

Чему это учит:

• Ценность создают роли и точки зрения, а не число запусков.
• Проверяющие роли можно применять как чек-лист, без дорогого распараллеливания.
• «Глубоко» и «максимально» — это про качество проверки, а не про массовость.

Когда настоящие агенты всё-таки нужны

Отказ от массового запуска не значит «никогда не запускать несколько исполнителей». В документе это оговорено отдельно: настоящих отдельных агентов имеет смысл поднимать только для ограниченной, действительно полезной параллельной работы. Ключевые слова — «ограниченной» и «полезной». Если задачу реально можно разбить на независимые куски, которые выгодно делать одновременно, — тогда несколько исполнителей оправданы.

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

Чему это учит:

• Параллельные исполнители оправданы только для отдельных, независимых частей задачи.
• Решение о запуске принимают по потребности задачи, а не для эффектности.
• Осознанное «включить» лучше автоматического «включать всегда».

Границы важнее скорости

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

Отдельно зафиксировано правило про секреты: пароли и ключи не хранятся в переписке и в памяти. Эти границы — не тормоз, а страховка. Именно они превращают «мощного, но опасного» помощника в «полезного и предсказуемого».

Чему это учит:

• Чем больше автономии у ИИ, тем важнее чёткие стоп-линии.
• Необратимые и чувствительные действия всегда требуют подтверждения человека.
• Секреты и пароли не место в чате и в памяти помощника.

Правда вперёд массовости

Прежде чем «включать мощь», в документе выстроен порядок приоритетов, и первым в нём стоит не количество агентов, а работа с фактами. Введён обязательный протокол против выдумывания: помощник должен опираться сначала на актуальные локальные данные, а не на старую историю переписки; помечать неподтверждённые утверждения как «неизвестно» или «предположение»; и давать способ проверить факт, когда доказательств не хватает.

Финальная стратегия выстроена по шагам: сначала локальные доказательства, затем протокол правды, затем 15 ролей-проверяющих как чек-лист, затем настоящие исполнители — только для ограниченной полезной параллельной работы, и в конце короткий понятный результат с фактами, честно названными неизвестными и точными следующими шагами. Сотня агентов в этот список не входит вообще.

Чему это учит:

• Достоверность данных важнее числа исполнителей.
• Честное «я не знаю» с путём проверки ценнее уверенной выдумки.
• У хорошей работы есть порядок: факты, проверка, роли, и лишь потом — распараллеливание.

Вывод

Мощь ИИ-оркестрации — не в том, чтобы запустить сто агентов, а в том, чтобы выстроить роли, проверки и границы. Сначала опираемся на проверенные факты, потом прогоняем работу через набор ролей-ревьюеров, и только для действительно независимых задач поднимаем несколько исполнителей — осознанно и под конкретную пользу. Рациональная оркестрация экономит деньги и силы и даёт результат, которому можно доверять.

Что это за кейс

Это разбор одной реальной рабочей недели в небольшой B2B-компании, которая продаёт решения для организаций. В компании пара десятков сотрудников, все сделки ведутся в CRM-системе, а в чатах сделок живёт бот-ассистент на базе ИИ. В конце недели десятки проверяющих агентов и ролей в два прохода проанализировали всю неделю: несколько сотен сделок, около двух сотен рабочих чатов, тысячи сообщений и полторы сотни задач. Каждую серьёзную находку перепроверяли отдельные агенты-«скептики» — та самая экономная схема «роли вместо толпы агентов», которую разбирает урок про пятнадцать ролей.

Все имена сотрудников, названия клиентов и суммы конкретных сделок в этом тексте убраны или заменены на условные роли. Точные количества, даты и проценты намеренно округлены до долей и порядков, чтобы ни компанию, ни конкретных людей нельзя было опознать; пропорции и сама логика событий — настоящие. Это честная картина того, что агенты умеют делать сами, а где без человека не обойтись.

---

1. Как был устроен эксперимент

Агенты работали в режиме «только отчёт»: они читали, считали и делали выводы, но не меняли ничего в сделках без людей. Анализ шёл в два прохода: первый — аудит всей недели (что происходило в сделках, чатах и задачах), второй — глубинный разбор взаимодействий «человек — бот». Ключевые выводы прогонялись через агентов-скептиков: отдельные агенты специально пытались опровергнуть каждую находку, и в отчёт попадало только то, что выдержало проверку.

Чему это учит:

• Сила агентов — в массовом чтении: человек физически не может за день перечитать тысячи сообщений, агент — может.
• Выводам одного агента нельзя верить на слово: перепроверка (в этом кейсе — другими агентами) обязательна.
• Рабочая схема разделения ролей: агент собирает факты и предлагает, человек решает.

---

2. Мёртвая воронка: жизнь лишь в каждой шестой сделке

Главная находка недели: из более чем трёхсот открытых сделок живые человеческие сообщения за неделю были лишь примерно в каждой шестой. По деньгам примерно две трети суммы всей воронки висело в одной стадии («выставлен счёт») без движения — многие сделки стояли так месяцами, а некоторые — годами. Внешне CRM выглядела наполненной и рабочей. По факту — это была витрина, а не воронка.

Никто из людей этого не видел месяцами. Агентам, чтобы это показать, понадобился один прогон по данным и одна простая метрика: «есть ли в сделке живое сообщение за неделю».

Чему это учит:

• Красиво заполненная CRM не равна здоровому бизнесу; понять разницу помогает простая проверка на «признаки жизни».
• Метрики для агента стоит делать примитивными и однозначными — «было сообщение / не было» работает лучше сложных оценок.

---

3. Зомби-сделки: клиент давно ушёл, а сделка живёт

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

Агент отлично находит такие сделки по формальным признакам (дата последнего сообщения, слова отказа в переписке). Но закрыть сделку он не вправе — решение «реанимировать или списать» осталось за людьми, и именно на этом шаге всё застряло: закрывать сделки психологически тяжело, это признание потери.

Чему это учит:

• Агент — хороший «детектор правды»: ему не жалко и не стыдно называть сделку мёртвой.
• Финальное решение о судьбе сделки — человеческое; но без дедлайна и контроля люди его откладывают бесконечно.
• Прогноз, построенный на нечищеной воронке, — это самообман в масштабах компании.

---

4. Деньги недели: бот увидел все оплаты первым

Все поступившие за неделю оплаты (несколько продлений от клиентов) первыми заметил бот — он прислал уведомления в чаты сделок в день поступления. Но дальше началось человеческое: по одной оплате никто не перевёл сделку в следующую стадию, по другой ответственный менеджер не реагировал на уведомление три дня.

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

Чему это учит:

• Агент — идеальный «сторож событий»: он не пропустит оплату, письмо или дедлайн.
• Уведомление, на которое можно не реагировать, — это просто шум; у каждого сигнала должен быть обязательный следующий шаг.
• Прежде чем винить рынок, посмотрите на внутренние петли согласований — агенты умеют измерять их длительность.

---

5. Петля «проверь — неправильно — исправь»

В компании было важное правило о том, от какого юридического лица и с каким налогом выставлять документы. Проблема: правило существовало только в головах. Проверял его один-единственный сотрудник, отвечал односложно («не правильно») и с задержкой до суток. Результат за неделю: несколько полных циклов «сделал — забраковали — переделал», больше двух потерянных рабочих дней, а одна такая петля крутилась дольше недели — причём даже такая ручная проверка не гарантировала от пропущенных ошибок.

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

Чему это учит:

• Агент не может контролировать правило, которого нет на бумаге. Формализация — один лист текста — экономит дни работы.
• Единственный человек-контролёр — узкое место всей компании; рутинную часть проверки можно и нужно отдать агенту.
• Односложная обратная связь («неправильно» без объяснения) порождает лишние итерации — это верно и для людей, и для агентов.

---

6. Воронка команд: отвечено шесть из десяти

За неделю люди дали боту около трёх десятков реальных команд. Ответ получили лишь примерно шесть из десяти. Остальные команды пропали молча — большинство из-за одного бага: обращение к боту, набранное текстом вручную, не распознавалось. Зато из отвеченных команд примерно четыре из пяти сразу привели к действию человека: следующая команда, передача коллеге, отправка на расчёт. Скорость ответа была отличной: обычно около минуты.

Самая дорогая потеря — первые команды новичков. Один из руководителей впервые написал боту — бот промолчал. Человек, чья первая попытка провалилась, почти никогда не пробует второй раз.

Чему это учит:

• Главные потери в работе с агентом — на входе (нераспознанные обращения), а не в качестве ответов.
• Молчание бота хуже честного «не понял, уточните» — при нераспознании агент обязан переспросить.
• Первый опыт пользователя решает всё: одна потерянная первая команда — минус один пользователь навсегда.

---

7. Обратная воронка: когда пишет бот, а молчат люди

За неделю бот отправил людям около полусотни сообщений-«пушей» (уведомления об оплатах, черновики документов, напоминания). Хоть какая-то реакция в чате была на большинство из них — но именно ответственный за сделку отреагировал лишь примерно в четверти случаев. Типичное время реакции ответственного — почти сутки (против минут, когда в чате присутствовал руководитель). Часть сотрудников показала нулевую реакцию — «невидимки», которые уведомления бота просто не читают.

Отдельная беда — шум: каждое пятое сообщение бота было служебным («всё ещё работаю…») или дублем. Люди приучились проматывать бота не читая.

Чему это учит:

• Спам от агента убивает доверие быстрее, чем его ошибки: один результат — одно сообщение, и точка.
• Сообщение без требования подтверждения («ОК» от ответственного) — это сообщение в никуда; нужны квитирование, повтор и эскалация руководителю.
• Агент должен знать, когда человек реально бывает онлайн: у каждого сотрудника есть свои «пики входа», и повтор уведомления надо отправлять именно в них.

---

8. Персональные «разборы сделок»: сработала треть

В середине недели бот разослал полтора десятка персональных «разборов сделки»: по каждой — диагноз и конкретный следующий шаг («сегодня позвонить, зафиксировать результат в чате»). Итог к следующему дню: ожила примерно треть чатов, лично ответственный отреагировал в единичных случаях, а полностью шаг был выполнен лишь в одной сделке. Прописанные в текстах эскалации («если тишина — вопрос уходит руководителю») не сработали ни разу — они остались словами.

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

Чему это учит:

• Рассылка рекомендаций без контроля исполнения отрабатывается примерно на треть — нужен механизм, который проверяет выполнение шага.
• Данные для автоматической рассылки надо перепроверять на свежесть в момент отправки, а не в момент подготовки.
• Эскалация, прописанная текстом, не запускается сама — её тоже должен исполнять агент или процесс, а не совесть сотрудника.

---

9. Где агент ошибался — и как это чинили

Отчёт честно зафиксировал зону сбоев бота: перепутал один продукт с другим в техническом задании, «галлюцинировал» о текущем месяце, несколько раз подряд написал одно и то же сообщение об ошибке, обрывал ответы по таймауту, а однажды прислал «готово — ответ ниже» без самого ответа. При этом зона доказанной пользы (сгенерированные за минуты документы, вовремя замеченные оплаты, пойманные ошибки в реквизитах) по деньгам оказалась примерно в полтора раза больше зоны сбоев.

Важнее другое: за одни сутки после отчёта основные баги были исправлены — распознавание любых обращений к боту, ответ строго после фактической отправки результата, увеличенные таймауты с авто-повтором, один прогресс-апдейт вместо потока служебных сообщений, а вычищенное налоговое правило зашито во все документы.

Чему это учит:

• Агент в реальной работе будет ошибаться — вопрос не в том, ошибается ли он, а в скорости обнаружения и починки.
• Каждый сбой должен превращаться в конкретное правило или исправление, иначе он повторится.
• Честный баланс «польза против вреда» в измеримых величинах — лучший аргумент и для скептиков, и для энтузиастов.

---

10. Почему ботом пользовалась лишь четверть команды — и план внедрения

За неделю боту давал команды лишь примерно каждый четвёртый сотрудник, причём львиная доля всех команд пришлась на одного человека — руководителя, который эту систему и завёл. Часть самых загруженных сотрудников компании вообще ни разу не соприкоснулась с ботом — ни команды от них, ни уведомления им. Технология работала, но команда её не приняла.

План, который сформировали агенты: (1) живые 15-минутные онбординги в реальные «пики входа» сотрудников, где каждый даёт одну команду в своей сделке и видит результат; (2) снять входной барьер — бот отвечает на любое обращение и переспрашивает вместо молчания; (3) квитирование уведомлений с повтором и эскалацией; (4) персональные сценарии для «тяжеловесов» вне контура; (5) еженедельная сводка пользы в общий чат. Целевая метрика: утроить число активных пользователей за месяц.

Чему это учит:

• Технология сама себя не внедряет: без онбординга агентом пользуется только тот, кто его завёл.
• Лучший онбординг — одна успешная команда в собственной, а не учебной, сделке.
• Польза агента должна быть видимой: регулярная сводка «что бот сделал за неделю» работает лучше любых уговоров.

---

Итоговая таблица: агент справился сам / понадобился человек

Задача	Агент справился сам	Понадобился человек
Прочитать сотни сделок и тысячи сообщений, найти мёртвые зоны воронки	Да	—
Заметить оплаты и события в день поступления	Да	—
Сгенерировать документы за считанные минуты (акт, коммерческое предложение)	Да	—
Поймать ошибку в реквизитах и налоговом правиле до отправки клиенту	Да (после формализации правила)	Правило сначала записал человек
Найти зомби-сделки и сделки, заблокированные молчанием	Да	—
Решить судьбу зомби-сделки: реанимировать или закрыть	—	Только человек
Позвонить клиенту, дожать недозвон	—	Только человек
Ответить на вопрос подчинённого по сделке	—	Только человек (и это было главным узким местом)
Проконтролировать выполнение рекомендованных шагов	Частично (разослал разборы)	Без человека выполнена треть
Эскалация при молчании ответственного	Нет (осталась словами)	Нужен человек или доработка агента
Починить сбои и баги самого бота	—	Разработчик, за сутки
Внедрить ассистента в привычки команды	—	Живой онбординг людьми

Главный вывод кейса. Агенты за неделю сделали то, что не по силам ни одному сотруднику: перечитали всю переписку компании, измерили здоровье воронки и назвали вещи своими именами. Но каждый найденный ими рубль двигали (или не двигали) люди. ИИ-агент — это рентген и сторож, а не хирург: диагноз он ставит блестяще, решение и действие остаются за человеком.