Как AWS строит агентные продажи на Amazon Bedrock AgentCore: опыт Field Advisor — VogueTech

Что нового

AWS показала, как перевела свою глобальную команду продаж на агентный ИИ-слой Field Advisor, построенный на Amazon Bedrock AgentCore. Ключевые изменения и цифры:

Вместо зоопарка из более чем 20 разрозненных ИИ‑агентов (CRM, рекомендации, комплаенс, аналитика) появился единый интерфейс — Field Advisor.
Вся оркестрация между агентами и инструментами перенесена в Amazon Bedrock AgentCore:
- изолированные окружения исполнения (MicroVM) для каждого сеанса;
- единый шлюз ко всем инструментам и агентам через AgentCore Gateway;
- встроенная долговременная память (AgentCore Memory);
- единая идентичность и OAuth (AgentCore Identity);
- наблюдаемость и метрики (AgentCore Observability);
- встроенная оценка качества (AgentCore Evaluations).
Продажи AWS уже отправили более 120 000 запросов во всех каналах (CRM, Slack, веб‑портал).
После миграции на AgentCore:
- латентность снизилась на 41% по сравнению с предыдущей инфраструктурой;
- вместо 7 отдельных AWS‑аккаунтов оркестрация работает в одном AgentCore Runtime;
- команда отказалась от самописных систем для памяти, логирования и аутентификации.
Компонент human‑in‑the‑loop (создание и обновление CRM‑записей с подтверждением человека) экономит крупным аккаунт‑менеджерам до 2 часов в неделю.
Field Advisor работает прямо в привычных инструментах:
- панель в CRM;
- интеграция со Slack;
- собственные внутренние приложения AWS.
Под капотом — последняя версия Anthropic Claude на Amazon Bedrock с кросс‑региональным профилем инференса для высокой пропускной способности.
Для ускорения многоходовых диалогов AWS реализовала кастомную модель PromptCachingBedrockModel с инкрементальным кэшированием промпта.
Оркестрация основана на Strands Agents: reasoning‑цикл, хуки, Interrupt‑механизм, интеграция с OpenTelemetry.

Как это работает

Общая архитектура Field Advisor

Field Advisor — это надстройка над существующими системами продаж AWS. Пользователь общается с одним ассистентом, а под капотом запускается многоагентная схема:

Каналы ввода: CRM‑панель, Slack или веб‑портал.
Аутентификация: запрос проходит через сервис аутентификации, который проверяет пользователя и выдает OAuth‑токен.
AgentCore Runtime:
- получает аутентифицированный запрос;
- поднимает supervisor‑агента на Strands Agents в изолированной MicroVM;
- управляет жизненным циклом агента, доступом к моделям и стримингом ответов.
Supervisor‑агент:
- анализирует запрос;
- решает, какие инструменты и под‑агенты вызывать;
- может параллельно дергать несколько инструментов и агентов;
- собирает результаты в единый ответ.
AgentCore Identity:
- прокидывает OAuth‑идентичность во все инструменты и удаленные агенты;
- для кросс‑аккаунт вызовов использует machine‑to‑machine обмен токенами.
AgentCore Gateway:
- единственная точка доступа к удаленным MCP‑инструментам;
- supervisor при старте подтягивает описания инструментов и создает локальные Strands‑tools без изменений в рантайме.
AgentCore Memory:
- хранит краткосрочную историю диалогов;
- поддерживает долгосрочную семантическую память (факты, предпочтения, прошлые взаимодействия);
- кастомный SessionManager синхронизирует состояние после каждого вызова, а не после каждого сообщения.
AgentCore Observability и Evaluations:
- собирают трейсы, логи, метрики и данные для оценки качества (релевантность, точность контекста, корректность действий, faithfulness);
- Strands Agents интегрируется с OpenTelemetry для распределенного трейсинга по всем агентам и MCP‑инструментам.

Оркестрация и модель

Supervisor‑агент в Strands Agents инициализируется с:

системным промптом;
набором инструментов (локальные, удаленные агенты, MCP‑инструменты, CRM‑операции, поиск по базе знаний);
менеджером сессий и контекста;
провайдером модели — последней версией Anthropic Claude на Amazon Bedrock через кросс‑региональный профиль инференса.

Чтобы снизить задержку в многоходовых диалогах, AWS реализовала обертку PromptCachingBedrockModel над стандартным BedrockModel из Strands. Она добавляет скользящую точку кэширования в последний запрос, чтобы модель не пересчитывала весь контекст заново, а использовала уже закэшированный префикс.

Полный код из блога:

CACHE_POINT = {"cachePoint": {"type": "default", "ttl": "1h"}}

