ИИ-агенты для бизнеса: три сценария из работы над продуктом

В команде Эсборда мы используем ИИ-агентов для технического ревью, проектирования архитектуры, SEO и подготовки статей. Это не история о компании без сотрудников и не обещание заменить специалиста одним запросом. Полезнее показать, какую часть работы можно передать агенту и где остаётся ответственность человека.

Чем агент отличается от чата и автоматизации

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

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

Сценарий 1. Техническое ревью

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

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

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

Сценарий 2. Проектирование архитектуры

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

Хороший артефакт содержит не только блоки и связи, но и основания выбора. Что произойдёт при недоступности внешнего сервиса? Где хранится состояние? Кто имеет право изменить данные? Какие предположения пока не проверены? Схема без этих ответов может выглядеть убедительно и всё же быть непригодной для реализации.

На общей доске с MCP такой черновик можно превратить в редактируемую схему и разобрать с командой. Доступ к доске не означает разрешение менять любую её часть: область работы нужно указать явно.

Сценарий 3. SEO и статьи

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

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

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

Где возникают ошибки и чего мы не обещаем

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

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

Как начать с малого

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

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