Как создать ИИ-агента и запустить его в процессах компании: опыт Napoleon IT, World Chess и X5

Привет! Меня зовут Анастасия Федина, я руковожу AI-трансформацией в Napoleon IT. Последний год моя команда занимается ровно одним: переводит компанию из состояния «все пользуются ИИ» в состояние «ИИ реально влияет на сроки и стоимость наших проектов». Это, как выяснилось, две очень разные вещи, и расстояние между ними больше, чем кажется.

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

Цифры это подтверждают. По данным McKinsey State of AI 2025, ИИ внедрили около 78% компаний, но заметно влияет на прибыль он лишь у малой части — порядка 5%. Остальные застряли на экспериментах: люди пользуются ИИ поодиночке, а сроки и затраты компании стоят на месте.

Дальше — как мы выбираемся в эти 5%. Расскажу на нашем опыте в Napoleon IT и подкреплю кейсами коллег: Александра Пантелеева, CTO World Chess, и Виталия Лукина, директора по ИИ-агентам в X5.

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

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

И вот тут я столкнулась с неприятной правдой: на общий результат это почти не повлияло. Каждый сотрудник стал работать быстрее, а проекты — нет.

Вот конкретный пример из нашей разработки. Аналитик стал готовить требования за два дня вместо недели и отдал результат на ревью разработке. Они положили его в свой список задач и разобрали в обычном порядке. Сквозное время процесса — Cycle Time — не сдвинулось: этап ускорился, а очередь на стыке съела весь выигрыш.

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

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

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

Александр Пантелеев, CTO World Chess и преподаватель курса «ИИ-автоматизация», добавляет еще три фильтра из своей практики (он автоматизировал перевод всего контента портала на 14 языков):

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

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

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

Самая частая причина, по которой агент не приживается, — отсутствие контекста. Если он не знает, что уже реализовано в системе, он генерирует все с нуля. На выходе формально корректные, но оторванные от реальности артефакты. Мы зовем таких агентов «додумывателями»: внешне результат готов, а при проверке половина системы не учтена. Это хуже, чем отсутствие результата, — создается иллюзия прогресса.

Здесь стоит различать две вещи: где и в каком виде лежит документация и как агент к ней обращается.

Где хранить. Лучший вариант — markdown-файлы в git-репозитории (подход doc-as-code). Markdown языковая модель читает лучше всего, а git дает версии и совместную работу. Confluence и Word для этого не годятся: агент плохо работает с их форматированием, а его результат не ложится обратно в процесс. В этих файлах живет контекст системы — объектная модель, реализованные функции, бизнес-процессы.

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

Когда стало ясно, что обмена промтами мало, мы взяли этап discovery — от бизнес-заявки до проработанных требований — и пересобрали его целиком. Три шага.

Первое — стандартизировали работу аналитиков через единый набор AI-агентов. Раньше каждый работал изолированно: свои промты, свой контекст, своя логика. Теперь это общий интеллектуальный слой для роли, который лежит в корпоративном git: сотрудник перед новой задачей скачивает обновленный репозиторий со свежими навыками и работает по нему. Для ряда ролей это уже стандарт — результат принимается, только если он сделан через наш ИИ-слой. Логика жесткая: некорректно сформированный результат в начале цепочки ломает все, что идет дальше.

Второе — перевели аналитиков на doc-as-code (markdown + git). Звучит странно для нетехнической роли, но иначе агент не может нормально работать с документацией, а его результат не ложится обратно в процесс. Переход дался не сразу: через инструкции на каждый шаг, демо-встречи и персональную поддержку. И вот неожиданное наблюдение про сопротивление: сами аналитики, которые работают с инструментом руками, дают позитивную обратную связь. Сопротивляется средний менеджмент — руководители, для которых изменение процесса угрожает выстроенным планам. Поэтому мы работаем с исполнителями напрямую и собираем обратную связь лично.

Третье — ужесточили стыки. Стандарт передачи у нас был и раньше, но на практике каждый аналитик добавлял в документ что-то «от себя»: чуть другую структуру, свой формат описания. Вроде по шаблону — а каждый раз по-разному, и на стыке с разработкой это все равно требовало ручной доводки. Теперь результат discovery — это структурированный набор артефактов, каждый в едином формате, который AI-разработчик подхватывает и превращает в задачи без ручного перекладывания. Именно сшивка этих стыков, а не ускорение отдельного шага, и двигает Cycle Time.

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