class PromptCachingBedrockModel(BedrockModel):
    """Add a rolling cache point to the latest message so the model reuses cached prefixes instead of re-processing the full history."""

    def _format_request(self, messages, **kwargs):
        # Remove stale cache points from older messages
        for msg in messages:
            msg["content"] = [
                b for b in msg["content"] if "cachePoint" not in b
            ]

        # Add a cache point to the latest message
        messages[-1]["content"].append(CACHE_POINT)

        return super()._format_request(messages=messages, **kwargs)

Amazon Bedrock ограничивает количество cachePoint в одном запросе и требует неубывающий TTL для разных частей (инструменты, системный промпт, сообщения). Поэтому AWS аккуратно управляет размещением cachePoint, чтобы каждый новый ход расширял уже закэшированный префикс, а не пересчитывал все с нуля.

Хуки Strands Agents: логика без переписывания ядра

Strands Agents дает систему хуков, через которые AWS добавляет бизнес‑логику без изменения reasoning‑цикла. В Field Advisor используются:

Circuit breaker для инструментов — если инструмент многократно падает в рамках одного вызова, supervisor автоматически перестает его дергать.
Контингентная авторизация — все вызовы, которые лезут в чувствительные CRM‑данные, перехватываются хуком, исполнительная ветка ставится на паузу через Interrupt, пользователь видит запрос на согласие и только после этого агент продолжает работу.
Подтверждение записей на запись (write confirmation) — перед изменением данных агент показывает пользователю, какие поля он собирается обновить, и ждет явного подтверждения.
Извлечение цитат — результаты поиска по базе знаний проходят через хук, который вытаскивает источники и прикрепляет их к финальному ответу.
Стриминг статуса вызова инструментов — фронтенд получает промежуточные статусы, пока агент работает.

Эта схема разгружает команды, которые пишут удаленные агенты и инструменты: им не нужно реализовывать circuit breaker, авторизацию и стриминг по‑отдельности, supervisor делает это централизованно.

Мультиагентная координация

Field Advisor использует паттерн supervisor–subagent:

supervisor‑агент — главный оркестратор;
доменные агенты (комплаенс, рекомендации продуктов, планирование встреч и т. д.) подключены как инструменты.

Каждый удаленный агент описан конфигом: имя, описание, один параметр query. Strands‑tool оборачивает вызов этого агента:

def create_remote_agent_tool(config: RemoteAgentConfig) -> AgentTool:
    """Create a Strands tool that wraps a remote agent."""

    async def remote_agent_tool(query: str, tool_context: ToolContext):
        invoker = RemoteAgentInvoker(config)
        params = InvocationParams(
            query=query,
            session_id=session_id,
            alias=alias,
            ...
        )

        async for event in invoker.stream(params):
            if is_final_response(event):
                payload = parse_response_payload(event)

                # Surface any interrupts from the remote agent
                if payload.interrupts:
                    tool_context.interrupt(payload.interrupts)

                yield payload.response
            else:
                yield event  # stream tool-call progress to the UI

    return tool(context=True)(remote_agent_tool)

Supervisor видит все как плоский список инструментов. Reasoning‑цикл Strands сам решает, что вызывать и в каком порядке. Чтобы добавить новый агент, достаточно прописать конфигурацию — оркестрация не меняется.

Есть и pass‑through режим: если продавец явно выбирает конкретного агента, запрос идет напрямую в этот sub‑агент, минуя supervisor. Ответ стримится обратно без изменений, включая форматирование и цитаты.

Human‑in‑the‑loop без отдельной инфраструктуры

Field Advisor активно использует Strands Interrupts для сценариев с обязательным участием человека:

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

Как это работает:

Инструмент или удаленный агент понимает, что нужен ввод пользователя.
Он возвращает Interrupt.
Исполнение останавливается, Interrupt уходит клиенту (Slack, CRM‑панель).
Пользователь отвечает, агент продолжает с учетом этого ввода.

AWS расширила этот паттерн на кросс‑агентные сценарии. Если удаленный агент вернул Interrupt в своем payload, локальный wrapper‑инструмент поднимает Strands Interrupt от своего имени. Для пользователя все выглядит как единый диалог с одним ассистентом, независимо от того, сколько агентов участвуют.

За счет того, что Strands Interrupts хранят состояние в SessionManager, AWS обошлась без отдельного сервиса для human‑in‑the‑loop с очередями и поллингом.

Память и контекст

AgentCore Memory отвечает за два уровня памяти:

Краткосрочная — полная история диалога в рамках сессии.
Долгосрочная — семантическое хранилище фактов и предпочтений, которое живет между сессиями.

Field Advisor использует кастомный менеджер сессий на базе AgentCoreMemorySessionManager из Strands Agents. Он оптимизирует записи в хранилище: синхронизирует состояние после каждого вызова агента, а не после каждого отдельного сообщения. Это снижает число API‑запросов без потери надежности.

