Multi-step AI agent — это система, которая не просто генерирует один ответ, а последовательно планирует задачу, вызывает инструменты, проверяет результаты, сохраняет нужный контекст и решает, продолжить работу или передать ее человеку. Для бизнеса это означает управляемый процесс, а не автономного «бота», которому разрешено все.
Надежная agent architecture обычно состоит из шести слоев: цель и план, инструменты, состояние, память, guardrails и human handoff. Добавьте повторные попытки, наблюдаемость и регулярные evals — и получите LLM workflow, пригодный для обработки лидов, счетов и других реальных операций.
Чем агент отличается от обычной автоматизации
Классический workflow выполняет заранее заданные шаги: «получить форму → создать запись в CRM → отправить письмо». Агент нужен там, где маршрут зависит от неструктурированных данных: текста заявки, PDF-счета, результатов поиска или истории общения.
| Подход | Когда использовать | Главный риск |
|---|---|---|
| Жесткий workflow | Правила стабильны, данные структурированы | Ломается на исключениях |
| Один LLM-вызов | Классификация, извлечение, черновик | Нет проверки и действий |
| Multi-step agent | Нужны решения, инструменты и ветвление | Неконтролируемая автономность |
Практическое правило: начинайте с детерминированного workflow. Добавляйте агентное решение только в тех точках, где невозможно надежно описать ветвление обычными условиями.
Базовая архитектура: plan → tools → memory → guardrails
1. План и ограниченный цикл выполнения
Агент получает конкретную цель, например: «обогатить входящий лид и подготовить запись в HubSpot». Затем он выбирает следующий шаг из разрешенного набора. Ограничьте цикл, например, пятью вызовами инструментов и двумя минутами. Если цель не достигнута, задача уходит человеку.
2. Инструменты с узкими контрактами
Инструмент — это функция с четкой схемой входа и выхода: найти домен, получить данные CRM, распознать PDF или создать черновик платежа. Подойдут OpenAI или Anthropic для рассуждений, HubSpot и Salesforce для CRM, Stripe для платежных данных, QuickBooks или Xero для учета, Zapier, Make либо n8n для оркестрации.
Не давайте модели универсальный доступ к API. Вместо «выполни запрос» создайте функции вроде get_company_by_domain или create_invoice_draft. Проверяйте типы, обязательные поля, валюту и допустимые значения на уровне кода.
3. Состояние и память
Состояние хранит данные текущего запуска: ID лида, найденный домен, извлеченную сумму, статус проверки. Долгосрочная память содержит устойчивые сведения: правила квалификации, список одобренных поставщиков, налоговые настройки компании.
Не сохраняйте весь диалог автоматически. Для большинства операций достаточно PostgreSQL и таблицы событий. Векторная база нужна только для семантического поиска по большому массиву документов.
4. Guardrails и передача человеку
Guardrails должны быть программными, а не только текстом в prompt. Примеры: запрет на отправку платежа, лимит суммы, разрешенный список валют, маскирование банковских реквизитов и обязательное подтверждение при низкой уверенности.
LLM предлагает решение; код проверяет полномочия; человек подтверждает необратимое действие.
Кейс 1: агент исследования входящих лидов
Допустим, потенциальный клиент заполняет форму: имя, рабочий email, компания и комментарий. Цель агента — за 60–90 секунд собрать контекст и подготовить продавцу краткую карточку, не отправляя письмо самостоятельно.
Пошаговый LLM workflow
- Валидация: код проверяет email, обязательные поля и дубликаты в HubSpot.
- Определение компании: агент извлекает домен из рабочего email. Для Gmail или Outlook требуется ручная проверка либо название компании из формы.
- Обогащение: Clearbit, Apollo или другой подключенный провайдер возвращает структурированные поля. Веб-поиск используется только по разрешенным источникам.
- Квалификация: LLM сопоставляет сведения с вашей ICP-матрицей: страна, отрасль, размер команды, предполагаемый сценарий и срочность.
- Проверка фактов: каждое утверждение получает источник или пометку «не подтверждено». Модель не должна угадывать выручку или бюджет.
- Запись: агент обновляет поля CRM и создает черновик заметки.
- Handoff: продавец получает резюме, причины оценки и рекомендуемый следующий вопрос.
Пример шкалы: 0–40 — nurture, 41–70 — ручная проверка, 71–100 — приоритет продавцу. Это не универсальная формула: пороги настройте по собственным закрытым сделкам.
Цена ошибки здесь асимметрична. Пропущенный хороший лид стоит потенциальной сделки, а ошибочно высокий score — времени менеджера. Поэтому агент может сортировать очередь, но не должен автоматически отклонять заявку.
Кейс 2: агент обработки счетов
Второй сценарий — PDF-счета, поступающие на отдельный email. Агент извлекает реквизиты, сопоставляет поставщика и создает черновик в QuickBooks или Xero. Он не инициирует банковский перевод.
Безопасный маршрут документа
- Сохранить оригинал в закрытом хранилище и присвоить неизменяемый ID.
- Извлечь текст через AWS Textract, Google Document AI или Azure AI Document Intelligence.
- Получить JSON: поставщик, номер счета, даты, валюта, subtotal, налог, total и банковские реквизиты.
- Проверить арифметику кодом: позиции плюс налог должны совпадать с итогом в пределах заданного допуска.
- Найти поставщика в учетной системе по ID, домену или ранее подтвержденным реквизитам.
- Проверить дубликат по поставщику, номеру, дате и сумме.
- Создать только черновик и направить его ответственному сотруднику.
Обязательный handoff нужен, если поставщик новый, банковские реквизиты изменились, отсутствует номер счета, валюта неожиданна или итог не сходится. Для счета на $500 можно установить один маршрут согласования, а для $5,000 — дополнительного утверждающего; конкретные лимиты определяет ваша компания.
Для non-US founder особенно важны мультивалютность и разделение сущностей. Счет вашей Delaware C-Corp нельзя автоматически относить к другой компании основателя только из-за совпадения email.
Надежность: retries, идемпотентность и evals
Повторные попытки без дублей
Временные ошибки API повторяйте с exponential backoff, например через 2, 8 и 30 секунд. Ошибки валидации повторять бессмысленно: их нужно исправить или передать человеку.
Каждая операция записи должна иметь idempotency key. Если Zapier или n8n перезапустит задачу, система не создаст второй лид или второй черновик счета.
Evals до и после запуска
Соберите набор из 50–100 обезличенных примеров, включая сложные случаи. Для лидов измеряйте точность полей, качество источников и долю корректных маршрутов. Для счетов — точность суммы, валюты, поставщика, поиск дублей и долю ручных исправлений.
Запускайте evals при смене prompt, модели, OCR-провайдера или бизнес-правил. В production записывайте версию модели, входные данные, вызовы инструментов, задержку, стоимость и итоговое решение — без лишних персональных данных.
Чек-лист запуска за 2–4 недели
- Выберите один процесс с измеримым результатом и 50–200 примерами.
- Опишите разрешенные действия, запрещенные действия и владельца исключений.
- Сначала реализуйте «теневой режим»: агент предлагает, человек выполняет.
- Добавьте схемы JSON, тайм-ауты, лимит шагов и idempotency keys.
- Создайте eval-набор и зафиксируйте исходные метрики.
- Запустите на 10–20% задач и еженедельно разбирайте ошибки.
- Автоматизируйте обратимые шаги; платежи и другие необратимые действия оставьте на подтверждении.
FAQ
Нужен ли отдельный агент для каждого процесса?
Обычно да. Общая платформа может быть одной, но инструменты, память, разрешения и evals для лидов и счетов должны различаться.
Можно ли построить агента только в Zapier или Make?
Для пилота — часто можно. При сложном состоянии, строгой идемпотентности и детальном аудите обычно потребуется собственный backend и база данных.
Как выбрать между OpenAI и Anthropic?
Проверьте обе модели на собственном eval-наборе. Сравнивайте не только качество текста, но и корректность tool calls, задержку, стоимость и стабильность JSON.
Когда агенту нельзя давать автономность?
Когда действие необратимо, затрагивает деньги, доступы, юридические обязательства или чувствительные данные. В таких точках нужен human-in-the-loop.
Когда поможет Founder Portal
Founder Portal может помочь non-US founder связать агентный workflow с операционным контуром американской компании — Stripe, банковскими и учетными процессами — и определить, где автоматизация безопасна, а где необходимо подтверждение человека.