Архитектура AI-агентов: размещайте агентов на границе рабочего процесса

Почему всё быстро становится запутанным

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

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

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

Небольшой пример из службы поддержки показывает, как быстро всё идёт не так. Пользователь пишет: "Пожалуйста, используйте тот же способ оплаты, что и ранее, и передайте управление этим аккаунтом моему коллеге." Один агент мог бы определить, какую карту применять, кто этот коллега, обновить аккаунт и инициировать возврат. Если хотя бы одна часть предположения неверна, компания получает одновременно проблему с оплатой и с доступом.

Доверие падает даже быстрее, чем точность. Люди готовы принимать подсказки от инструмента, но нервничают, когда он меняет права или редактирует записи без понятного правила. Если никто не может объяснить, почему изменился доступ, система начинает казаться случайной.

Вот где команды застревают. Казалось, что они покупали скорость, но по сути дали одному агенту слишком много свободы там, где бизнесу нужны жесткие правила.

Что значит граница рабочего процесса

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

Это важно, потому что на границе полно недостающих деталей, смешанных сигналов и странных формулировок. Клиент может написать: "Я сменил банк в прошлом месяце и меня всё ещё списали дважды. Можете исправить мой аккаунт и вернуть деньги?" Правилам будет сложно, если весь этот текст сразу толкнуть в бизнес-логику. Агент может разделить запросы, заметить неясность и задать один уточняющий вопрос вместо рискованной догадки.

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

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

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

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

За что должны отвечать детерминированные сервисы

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

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

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

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

Утверждения и смены состояния должны иметь полный аудит. Когда кто-то обновляет адрес биллинга, выдаёт возврат или разблокирует аккаунт, сервис должен записать, кто запросил, кто утвердил, что изменилось и когда. Если позже финансы или поддержка будут разбирать дело, им нужны факты, а не размытое резюме чата.

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

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

Как работает передача

Чистая передача сохраняет полезность агента, не давая ему трогать рискованные части системы. Агент слушает беспорядочный ввод, затем передаёт небольшой, «скучный» запрос в код, который соблюдает фиксированные правила.

Первый шаг — перевод. Пользователь пишет что-то размытое, например: "Перенесите этот платёж на следующий месяц и оставьте мой текущий доступ." Агент не должен действовать по этому тексту напрямую. Он превращает его в короткий структурированный запрос с полями: тип действия, ID аккаунта, дата и причина. Меньше — лучше. Если агент придумывает лишний смысл, остальной поток становится шатким.

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

Этот валидатор должен оставаться строгим. Он не угадывает. Если в запросе указано "сменить владельца", а список разрешённых действий включает только "сменить контакт для выставления счёта", система должна остановиться.

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

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

Когда команды пропускают эту последовательность, агент начинает действовать как скрытый бэкенд. Тогда ошибки становятся дорогими.

Как встроить агента в поток

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

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

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

Это важнее, чем многие команды ожидают. Агент может читать, суммировать, извлекать намерения и задавать уточняющие вопросы. Он не должен быть тем, кто делает возврат, даёт админ-доступ или переписывает запись клиента. Детерминированный сервис всегда сможет проверить состояние аккаунта, политику, лимиты и правила аудита одинаково.

Думайте об агенте как о переводчике, а не кассире.

Пример из поддержки ясно это показывает. Клиент пишет: "Меня списали дважды и я потерял доступ после смены email." Агент может разделить это на два структурированных запроса: проверка возврата и восстановление доступа. После этого отдельные сервисы проверяют историю платежей, подтверждают личность, проверяют правила доступа и решают, разрешено ли каждое действие.

Тестируйте поток плохим вводом до релиза. Используйте размытые запросы, отсутствующие поля, попытки инъекций подсказок и запросы, которые должны провалиться. Если агент путает действия, пропускает поле или делает рискованную догадку, вы хотите поймать это в тестировании, а не в продакшне.

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

Простой пример с возвратами и изменениями аккаунта

Клиент отправляет одно сообщение поддержки: "Пожалуйста, верните деньги за заказ 48291 и смените мой адрес для выставления счета на [email protected]." Агент читает заметку, выделяет номер заказа и разделяет сообщение на две задачи: запрос на возврат и запрос на обновление аккаунта.

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

Запрос на возврат идёт в сервис возвратов. Сервис проверяет сумму оплаты, статус заказа и политику возврата. Он задаёт простые вопросы: был ли платёж завершён? Уже был возврат по этому заказу? Находится ли заказ в пределах допустимого окна возврата? Затем он возвращает явный результат, например: "одобрен на $49" или "отклонён: заказ старше 30 дней."

Изменение email идёт в сервис аккаунта. Он должен быть строже. Смена email влияет на квитанции, счета и восстановление доступа. Поэтому сервис запрашивает доказательство личности перед любыми изменениями. Это может быть одноразовый код на текущий email, активная сессия или другой одобренный чек. Пока проверка не пройдена, сервис оставляет изменение в состоянии ожидания.

Теперь у агента два структурированных результата. Он может составить итоговый ответ простым языком:

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

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

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

Ошибки, которые делают команды

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

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

Хитрости, которые стоят денег

Ещё одна распространённая ошибка — прятать бизнес-правила в подсказках. Подсказку легко изменить и трудно проверить. Если ваша политика возвратов говорит "30 дней, исходный способ оплаты, без признаков мошенничества," реализуйте это в коде, а не в абзаце, который читает модель. Подсказки могут объяснять задачу, но не решать политику.

Маленькие потоки часто пропускают логи, потому что кажутся безвредными. Такое решение плохо стареет. Когда клиент спрашивает: "Почему система сменила мой адрес?" или финансы спрашивает, почему прошёл возврат, вам нужен след запроса, использованные данные, выполненные проверки и финальное действие. Если вы не можете воспроизвести путь, вы не сможете уверенно исправить ситуацию.

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

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

Хорошее правило простое: пусть агент говорит, суммирует и готовит. Пусть детерминированные сервисы проверяют, принимают решение и записывают.

Бырые проверки перед запуском

Если агент может затрагивать деньги, записи или права доступа, вам нужна короткая предзапускная проверка, на которую реальная команда ответит за пару минут. Если ответы размыты, дизайн ещё не готов.

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

Логи важны не меньше. Сотрудник поддержки должен иметь возможность воспроизвести решение и увидеть, что видел агент, какие данные были переданы, какой сервис ответил и почему финальное действие произошло. Если лог просто говорит "модель одобрила", этого недостаточно.

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

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

Ещё одно правило: закройся при ошибке. Если агент неуверен или ввод неполный, остановите действие и запросите доп.

Пауза в потоке раздражает. Неправильный платёж или неверное изменение прав хуже.

Следующие шаги для вашей команды

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

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

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

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

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

Здесь архитектура перестаёт быть теорией и становится рабочей моделью. Люди понимают, что агент может предложить, что система сделает и где человек по-прежнему принимает решения.

Если нужна вторая экспертная точка зрения по границам, Oleg Sotnikov at oleg.is работает со стартапами и малыми командами как fractional CTO по AI-first софту, автоматизации и продуктовому дизайну. Внешний обзор такого рода помогает до того, как агент начнёт действовать в живом рабочем процессе.