За счет памяти Field Advisor:

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

Что это значит для вас

Если вы руководите продажами или customer success

Field Advisor показывает, как можно использовать агентный ИИ не как «еще один бот», а как единый слой над всей инфраструктурой продаж:

Один интерфейс вместо десятка разрозненных ИИ‑агентов и внутренних инструментов.
Меньше контекст‑свитчинга между CRM, документами, планировщиками и аналитикой.
Часть рутинных действий (создание задач в CRM, обновление записей, проверка комплаенса) переезжает в ИИ, но с обязательным человеческим подтверждением.
Освободившиеся часы уходят на реальные разговоры с клиентами и стратегическое планирование.

Практически это можно применять для:

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

Если у вас уже есть несколько внутренних агентов или сервисов (условный «бот по документации», «бот по CRM», «бот по комплаенсу»), опыт AWS показывает, что без центрального оркестратора пользователи тратят время на выбор правильного бота и склейку ответов. AgentCore‑подход снимает этот когнитивный шум.

Если вы строите свои агентные системы

Полезные выводы из кейса AWS:

Не спешите писать свой оркестратор. AgentCore закрывает:
- изоляцию исполнения (MicroVM);
- память;
- идентичность и OAuth;
- шлюз к инструментам (включая MCP);
- наблюдаемость и оценку качества.
Используйте паттерн supervisor–subagent:
- supervisor как единая точка разума и политики;
- доменные агенты как инструменты с четким контрактом.
Включайте human‑in‑the‑loop как базовую конструкцию, а не как «потом прикрутим»:
- Interrupt‑механизм в Strands — простой способ сделать это без отдельной инфраструктуры.
Для производственных нагрузок с длинными диалогами имеет смысл внедрить кэширование промптов, как PromptCachingBedrockModel.
Наблюдаемость и оценки качества — не опция. При сложных multi‑tool сценариях без OpenTelemetry‑трейсов и автоматических метрик качество быстро деградирует незаметно.

Ограничения и реалии для России

Amazon Bedrock и AgentCore — облачные сервисы AWS. Для прямого доступа из России могут потребоваться:
- регистрация AWS‑аккаунта на юрисдикцию вне РФ;
- VPN и инфраструктура в других регионах.
Field Advisor — внутренний продукт AWS. Внешним компаниям он недоступен, но архитектурные решения можно повторить.
Если вы строите решения для российского рынка, придется учитывать:
- юридические ограничения по вывозу данных в зарубежные облака;
- требования к хранению персональных данных и коммерческой тайны.

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

Место на рынке

По сути Amazon Bedrock AgentCore конкурирует не с одной моделью, а с целым классом решений:

самописные оркестраторы на базе фреймворков вроде LangChain/LangGraph;
встроенные агенты в отдельных платформах (CRM, helpdesk и т. д.);
кастомные микросервисные архитектуры вокруг LLM.

В этом кейсе AWS показывает несколько конкретных преимуществ AgentCore по сравнению с их же предыдущей инфраструктурой:

−41% латентности на реальных нагрузках продаж;
отказ от 7 AWS‑аккаунтов в пользу единого рантайма;
вынос памяти, аутентификации и наблюдаемости из кода продукта в платформу.

Сравнения с GPT‑4o, Claude 3.5/3.7 или другими моделями по скорости, цене и качеству AWS здесь не приводит. Фокус — именно на уровне оркестрации и эксплуатации, а не на сравнении самих LLM.

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

Как запустить похожую архитектуру

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

Развернуть Amazon Bedrock AgentCore в своем AWS‑аккаунте.
Настроить Identity и OAuth:
- подключить ваш IdP (например, корпоративный SSO);
- настроить прокидывание токенов в инструменты и удаленные агенты.
Поднять AgentCore Gateway:
- зарегистрировать MCP‑инструменты;
- описать их схемы и доступы.
Собрать supervisor‑агента на Strands Agents:
- выбрать модель (например, последнюю Claude на Bedrock);
- реализовать PromptCachingBedrockModel по примеру выше;
- описать инструменты (CRM, базы знаний, MCP, удаленные агенты);
- подключить SessionManager на базе AgentCore Memory.
Обернуть доменные агенты в инструменты по образцу create_remote_agent_tool.
Включить хуки для:
- circuit breaking;
- авторизации;
- подтверждения записей;
- стриминга статусов и цитат.
Интегрировать каналы: веб‑панель, Slack‑бот, расширение для вашей CRM.
Подключить Observability и Evaluations:
- включить OpenTelemetry‑трейсинг;
- настроить метрики качества и алерты.

Если вы уже работаете с AWS и Bedrock, этот стек можно внедрять поэтапно: сначала supervisor над существующими инструментами, потом — вынос памяти и идентичности в AgentCore, затем — Observability и Evaluations.