Второй типовой провал — доверие к правдоподобному результату. Агент может выдать SQL, который тихо удвоит строки: цифры красивые, а вдвое больше правды. Лечится самопроверкой агентов и алертами на странные метрики. Доверие строится на проверке, а не на вере.

Свои предостережения добавляет и Виталий Лукин:

У нас в Napoleon IT (пилот в нескольких командах): проработка требований — 40–60 часов → 6 часов; 3 из 3 проверок концепции подтвердили гипотезу; владелец продукта за 5 дней без аналитиков проработал 6 эпиков, а команда продукта сжимается с 5–7 ролей до 2.

World Chess: backfill из 113 статей × 14 языков ≈ 1580 переводов за ~2,5 часа вместо месяцев. Ручной эквивалент прогона — десятки тысяч долларов, автоматический — единицы. По сути компания получила мультиязычный портал без расширения штата.

X5: эффект под NDA, но порядок — «сотни миллионов». Зрелость уже мультиагентная: анализом новостной повестки и трендов занимаются 19 агентов.

Самое стойкое заблуждение — что нужен инженер. Я не инженер. Моя работа — видеть процесс целиком: где узкие места, как данные текут между этапами, что мешает людям работать по-новому. Я проектирую подход — какой навык нужен, для какой роли, что он делает, какой контекст ему дать. Техническую реализацию я довожу в связке с техлидом AI-инструментов.

Команда изменений у нас устроена так: я — координация и управление проектами; техлид — техническая реализация; амбассадоры в ролях — первыми берут новые инструменты и дают обратную связь; спонсоры на уровне бизнеса (COO и CEO) — лоббируют изменения и обрабатывают сомнения. Решали не технические навыки, а системное мышление, управление изменениями и умение переводить между языком бизнеса и языком технологий.

И собрать агента реально без разработчика. Пантелеев прямо называет себя «не разработчиком» — и сам собрал production-систему на 14 языков, проектируя ее в паре с Claude: тот помогал разбирать баги по логам, писать код для узлов n8n и рисовать схемы. No-code-инструменты сместили порог: агента собирает тот, кто понимает задачу, а инженер подключается там, где нужна глубокая интеграция.

Чтобы это не звучало как история успеха, вот наши грабли.

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

Но главный урок такой: разработать AI-агента — это половина задачи. Главное — внедрение: люди, привычки, переучивание, сопротивление, новые регламенты. Без глубокой работы с внедрением любой MVP остается на полке. Если коротко, разницу между двумя подходами я для себя сформулировала так: обучение делает быстрее одного человека, а внедрение делает быстрее бизнес.

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

Короткий чек-лист, чтобы не упустить главное:

Дальше все упирается в ремесло — как делать это стабильно и доводить до прода, где ломается большинство. Этому уже учат отдельно.

Если за время чтения вы согласились, что ИИ-агент — рабочий инструмент, а не хайп, логичное продолжение — научиться собирать их системно. Этому учит курс «ИИ-автоматизация: проектирование и запуск агентных систем» (karpov.courses × AI Talent Hub, ИТМО): среди преподавателей — и Александр Пантелеев, и Виталий Лукин, чьи кейсы вы видели выше. Курс построен вокруг вашего процесса: первую рабочую автоматизацию вы собираете уже на первой неделе, а к концу — агентную систему, которая работает без вас. Без программирования, агента вы проектируете и собираете сами. На выходе — рабочий прототип под ваши задачи и диплом ИТМО.

Программа курса

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

2. Как дать агенту контекст системы? Хранить документацию (объектную модель, реализованные функции) как markdown-файлы в git — подход doc-as-code. Если контекста немного, он подается агенту целиком; если документов много — подключают RAG, и агент находит нужные фрагменты по смыслу.

3. Почему ИИ ускоряет сотрудника, но не проект? Ускоряется один шаг, а Cycle Time держат стыки и ожидание на других этапах. Автоматизировать нужно переходы между ролями.

4. Нужен ли программист? Нет. На no-code-инструментах агента проектирует и собирает тот, кто понимает задачу; инженер нужен для глубоких интеграций.

5. Где чаще всего ломается? На обработке ошибок в проде, на доверии к правдоподобному результату и на сопротивлении среднего менеджмента.