ИИ — это не волшебство и не простая формула «запусти программу — получи прибыль». На самом деле большинство людей не понимают, что такое искусственный интеллект.
Из тех, кто действительно разбирается — их меньше 5% — многие пытаются создавать собственные решения и терпят неудачу. ИИ-агенты могут выдавать ложные результаты, терять ход выполнения задачи или ошибочно запускать инструменты не вовремя. Демонстрация может пройти идеально, но в реальной эксплуатации всё рушится.
Более года я внедряю ИИ-программы. Моя карьера началась в Meta, а полгода назад я ушёл, чтобы основать компанию по внедрению ИИ-агентов для бизнеса. Наш годовой повторяющийся доход достиг $3 млн и продолжает расти. Это не из-за нашей гениальности — мы прошли через множество попыток, ошибок и в итоге нашли рабочую формулу успеха.
Вот мои выводы о создании эффективных ИИ-агентов. Независимо от вашего уровня — новичок, эксперт или что-то между ими — эти инсайты будут полезны.
Это кажется очевидным, и вы наверняка слышали это раньше. Но значение этого принципа невозможно переоценить. Многие думают, что создание агента — это просто связать несколько инструментов: выбрать модель, открыть доступ к базе данных и запустить работу. Такой подход сразу терпит неудачу по нескольким причинам:
Агенты не понимают приоритеты. Они забывают, что происходило несколько шагов назад, видят только текущий момент и пытаются угадать, что дальше — часто ошибаясь и полагаясь на случай.
Контекст — это ключевое отличие между агентами, приносящими миллионы, и бесполезными решениями. Сосредоточьтесь на оптимизации следующих моментов:
Память агента: не только текущая задача, но вся история, которая к ней привела. Например, при обработке аномалий по счету агенту нужно знать, как возникло исключение, кто отправил счет, какая политика применима и как решались прошлые вопросы с этим поставщиком. Без этих данных агент просто гадает — хуже, чем если бы его не было вовсе. Человек, скорее всего, уже решил бы проблему. Поэтому и говорят: «ИИ сложно использовать».
Информационный поток: если работает несколько агентов или многоэтапный процесс, информация должна передаваться между этапами без потерь, искажений или ошибок. Агент, который классифицирует запросы, должен передавать чистый структурированный контекст агенту, который решает проблему. Если передача неточная, весь процесс рушится. Значит, на каждом этапе нужны проверяемые структурированные входные и выходные данные. Например, функция /compact в Claude Code передаёт контекст между сессиями LLM.
Экспертиза в предметной области: агент, проверяющий юридические контракты, должен знать, какие пункты важны, как оценивать риски и какие реальные политики у компании. Нельзя просто загрузить документы и ждать, что агент сам разберётся — это ваша задача. Необходимо структурировать ресурсы, чтобы агент действительно освоил предметную область.
Плохое управление контекстом выглядит так: агенты многократно вызывают один и тот же инструмент, потому что забыли ответ, запускают неверный инструмент из-за неправильных данных, принимают решения, противоречащие предыдущим шагам, или воспринимают каждую задачу как новую, игнорируя явные шаблоны из прошлого.
Хорошее управление контекстом позволяет агентам работать как опытные бизнес-эксперты, связывать информацию без явных инструкций.
Контекст — это то, что отличает «демо-агентов» от реально работающих в продакшене.
Ошибка: «Теперь нам не нужны сотрудники».
Правильный подход: «Теперь трое делают работу, которая раньше требовала пятнадцати».
Агенты постепенно заменят часть ручной работы — отрицать это бессмысленно. Плюс в том, что агенты не заменяют человеческое мышление, а устраняют рутину вокруг него — поиск данных, сбор информации, сверка, форматирование, распределение задач, напоминания и другое.
В финансовых командах решения по аномалиям принимают люди, но с агентами они не тратят 70% времени на поиски недостающих документов в конце месяца. Эти 70% уходят на решение реальных задач. Агенты делают основную работу, люди — финальную проверку. В моих проектах компании не сокращают штат. Сотрудники переходят с рутинных задач на более ценные — по крайней мере, сейчас. В долгосрочной перспективе, по мере развития ИИ, ситуация может измениться.
Выгоду получают не те, кто пытается убрать людей, а те, кто понимает: большинство времени уходит на подготовительную работу, а не на создание ценности.
Если проектировать агентов с этим учётом, точность перестаёт быть навязчивой идеей: агенты делают то, в чём сильны, люди — то, что у них получается лучше всего.
Это ускоряет внедрение. Агентам не нужно обрабатывать все исключения — достаточно охватить типовые случаи и передавать сложные задачи людям с достаточным контекстом для быстрого решения. Пока это оптимальная стратегия.
То, как агенты хранят информацию внутри и между задачами, определяет масштабируемость.
Три распространённых схемы:
Автономный агент: ведёт весь рабочий процесс от начала до конца. Самый простой вариант, так как весь контекст централизован. Но по мере роста процессов управление состоянием усложняется — агенту нужно помнить решения на третьем шаге и применять их на десятом. Если окно контекста переполнено или структура памяти неверна, поздние решения принимаются без учёта ранних, что приводит к ошибкам.
Параллельные агенты: одновременно решают разные части задачи. Быстрее, но возникают сложности с координацией — как объединять результаты? Что, если агенты не согласны? Нужно чётко прописать протоколы интеграции информации и разрешения конфликтов, часто с «арбитром» (человеком или LLM) для споров и гонок.
Коллаборативные агенты: передают задачи по цепочке. Агент A классифицирует, B исследует, C выполняет. Хорошо подходит для процессов с чёткими этапами, но передача между агентами — слабое место: выводы A должны поступать к B в пригодном для работы виде.
Главная ошибка: воспринимать это как «планы внедрения». На самом деле это архитектурные решения, определяющие возможности агента.
Например, если строить агента для согласования контрактов, нужно решить: один агент выполняет всё или маршрутизатор распределяет задачи между специалистами по ценообразованию, юридическим вопросам и руководству? Только вы знаете реальный бизнес-процесс — и должны обучить ему агента.
Как выбрать? Всё зависит от сложности каждого этапа, объёма передаваемого контекста и необходимости в реальном времени или последовательном выполнении.
Если ошибиться с архитектурой, придётся месяцами устранять не баги, а несоответствия между дизайном, задачей и решением.
У многих первая реакция при создании ИИ — сделать дашборд для отображения ситуации. Пожалуйста, перестаньте делать дашборды.
Дашборды не решают проблему.
Ваша финансовая команда и так знает о недостающих чеках, а отдел продаж — о контрактах, застрявших в юридическом отделе.
Агенты должны перехватывать проблемы в момент их возникновения, сразу передавать ответственному лицу и предоставлять всю необходимую информацию для быстрого решения.
Есть счёт без документов? Не просто фиксируйте это. Мгновенно помечайте, определяйте, что отсутствует, и отправляйте проблему — со всеми деталями (поставщик, сумма, политика, специфика) — ответственному. Блокируйте транзакцию до решения. Это критически важно, иначе проблемы распространяются по всей компании, и вы опоздаете с их устранением.
Согласование контракта задерживается на 24 часа? Не ждите еженедельной встречи. Автоматически эскалируйте вопрос с деталями транзакции, чтобы лицо, принимающее решение, могло быстро разобраться — без поиска по системам. Создайте срочность.
Поставщик не выполнил этап? Не ждите, пока кто-то заметит. Запускайте аварийные протоколы автоматически, ещё до того как проблема станет очевидной.
Задача агента — сделать проблемы невозможными для игнорирования и простыми для решения.
Выявляйте проблемы напрямую — не только через дашборды.
Это противоположно тому, как большинство компаний используют ИИ: они «видят» проблемы, а вы должны «заставлять» их решаться — быстро. Когда процент решённых задач приблизится к 100%, тогда можно думать о дашборде.
Есть причина, по которой компании продолжают покупать SaaS, которыми никто не пользуется.
SaaS легко купить: демонстрация, коммерческое предложение, галочка в списке требований. Кто-то одобряет покупку и считает, что дело сделано — хотя это редко так.
Главная проблема ИИ SaaS: он просто существует. Не интегрируется с реальными процессами и становится ещё одной точкой входа. Нужно переносить данные, а через месяц это просто ещё один поставщик. Через год его забрасывают, но затраты на переход сохраняются — появляется «технический долг».
Индивидуальные агенты, построенные на ваших текущих системах, избегают этих проблем.
Они работают внутри существующих инструментов, не добавляют новых платформ и ускоряют работу. Агенты выполняют задачи, люди проверяют результаты.
Реальное сравнение затрат — не «разработка против лицензии», а гораздо проще:
SaaS создаёт технический долг: каждый новый инструмент — это дополнительные интеграции, ещё одна устаревающая система и поставщик, который может быть куплен, сменить направление или закрыться.
Собственные агенты — это развитие: каждое улучшение делает систему умнее, каждый новый процесс расширяет возможности. Инвестиции накапливаются, а не обесцениваются.
Я говорил год: у типовых ИИ SaaS нет будущего. Данные отрасли это подтверждают — большинство компаний отказываются от ИИ SaaS за шесть месяцев, не получая никаких приростов производительности. Реальная ценность ИИ — в индивидуальных агентах, созданных внутри компании или сторонним разработчиком.
Поэтому ранние внедренцы агентов получают долгосрочные структурные преимущества — они строят инфраструктуру, которая становится сильнее. Остальные просто арендуют инструменты, которые придётся заменить. В быстро меняющейся сфере потеря даже недели — серьёзный удар по вашему плану и бизнесу.
Если запуск ИИ-агента занимает год, вы уже проиграли.
Планы не поспевают за изменениями. Проектирование рабочих процессов редко соответствует реальности, а самые важные случаи — это те, которые вы не учли. Через год ИИ может быть совершенно другим — ваш проект устареет.
Три месяца максимум — запускайте в продакшен.
В современном мире избытка информации главное — умение эффективно использовать её и работать совместно. Решайте реальные задачи, принимайте решения, оставляйте проверяемые следы.
Частая проблема: внутренние команды оценивают трёхмесячные проекты ИИ как шесть–двенадцать месяцев. Или ещё хуже — обещают три месяца, а затем бесконечно откладывают запуск из-за «непредвиденных причин». Это не всегда их вина — ИИ действительно сложен.
Вот почему нужны инженеры, которые действительно понимают ИИ — знают, как его масштабировать, сталкивались с реальными проблемами, понимают сильные и слабые стороны. Слишком много «сырых» разработчиков думают, что ИИ способен на всё — это далеко не так. Если вы разработчик, стремящийся к корпоративному ИИ, вы должны знать его реальные границы.
Вот что важно для рабочих агентов:
Контекст — главное: без надёжного контекста агент — просто дорогой генератор случайных чисел. Обеспечьте поток информации, постоянную память и интеграцию знаний о предметной области. «Промпт-инжиниринг» был старой шуткой, теперь «контекст-инжиниринг» — версия 2.0.
Проектируйте для усиления, а не замены: люди должны делать то, в чём они сильны, агенты — создавать условия для концентрации.
Архитектура важнее выбора модели: решение между автономными, параллельными или коллаборативными агентами гораздо значимее, чем выбор модели. Определите архитектуру правильно.
Перехватывайте и решайте, а не просто фиксируйте и анализируйте: дашборды — кладбище проблем. Создавайте системы, которые заставляют быстро решать задачи.
Внедряйте быстро, постоянно улучшайте: лучший агент уже работает и развивается — не застрял на этапе проектирования. (И следите за сроками.)
Всё остальное — детали.
Технологии готовы, а вы — возможно, нет.
Поняв это, вы сможете увеличить бизнес в 100 раз.





